你的用户还在等，3秒后他们就走了

别自欺欺人了——用户不是“没耐心”，是根本没给你机会。
你精心写的标题、主图、行动按钮，如果3秒内没露脸，大概率已经进了回收站。

我上周帮一个做母婴知识的公众号落地页调优，首页首屏加载卡在2.8秒，用户滑走前连“免费领取育儿清单”这行字都没看见。不是内容不好，是页面太慢，慢到还没开口，人家就转身走了。

首屏到底要渲染什么？先做减法

首屏 ≠ 整个首页。它只是用户手机/电脑屏幕里那一小块区域里，最先撞进眼里的东西：标题、一两行核心描述、主导航、一张真正关键的图。别的，统统往后排。

怎么确认？打开 Chrome，按 F12 → 切到 Device Toolbar（那个小手机图标）→ 选 iPhone 或 “Responsive” 拉到常见屏幕宽度 → 看一眼，框住你眼睛第一下扫到的部分。就这框里，必须1秒内有东西出来。

然后狠心问自己三句：

  • 这张图不放这儿，用户会错过关键信息吗？
  • 这段文案现在不显示，会影响他立刻理解这是干啥的吗？
  • 那个“点赞+分享+收藏”三件套插件，非得挤在首屏加载吗？

之前优化过一个本地烘焙店的官网，首屏硬塞了4个轮播图、2个弹窗脚本、1个实时库存查询组件……结果用户点开页面，盯着白屏等了3秒多。砍掉轮播图（换成一张高清静态主图），把库存查询挪到商品详情页再触发，首屏直接压进0.9秒。用户终于看得到“今日现烤｜下单即发”这行字了。

记住：首屏不是舞台，是门把手。推开门，人才愿意进来。

图片是首屏杀手，怎么压缩才有效？

别再传设计师给的4K大图了。你上传一张4000×3000的JPG，再用CSS缩成400px宽，浏览器照单全收——还是下载那4MB。用户流量在替你买单，你却在喂它吃撑。

最省力有效的办法就两条：

  • 首屏图片统一转 WebP 格式（Photoshop导出时选“导出为”，格式选 WebP；Mac 用户用预览也能批量转）；
  • 上传前手动裁剪/缩放到你实际展示的最大尺寸，比如首屏横幅图，宽度别超1200px（PC端）或800px（移动端）。

有个做职场写作课的小红书博主，把课程封面图全换成 WebP + 尺寸压缩，原来首屏加载要等2秒多，改完后基本秒出。她后台发现，用户在首页停留时间变长了，咨询私信也多了——没人教她做SEO，但她让内容“被看见”了。

渲染阻塞的JavaScript，你排查过吗？

浏览器加载页面像排队打饭：HTML 是队伍，<script> 是突然插队的人。它一来，后面所有内容都得等它吃完再动。

怎么知道是不是它在捣乱？
打开 Chrome 开发者工具 → Performance 标签 → 点左上角圆点开始录制 → 刷新页面 → 停下 → 看时间轴。如果在“首屏内容出现前”有一长条黄色（Scripting）或紫色（Rendering）块，那就是它。

三个马上能做的动作：

  • 所有非首屏必需的脚本（比如百度统计、微信分享、客服浮窗），加上 defer 属性；
  • 把首屏必须跑的极小段逻辑（比如导航高亮判断），直接写进 <script> 标签里，别外链；
  • 把所有 <script> 标签从 <head> 里剪出来，粘贴到 </body> 前面。

之前帮一个SaaS工具官网调优，他们首页挂了个“3D产品演示动画”，JS文件2MB多，还放在head里。删掉动画，用纯CSS实现入场动效，首屏从2.6秒压到0.7秒。销售说，当天表单提交量肉眼可见地涨了一截。

字体也能拖慢首屏，你信吗？

真信。你用 Google Fonts 引入一套“高级感”字体，浏览器得先下载、解析、激活，才能画出第一个字。这期间，标题位置一片空白——用户以为页面崩了。

最干脆的解法：首屏文字用系统字体。一行CSS就能搞定：

h1, h2, .hero-text {
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
}

如果品牌强要求用定制字体，至少加一句：

@font-face {
  font-family: 'MyBrand';
  src: url('mybrand.woff2');
  font-display: swap; /* 关键！ */
}

swap 的意思很直白：先用系统字体顶上，等你的字体下完再换。用户不会卡在白屏里干等。

见过一个新闻聚合站，首页硬上了3套自定义字体，每套都带粗体/斜体/数字变体……首屏文字等了快3秒才浮现。切回系统字体后，标题和摘要几乎和页面骨架一起出来。编辑说，读者反馈“终于不用盯着空白屏猜标题了”。

服务器响应时间，你检查过吗？

首屏再快，也得等服务器“应一声”。TTFB（Time to First Byte）就是这个“应声”时间。超过500ms，说明服务器已经在拖后腿了。

怎么查？Chrome 开发者工具 → Network 标签 → 刷新 → 看第一条请求（通常是 document）的 TTFB 值。
如果它动不动就跳到800ms、1200ms，别折腾前端了，先看后台。

WordPress 用户最常踩的坑：

  • 共享主机跑5个插件+3个主题+没清理的数据库；
  • 缓存插件开着但没配好，或者压根没开；
  • 主题自带一堆“炫酷功能”，其实90%没人用。

解决方案也很实在：

  • 启用 WP Super Cache 或 LiteSpeed Cache（如果你用LiteSpeed服务器）；
  • 在 WordPress 后台 → 插件 → 停用所有非必要插件，只留缓存、安全、SEO这三个；
  • 进数据库（phpMyAdmin）删掉 wp_options 表里 transient_ 开头的垃圾缓存。

有个做考研资料分享的WordPress站，原来在廉价共享主机上，TTFB平均1.3秒。开了LiteSpeed Cache + 清掉27个闲置插件，TTFB稳在120ms左右。首页首屏从3.5秒掉到1.4秒，新用户留存率明显变高。

今天就能执行的3个操作步骤

别收藏吃灰，现在就打开电脑做：

  1. 打开 Chrome，按 F12 → 点右上角 ⋯ → More Tools → Network Conditions → 勾选 “Slow 3G” → 刷新你的首页。盯紧“首屏内容完整出现”的时间。如果＞2秒：立刻用 Squoosh.app（免费在线工具）把首屏所有图片转成 WebP，宽度设为800px（移动端）或1200px（PC端），替换上传。

  2. 回到 Chrome 开发者工具 → Performance → 录制一次加载 → 找到 TTFB 后、首屏内容前那段长黄色块 → 看它的 Name 是哪个 .js 文件 → 打开你网站的HTML源码（或主题的 header.php / footer.php），把这个文件的 <script> 标签加上 defer，或者剪到 </body> 上方。

  3. 打开你网站的CSS文件（一般是 style.css 或主题自定义CSS），找到首屏文字的选择器（比如 .hero h1, .site-title），把 font-family 改成：

    font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;

    保存，刷新，对比前后——你会亲眼看到文字“抢在图片前一步跳出来”。