从零搭建SSR方案的踩坑经验与核心技巧分享

又踩坑了，SSR渲染性能问题折腾了我两天

最近在做一个基于Next.js的项目，遇到一个头疼的问题：首屏加载速度慢得让人抓狂。用户访问页面时，明明数据量不大，但硬是要等个两三秒才能看到内容。这里我踩了个大坑，差点怀疑人生。

一开始我以为是接口响应慢，结果发现API调用其实不到300ms。后来试了下把服务端渲染改成客户端渲染，速度立马快了不少。但这显然不是长久之计，毕竟SEO优化和首屏体验还是要靠SSR来保证。

排查过程：从网络请求到代码实现

折腾了半天发现，问题出在几个地方。首先是服务端渲染时的数据获取逻辑太重，其次是组件初始化时做了太多不必要的计算。具体来说：

• 每个页面都在getServerSideProps里调用了多个API
• 有些组件在服务端和客户端都重复执行了相同的逻辑
• 最大的坑是：某些第三方库在服务端环境下表现异常，导致额外的阻塞

这里我要特别提醒：千万别在getServerSideProps里写太多逻辑。我就是因为贪图方便，把一堆业务逻辑都塞进去了，结果服务端每次渲染都要等这些逻辑跑完。

核心代码就这几行

最终的解决方案是从数据获取、组件优化到第三方库使用都做了调整。下面详细说说我是怎么改的。

1. 数据获取优化

我把原先分散在各个页面的getServerSideProps提取出来，做了一个统一的数据预取服务：

// utils/data-fetch.js
export const fetchData = async (url) => {
  try {
    const res = await fetch(https://jztheme.com/api/${url});
    if (!res.ok) throw new Error('Failed to fetch data');
    return await res.json();
  } catch (err) {
    console.error(err);
    return null;
  }
};

// pages/index.js
export const getServerSideProps = async () => {
  const [headerData, mainData] = await Promise.all([
    fetchData('header'),
    fetchData('main-content')
  ]);

  return {
    props: {
      headerData,
      mainData
    }
  };
};

这里的关键是用Promise.all并行处理多个请求，别再傻乎乎地串行调用了。之前我就因为这个浪费了不少时间。

2. 组件懒加载

有些非首屏组件没必要一开始就渲染，所以我加了动态导入：

// components/LazyComponent.js
import dynamic from 'next/dynamic';

const HeavyComponent = dynamic(() => import('../components/HeavyComponent'), { 
  ssr: false 
});

export default function LazyComponent() {
  return (
    <div>
      <HeavyComponent />
    </div>
  );
}

这里要注意：设置ssr为false很重要，否则Next.js还是会尝试在服务端渲染这个组件。

3. 第三方库适配

有好几个库在服务端环境会报错，比如某个日期处理库。我的解决办法是：

// utils/date-utils.js
import isServer from 'is-server';
import dayjs from 'dayjs';

let localizedDayjs;

if (!isServer()) {
  const customParseFormat = require('dayjs/plugin/customParseFormat');
  dayjs.extend(customParseFormat);
  localizedDayjs = dayjs;
} else {
  localizedDayjs = null;
}

export const formatDate = (date, format) => {
  if (!localizedDayjs) return '';
  return localizedDayjs(date).format(format);
};

这个方案虽然看起来有点丑，但确实解决了服务端渲染时报错的问题。

三种方案对比，我选了最简单的

其实我尝试过几个不同的优化方向：

• 完全静态生成（Static Generation）：对动态内容不友好
• 边缘计算（Edge Computing）：配置太复杂，团队维护成本高
• 服务端缓存：效果不错，但需要额外的Redis支持

最后还是选择了在现有SSR基础上做优化，主要是改动最小，见效最快。虽然还有点小瑕疵，比如极端情况下首屏还是会有一点延迟，但整体已经比之前好太多了。

踩坑提醒：这三点一定注意

总结一下我在优化过程中遇到的主要坑：

1. 不要在服务端执行客户端特有的逻辑：比如window对象相关的操作
2. 注意第三方库的兼容性：很多库默认只考虑浏览器环境
3. 避免过度优化：有时候简单的方案反而更稳定

以上是我个人对这个SSR优化的完整讲解，有更优的实现方式欢迎评论区交流。这个技巧的拓展用法还有很多，后续我会继续分享这类博客。