首屏加载慢怎么优化？从资源压缩到关键渲染的排查步骤
首屏加载慢，先不要急着加带宽或换服务器。
多数站点首屏慢集中在两类原因：一是资源体积大、传输链路慢；
二是CSS和JS阻塞了浏览器渲染。
用浏览器开发者工具看一次瀑布图，基本能判断先动哪里。
下面按“测量—压缩传输—解除阻塞—验证”的顺序给出可执行步骤，适用于常见的Nginx+静态资源站点。
先测出首屏时间花在哪
打开Chrome开发者工具，切到Network面板，勾选Disable cache后刷新页面。
重点看三个指标：
- FCP（首次内容绘制）：首屏第一块文字或图片出现的时间，这是用户感知“打开快不快”的关键。
- LCP（最大内容绘制）：首屏最大元素（通常是头图或大标题）渲染完成的时间。
- 瀑布图里的长条：哪个请求耗时最长、哪个资源阻塞了后续请求。
如果最大的请求是图片，先做图片压缩；
如果是HTML或CSS响应慢，先查服务端和缓存；
如果请求数很多且排队，考虑合并或预加载。
记录下优化前的FCP和LCP数值，后面用来对比。
压缩图片和文本资源
图片通常是首屏体积的最大来源。
用identify（ImageMagick）查看图片尺寸，按实际展示宽度压缩，不要直接上传相机原图。
# 查看图片信息
identify -format "%f %wx%h %b\n" *.jpg
# 批量把宽度限制在1600px，质量85，转为渐进式JPEG
mogrify -resize 1600x\> -quality 85 -interlace Plane *.jpg文本资源方面，在Nginx中启用Gzip或Brotli压缩。
以Gzip为例，在nginx.conf的http块或站点配置中加入：
gzip on;
gzip_min_length 1k;
gzip_comp_level 5;
gzip_types text/css application/javascript application/json image/svg+xml;改完执行nginx -t检查语法，再nginx -s reload生效。
注意不要对已经压缩过的JPEG、PNG、MP4重复开启Gzip，收益很小。
让静态资源走浏览器缓存
首屏重复访问慢，常见原因是每次都要重新下载CSS、JS和字体。
给带哈希指纹的静态文件设置长期缓存：
location ~* \.(css|js|png|jpg|jpeg|gif|svg|woff2)$ {
expires 30d;
add_header Cache-Control "public, max-age=2592000, immutable";
}HTML文件不要设长缓存，否则用户看不到更新。
可以用expires -1或Cache-Control: no-cache让浏览器每次校验。
验证方法：刷新页面后在Network面板看静态资源的Status是否显示200 (from disk cache)或304。
处理阻塞渲染的CSS和JS
浏览器遇到同步的
defer表示下载不阻塞解析、在HTML解析完后按顺序执行；async表示下载完立即执行，适合独立脚本。
首屏关键CSS建议内联到，其余样式异步加载。
改完后用Lighthouse的“Eliminate render-blocking resources”项复查。
验证效果与常见误区
优化后回到Network面板，清缓存重新加载，对比FCP和LCP是否下降。
如果FCP没变，检查首屏HTML是否本身过大或服务端响应慢；
如果LCP没变，重点看首屏大图是否仍过大或未预加载。
常见误区：只压缩了图片却忘了开启文本压缩；
给HTML设了长缓存导致更新不生效；
把关键CSS也改成异步加载，反而造成首屏样式闪烁。
每次只改一类配置，改完立即验证，出问题可以快速回滚。
首屏加载慢的优化不是一次到位，按测量结果逐项处理，比盲目换服务器更有效。
