首屏变慢主因常是网络层等待而非代码：DNS解析延迟、TLS握手过长、缓存策略失效或Service Worker污染。应依次用dig/nslookup查DNS、DevTools Timing看SSL与DNS耗时、curl比对响应头、清空SW与Cache Storage定位问题。
查 DNS 解析是否拖慢首屏
切换服务器后用户访问变慢，第一怀疑对象不是代码，而是 dns。新服务器的域名解析可能没生效、用了低质量递归 dns、或本地缓存了错误的旧 ip，导致浏览器卡在 dnslookup 阶段。
实操建议：
- 用
dig your-domain.com +trace或nslookup -debug your-domain.com看解析链路和耗时，重点看权威 DNS 返回是否及时、TTL 是否合理 - 浏览器开发者工具 Network 标签页中，找任意一个静态资源（如
main.js），看 Timing 里的DNS Lookup时间——超过 100ms 就值得怀疑 - 确认 DNS 记录已全球生效：用
https://dnschecker.org查多地解析结果，别只信本地ping或curl - 若用 CDN 或 LB，确保 CNAME 指向的域名本身 TTL 不过长（建议 ≤ 300），否则 DNS 变更后用户端要等很久才更新
确认前端资源是否命中缓存
服务器切完，但 HTML 是新的，而 JS/CSS/图片仍走旧缓存路径，可能加载失败或回退到慢源；也可能因缓存策略突变（比如新服务器没配 Cache-Control），导致所有资源都重新拉取。
实操建议：
- 打开 Network，筛选
js、css、img，看每个请求的 Response Headers 中是否有Cache-Control，值是否含max-age或immutable；状态码是200还是304 - 对比新旧服务器返回的同一资源响应头：用
curl -I https://new.example.com/app.js和curl -I https://old.example.com/app.js直接比对 - 检查构建产物是否带哈希（如
app.a1b2c3.js）：没哈希就靠Cache-Control续命，一旦配置漏掉，用户会卡在旧缓存里不动 - 注意
index.html本身通常不该强缓存（应设为no-cache或短max-age=60），否则 HTML 更新了，但浏览器还在用本地老 HTML 加载旧哈希资源
看 HTTP/HTTPS 协议与证书握手是否拖慢
新服务器如果 HTTPS 配置不完整（比如缺 OCSP Stapling、用弱 cipher、证书链不全），TLS 握手时间可能从 50ms 拉长到 300ms+，尤其在移动端更明显。
立即学习“前端免费学习笔记（深入）”；
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
实操建议：
- 用
openssl s_client -connect your-domain.com:443 -servername your-domain.com检查证书链是否完整、是否支持ALPN（HTTP/2 必需） - 在 Chrome DevTools 的 Network → Timing 中，展开任意 HTTPS 请求，看
SSL阶段耗时；若 > 200ms，大概率是服务端 TLS 配置问题 - 用
https://www.ssllabs.com/ssltest/扫描域名，重点关注 “Handshake Simulation” 里各客户端的协商结果，特别是 iOS 和 Android 老版本是否 fallback 到 TLS 1.0 - 确认 Nginx/Apache 是否启用了
ssl_buffer_size 4k（小包优化）、ssl_session_cache（复用 session），这些不配齐，每次刷新都重握手
排除 Service Worker 或本地存储污染
前端用了 PWA 或自定义缓存逻辑，切服务器后旧 Service Worker 仍在控制页面，它可能把请求代理到已下线的旧 API 地址，或从 cacheStorage 返回过期资源，造成白屏、接口 502、样式错乱等“卡顿假象”。
实操建议：
- Chrome DevTools → Application → Service Workers，勾选
Update on reload，再硬刷；或点Unregister彻底清除 - 检查是否误将 API 基地址写死在
localStorage或sessionStorage中（比如存了API_BASE: "https://old-api.com"），切服后前端仍往旧地址发请求 - 在 Console 运行
caches.keys().then(keys => keys.forEach(key => caches.delete(key)))清空所有 Cache Storage（仅调试用） - 若用 Workbox，确认
sw.js版本号已更新，且skipWaiting()和clients.claim()已调用，否则新 SW 永远不会激活
真正卡住的地方，往往不在 JS 执行，而在网络层看不见的等待——DNS、TLS、缓存协商、SW 控制权交接，这些环节一堵，用户看到的就是“转圈不动”。盯着 Network 的 Timing 面板逐段看，比改代码更管用。
