首屏加载时间：我优化了三年，终于让网站快到令人发指
说真的，我以前压根不关心什么首屏加载时间。不就是打开网页那一下子吗？能慢到哪去。直到有一天，我自己负责的一个电商站——用户唰唰唰流失，转化率跌得亲妈都不认识。查了一通数据，发现移动端平均首屏加载...6.8秒！6.8秒啊兄弟们，我自己都等不了。那一刻我才明白，这玩意儿是真能要命的。https://obgeo.oss-cn-beijing.aliyuncs.com/pvc-articles/0fbac0bc-37bd-4d72-9425-8cf5cca0fc7e.jpg
电脑屏幕上显示网站加载缓慢的报错页面
我现在做SEO/GEO这行，见过太多站因为首屏慢被踢出局。谷歌那帮人天天喊用户体验，Core Web Vitals都快成圣旨了。而LCP（最大内容绘制），就是圣旨上最刺眼的大红字。但有意思的是，很多站长压根搞不清LCP、FCP、TTFB的区别，混在一起调优，越调越烂。
首屏加载时间，不就是LCP吗？可没那么简单
https://obgeo.oss-cn-beijing.aliyuncs.com/pvc-articles/0c276b47-5404-4c3e-94c4-11349dbe00dd.jpg
首屏加载时间，不就是LCP吗？可没那么简单
如果你只看Lighthouse报告，很容易被带偏。LCP是好事，但**它只是一个时间点**。真正影响用户感知的，是从用户点击到页面完全可用的整个过程。我举个例子：某个站LCP只有1.5秒，漂亮吧？但它的FCP（首次内容绘制）却花了4秒。这意味着用户盯着白屏看了4秒，然后突然涌出一堆内容。这种体验，比慢悠悠加载还恶心——因为它缺乏渐进感，让人以为是坏了。
说实话，我一度迷信TTFB（首字节时间）。觉得服务器响应快，后面自然快。可现实啪啪打脸。TTFB降到了200毫秒以内，但首屏还是慢如牛。为啥？因为那堆阻塞渲染的CSS和JS还在后面排队呢。浏览器光等服务器响应没用，它得把那些资源下载完，解析完，才能画出第一帧。
这里就要提一嘴渲染路径。如果你不懂关键渲染路径，优化就是瞎猫碰死耗子。很多人爱用巨型CSS框架，比如全量Bootstrap，只用到10%的样式，却让浏览器全部解析。这不有病吗？还有JS，写着defer就以为万事大吉，结果那些defer的脚本还是阻塞了DOMContentLoaded，虽然没有阻塞渲染，但如果你的页面依赖JS来展示首屏内容，那一样白瞎。
为什么你的首屏加载能慢到让人想砸电脑？
我复盘过一堆慢站，发现问题往往不是单一原因。第一杀手：图片。不是图片多，是图片大得离谱。我见过最夸张的，一个Banner图8MB，png未压缩。我说你图啥？他说“设计师给的，高清”。高清你个头啊，你一个企业官网，谁敢放大看像素？第二杀手：第三方脚本。什么统计代码、在线聊天、热力图、广告联盟，一堆不知名的tracker。它们就像蟑螂，踩死一个出来一群。更可恨的是，这些脚本加载的时候会阻塞页面，而且你还没法控制它们的CDN质量。有一次，一个A/B测试工具挂了，直接导致我的站白屏30秒，因为它在head里同步加载。
第三杀手，也是很多人忽略的：字体文件。尤其是自定义中文字体，动辄好几兆。如果你没用font-display: swap，浏览器会傻等字体下载完才显示文字。这段时间用户看到的就是空白，或者“闪烁不可见文本”（FOIT）。我就被坑过，中文字体用了wordpress主题自带的，结果移动端白屏5秒。排查好久才发现。
https://obgeo.oss-cn-beijing.aliyuncs.com/pvc-articles/f6043942-487c-4751-9ad1-6a9a011c962e.jpg
WebPageTest瀑布图分析首屏加载瓶颈
第四，服务器配置。什么Gzip都不开，CDN不用，甚至还用HTTP/1.1。都2025年了，还不用HTTP/2的多路复用，资源加载排队排到地老天荒。另外，缓存策略也是重灾区。明明可以静态的资源，偏偏设个no-cache，让用户每次重新下载。这不是作死是啥？
我的优化血泪史：从6.8秒到1.2秒，差点没把自己折腾死
那个6.8秒的电商站，我是怎么救回来的？说起来都是泪。上手先用WebPageTest跑了一遍，选了个迪拜的机器，模拟3G，因为目标市场在中东。瀑布图一出来，直接傻眼：总共150个请求，其中50多个是第三方域名的脚本，还有一堆3MB以上的大图。优化方向立刻清晰了——先砍后优。
砍掉不必要的东西是最快的。我跟市场部吵了一架，把浮窗聊天机器人给下了（他们非要用来收集线索，但数据显示，它造成20%的用户直接离开）。然后广告重定向脚本，只保留一个。那些GA之外的统计，比如某个不知名国产分析工具，也删了。这一通操作，请求数降到90，首屏时间降到4秒左右。
接下来搞图片。全部换成WebP格式，并实施响应式图片，用srcset和sizes。大Banner图用低质量占位加渐进式加载。这里有个技巧，别用通用懒加载库，直接用loading='lazy'属性，原生支持最好。同时，对所有图片设置明确的width和height，防止CLS（累积布局偏移）。因为图一出来把文字挤飞，也是恶心用户。
CSS优化可要了老命。我把关键CSS手动提取出来，内联到head里。第一次自己手写提取，结果漏了样式，页面乱成狗。后来用Critical工具包自动化，清爽了。非关键CSS全部异步加载，用了一些老掉牙但管用的黑魔法。
JS方面，所有脚本都审查一边。能用async的绝不sync，还用了资源提示：比如preconnect、dns-prefetch提前建连。对重要页面资源，加了preload。这里有个坑，preload如果没用好，会造成下载竞争，反而不利。得看瀑布图，别盲目preload。
服务器端，升级到HTTP/2是必须的。然后全站CDN，静态资源用单独的域名（但要避免额外DNS查询）。缓存策略调优，对于版本化的静态资源，直接设一年max-age。HTML页面用协商缓存，但TTFB尽可能压到100ms。PHP后端启用了OPcache，数据库查询缓存也上了。
最终，这个站的首屏加载稳定在1.2秒，LCP 1.5秒以内，转化率提升了30%多。那种成就感，怎么说呢，就像便秘一周终于通畅了。
那些年我信过的优化玄学，差点把我送走
网上有些流传很广的“最佳实践”，真用起来要谨慎。比如DNS预解析，加多了反而拖慢，因为浏览器同时能解析的DNS有限。还有把脚本全放到body底部，也不全对。如果是页面渲染必需的脚本，放底部会让用户先看到未点缀的裸内容，然后突然蹦出样式或交互，体验割裂。所以关键脚本异步加载或defer，非关键脚本延迟加载，才是正解。
另一玄学是“减少HTTP请求”，结果有人把多个小图片搞成雪碧图，或者所有CSS合一个，JS合一个。在HTTP/1.1时代有用，现在HTTP/2多路复用，反而可能因为大块文件影响缓存粒度和执行效率。尤其是较大的合并文件，改一个小模块就要全量废弃缓存，得不偿失。所以适当代码分割更重要。
https://obgeo.oss-cn-beijing.aliyuncs.com/pvc-articles/99396cb3-ecc6-4f68-b725-df297a78c3c3.jpg
网站性能优化前后LCP数据对比图表
再比如，“绝对要避免CSS表达式”，这个在现代浏览器已经过时了。还有人迷信AMP，被坑得网站功能不全，流量反而跌。现在谷歌都不怎么推了。所以优化没有银弹，一切看自己的实际测试数据。
未来，谷歌的Web Vitals又要更新，INP取代FID，关注交互延迟。首屏加载只是第一步，交互流畅性才是长久之道。但搞技术的人，永远在和1秒较劲。有时候想想，也挺无趣的。可是看到用户能用得爽，又觉得值了。就这样吧，继续填坑。 已经推荐给朋友来看了，好东西就应该一起分享一起学习。 感谢楼主无私分享经验，少走了很多弯路，对我们帮助特别大。 虽然有些地方不太懂，但整体看完还是收获很多，慢慢消化一下。 看完感觉打开了新思路，以后遇到类似情况知道该怎么处理了。 内容写得很详细，逻辑也很清晰，对新手来说非常友好，支持一下楼主。 逻辑严谨，条理分明，一看就是经过认真思考和整理的内容。 看了这么多帖子，还是觉得你这篇最实在，条理清晰又容易理解。 不仅内容好，语气也很温和，这样的交流氛围真的很不错。 希望楼主常来发帖，持续输出优质内容，我们都会一直支持你。 楼主态度很认真，回复也很耐心，这样的楼主值得大家支持。 每一条都很实用，已经记下来了，以后遇到类似问题就能用上。 支持理性讨论，反对无脑争吵，楼主带了个很好的头。 说得很客观中立，没有偏激言论，理性讨论就该是这个样子。
页:
[1]