提升网站速度开始前需要哪些网站资料：先分清静态资源与动态请求两类处理方案
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /77580393b385.html
📄
提升网站速度开始前需要哪些网站资料：先分清静态资源与动态请求两类处理方案
开始优化前，至少要拿到三类资料：一份可复现的慢速页面清单、这些页面的资源加载记录、以及服务器与缓存配置的读取权限。缺少任何一类，后面的判断都会变成猜测。资料齐全后，再决定是走“前端资源压缩与缓存”这条线，还是走“后端响应与数据库查询”这条线，两条线的适用条件完全不同。
先观察：哪些资料能证明问题真实存在
不要凭感觉挑页面。打开浏览器开发者工具的 Network 面板，勾选 Disable cache 后刷新，记录三个数字：首字节时间（TTFB）、最大内容绘制（LCP）、总请求数。同一页面重复三次取中位数，避免单次网络抖动误导判断。
需要准备的资料包括：
- 慢速页面的完整 URL 列表，优先选首页、列表页、详情页各一个，覆盖不同模板。
- 每个页面的请求瀑布图导出文件，或至少一张截图，标明哪些资源耗时最长。
- 页面当前使用的图片格式、尺寸与体积，以及是否经过压缩。
- 服务器环境信息：Web 服务器类型、是否启用压缩、是否配置缓存头。
判断结果：如果 TTFB 超过 600 毫秒，而其他指标正常，问题多半在后端；如果 TTFB 正常但 LCP 很高，且瀑布图里大图或脚本排在前面，问题多半在前端资源。
再判断：两种处理方案的适用条件
方案一，前端资源优化。适合请求数多、图片未压缩、脚本阻塞渲染的站点。典型特征是瀑布图里同一域名下几十个请求排队，或单张图片超过 300KB。
方案二，后端与缓存优化。适合 TTFB 高、数据库查询慢、动态页面每次刷新都重新计算的站点。典型特征是瀑布图里第一个请求就占了大部分时间，后续资源反而很快。
对比依据是同一份瀑布图：把总耗时拆成“等待服务器响应”和“下载资源”两段。前者占比高选方案二，后者占比高选方案一。如果两段都高，先处理后端，因为前端优化无法弥补服务器响应慢带来的首屏延迟。
假设某详情页总加载 4 秒，其中 TTFB 占 2.5 秒，图片下载占 1 秒。这个例子说明后端是主要瓶颈，应先查数据库查询和缓存配置，而不是急着压缩图片。此判断只适用于该页面的实测数据，不能直接套用到全站。
处理：动手前需要确认的权限与备份
确认你拥有以下任一项操作权限，否则资料再全也无法落地：
- 修改主题模板或前端构建配置的权限。
- 修改服务器配置或缓存规则的权限。
- 在测试环境复现问题的能力，避免直接改动线上。
动手前先备份当前配置与原始资源文件。改动顺序建议：先加缓存头与压缩，再处理图片，最后考虑脚本拆分。每改一项就重新测一次，只保留有正向效果的改动。
复查：改完之后怎么确认没有白做
用同一份页面清单、同一网络条件、同样的无缓存模式重新测量。对比三项：TTFB 是否下降、LCP 是否下降、总请求数是否减少。如果某项没有变化，说明该改动对这条路径无效，应回退而不是保留。
复查时注意区分“可能原因”与“已经定位的原因”。例如 LCP 仍然偏高，可能是图片未压缩，也可能是字体加载阻塞，还可能是服务器响应波动。只有逐项排除后，才能确认是哪一个。不要因为改了一处就断言问题已解决。
下一步：从慢速页面清单里挑一个流量最高、结构最简单的页面，按上面的观察、判断、处理、复查走完一轮。跑通一个页面后，再决定是否把同一方案推广到其他模板。
