网站打开速度慢：图片、脚本与服务端的排查顺序
“打开慢”其实是三种不同的问题
同一个网站，市场同事说首页等太久，销售说手机上图片刷不出来，客服说点进产品页要愣一下。这些反馈听起来都是速度问题，实际卡住的地方却完全不同。首屏长时间白屏，通常卡在服务端响应或首屏必须加载的脚本；页面框架已经出来、图片一张张往下掉，多半是图片体积和加载顺序造成的；点导航后出现停顿，可能是页面本身资源过重，也可能是列表接口在等数据库。
如果不对这三类情况分别处理，讨论就会变成“要不要升级服务器”，而升级服务器只能解决其中一类。
按四层拆：从资源到服务端
第一层：资源体积，图片和字体占大头
企业官网里体积最大的文件，往往就是横幅图、产品图和应用截图。设计稿导出的原图直接上传，单张两三 MB 并不少见，一个页面放七八张，在移动网络下自然慢。字体文件是第二个容易被忽略的体积来源：中文字体动辄几 MB，为了几个标题字加载整套字体并不划算。
第二层：请求数量与渲染阻塞
页面头部的样式表和同步脚本会挡住渲染，浏览器必须等它们下载并执行完，才会绘制第一屏。统计代码、客服插件、在线表单、地图组件，每加一个都会多几次外部请求，其中任何一个响应慢，都会拖住整页。这类问题的特点是：本地测试很快，线上偶尔很慢，因为外部服务不在自己控制范围内。
第三层：服务端响应与网络
首字节时间偏高，说明请求到达服务器后，程序处理或数据库查询花了时间。常见于未加缓存的列表页、每次访问都实时查询的首页，以及配置偏低的服务器。这一层要看的是响应时间随访问变化的情况，而不是 CPU 占用率这类瞬时数字。
第四层：页面结构与前端实现
同样的内容，如果 DOM 层级过深、首屏一次性渲染几百个节点、滚动监听频繁触发重排，都会让中低端手机明显卡顿。这类问题在电脑上几乎看不出来，需要真机验证。
怎么定位：先量，再改
- 用浏览器网络面板录制一次完整的首屏加载，按耗时排序，找出体积最大和耗时最长的前五个请求。
- 看时间轴上的关键节点：首字节时间、首次内容渲染、完整加载，判断慢在服务端还是在前端。
- 用手机网络模拟重跑一遍，移动端常见的瓶颈通常在这一步才暴露。
- 把第三方脚本逐个临时禁用，对比加载时间，确认是否有外部组件拖慢了速度。
- 在生产环境复测，而不是在本地环境，因为本地没有网络延迟和真实并发。
这套流程下来，多数网站能定位到两三个具体原因，而不是一句笼统的“性能不行”。
处理顺序：先做改动小、收益明确的
- 图片：按展示尺寸导出，压缩后再上传；首屏之外的图片延迟加载。这一项通常收益最大、改动最小。
- 字体：只保留实际用到的字重，或用系统字体替代装饰性字体。
- 脚本：非关键的统计、客服、地图改为异步或延后加载，避免阻塞首屏。
- 缓存：给静态资源设置合理的缓存策略，首页数据做短周期缓存，减少重复查询。
- 服务端：在完成上面几项后仍偏慢，再评估服务器配置、数据库索引和接口合并。
如果顺序反过来，也就是先增加配置再优化资源，经常是钱花了，用户感知却不明显。
适用的边界
并不是所有慢都值得投入。访问量很小的内部系统、使用频率极低的后台页面，优化收益有限。反过来，以获客为目的的官网首页、投放落地页，以及移动端访问占比高的页面，加载时间的改善能直接体现在跳出率上，值得认真做。
速度优化也有上限：受用户所在网络、运营商线路、第三方服务稳定性影响，任何网站都无法保证在所有环境下都快。合理的目标是让多数用户在常见网络条件下，首屏能在可接受的时间内出现，而不是追求测试工具上的满分。