网站访问慢排查：用Chrome F12开发者工具的Network面板分析加载耗时
网站访问慢，先别急着换服务器或加带宽；用 Chrome F12 开发者工具的 Network 面板复现一次加载，按时间轴拆解 DNS、TCP、TLS、TTFB、内容下载，就能判断是网络、后端还是前端资源问题。
先打开 Network 面板并复现一次慢访问
不要只盯着页面转圈。操作路径：Chrome 右上角菜单 → 更多工具 → 开发者工具，或按 F12 / Ctrl+Shift+I / Cmd+Option+I。切到 Network 标签，勾选 Disable cache，保留 Preserve log，在无痕窗口打开目标 URL 更接近首次访问。按 Ctrl+R 刷新，等页面稳定后停止录制。此时底部状态栏会显示请求数、传输量、DOMContentLoaded 和 Load 时间；先记下总请求数和传输量，再点按时间排序或按大小排序。注意：如果页面有跳转，要保留日志，否则第一个文档请求会被清掉。
环节一：把瀑布流拆成加载阶段
在 Network 面板的 Waterfall 列上，把鼠标停在最长的一条上，会看到 Queueing、Stalled、DNS Lookup、Initial connection、SSL、Request sent、Waiting、Content Download。它们分别对应排队、等待连接、域名解析、TCP 建连、TLS 握手、发送请求、等待首字节、下载内容。排查时先找最大段：DNS 长说明解析慢或解析商远；TCP/TLS 长说明连接握手慢；Waiting 长通常指向后端、数据库、CDN 回源；Content Download 长则多半是资源太大或带宽不足。点开某条请求的 Timing 标签，可比悬浮更清楚。若 DNS 段明显，在终端执行 dig example.com NS +short 看权威服务器，执行 dig example.com +trace 看解析路径。
阶段二：按资源类型筛出真正拖慢项
不要被总请求数吓到。先点 Doc 筛选，看主文档的 Waiting 和大小；再点 Img，按 Size 列排序，找几百 KB 到几 MB 的图片；切到 JS 和 CSS，看是否有阻塞渲染的文件；最后看 Fetch/XHR，定位慢接口。Chrome 支持在筛选框输入域名或 larger-than:500k、status-code:404、domain:third-party.com 这类条件。右键列头可以打开 Time、TTFB、Content Download、Remote Address 等列。若勾选 Disable cache 后很慢、取消后正常，问题在缓存策略；若二次访问仍慢，继续查后端和第三方。
流程节点：用请求详情和命令验证瓶颈
单击最慢的请求，先看 Headers：状态码、Request URL、Remote Address、Content-Encoding、Cache-Control、Server、Via、X-Cache 等。若 Cache-Control 是 no-store，每次都要回源；若静态资源没有 max-age 或 ETag，缓存收益差。再看 Timing，把各段耗时抄到表格。要验证服务端时间，可以用 curl：curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://www.example.com/。如果 curl 的 ttfb 高而 Content Download 正常，瓶颈在服务端；如果 curl 正常但浏览器慢，检查扩展、代理、DNS、Service Worker 和并发限制。右键请求选 Copy → Copy as cURL，可以把浏览器请求原样拿到终端复测。
再往后：区分网络、后端、前端和第三方
同一页面在不同网络下表现不同：手机热点、公司宽带、无痕窗口、关闭 VPN 各测一次。若只有你慢，先查本地 DNS、代理和扩展；若多地都慢，查 CDN、回源和服务器负载。主文档 TTFB 高，优先看应用日志、数据库慢查询、PHP/Node 进程和缓存命中率；图片和脚本慢，优先做压缩、WebP/AVIF、合并或延迟加载；第三方统计、客服、字体慢，考虑异步、自托管或直接去掉。对站长和 SEO 来说，首屏资源少而稳，比单个文件小更重要。域名投资者若准备买站，也可以用 Network 面板快速判断目标站是否值得接手。
收尾：把结论写成可验证的修改项
排查完不要只截一张图。按“URL、请求类型、阶段耗时、怀疑点、验证方式、预期改善”记录。优先级通常是：先处理主文档和接口的高 TTFB，再压缩大图与大文件，然后处理阻塞 JS/CSS，最后调整 DNS、CDN 和缓存头。经验上，主文档 TTFB 控制在约 800ms 内、首屏传输量控制在约 1.5MB 内比较理想，但具体以业务和用户网络为准。每次修改后重新打开 Network，勾选 Disable cache 刷新，对比同一请求的 Waiting 和 Content Download 是否下降。若页面仍慢，再用 Performance 面板看主线程和渲染，Network 只负责回答“时间花在哪段”。