首屏加载时间主要受五件事影响：图片体积、字体加载、第三方脚本、服务器响应、渲染阻塞资源。按影响大小排序，图片和脚本通常占七成以上。纯静态站点在服务器响应和渲染阻塞两项上有天然优势，但图片和第三方脚本仍然要靠人管。
先量，再改
没有测量的优化都是猜。先测三组数据：桌面端、移动端 4G、移动端弱网。三组数据的差距往往比想象中大——桌面端 1 秒的页面，在弱网下可能是 6 秒。
测量工具用搜索引擎官方提供的页面体验报告即可，它给的是真实用户数据，比实验室数据更接近实际。
因素一：图片体积
图片通常是首屏最大的资源。一张未压缩的 2000 像素宽的产品图，体积可能超过 1MB，而它在手机上只需要显示 400 像素宽。
处理顺序：先按显示尺寸裁切，再压缩到合适质量，最后用现代格式（WebP 或 AVIF）。三步做完，同一张图通常能降到原来的十分之一。
首屏图片不要懒加载。懒加载会让首屏图片延迟出现，反而拉长最大内容绘制时间。首屏以下的图片才懒加载。
因素二：字体加载
中文字体文件动辄几 MB，直接引入会明显拖慢首屏。三种处理方式：
第一，用系统字体。中文环境下系统字体的渲染质量已经足够，这是最快的方案。
第二，如果必须用自定义字体，只引入需要的字重与字符子集，并用 font-display 控制回退行为。
第三，字体文件自托管，不要依赖第三方域名。第三方域名多一次 DNS 解析和连接建立，在弱网下代价明显。
因素三：第三方脚本
统计、客服、广告、热力图，每个第三方脚本都是一次额外的网络请求与执行。装五个，首屏时间翻倍是常态。
处理方式：先盘点，把所有第三方脚本列出来，问一句"这个还在用吗"。通常能删掉三分之一。
留下的脚本加异步属性，不要阻塞渲染。客服与统计类脚本延迟到用户交互或首屏渲染完成后再加载。
因素四：服务器响应
服务器响应时间指从请求发出到收到第一个字节的时间。静态文件由 CDN 分发时，这项通常在几十毫秒；动态渲染的页面则取决于数据库查询与缓存策略。
纯静态站点的优势就在这里：没有数据库查询，没有服务端渲染，文件直接从边缘节点返回。代价是内容更新需要重新生成，但对内容更新频率不高的企业站，这个代价可以接受。
因素五：渲染阻塞资源
浏览器遇到样式表和同步脚本时会暂停渲染。首屏需要的样式应该内联或优先加载，非首屏的样式可以延后。
脚本加 defer 或 async，除非它必须在渲染前执行。多数情况下没有脚本需要阻塞渲染。
处理顺序
| 顺序 | 动作 | 预期收益 | 工作量 |
|---|---|---|---|
| 1 | 压缩首屏图片、改用现代格式 | 大 | 小 |
| 2 | 删除无用第三方脚本 | 大 | 小 |
| 3 | 字体改为系统字体或子集化 | 中 | 小 |
| 4 | 静态化与 CDN 分发 | 大 | 中 |
| 5 | 内联首屏样式、脚本异步化 | 中 | 中 |
按这个顺序做，通常能在不动设计的前提下把首屏时间压掉一半以上。反过来先做第五项，收益很小。
速度和排名是什么关系
页面体验是排名因素之一，但不是决定性因素。一个内容与查询高度匹配、权威度足够的页面，速度慢一些仍然能排上去；速度快的薄内容页不会因为快而排上去。
所以速度优化的定位是：不要让它成为短板。达标之后继续投入的边际收益很低，不如把时间放在内容与内链上。