网站访问速度慢怎么排查：先量测再改图片与脚本
网站打开慢，第一反应往往是“服务器不行”或者“图片太大”，但这两个猜测都可能猜错。更稳妥的顺序是先量测、再定位、后动手，否则容易在错误的方向上白花时间：图片压缩了一整轮，结果瓶颈在第三方脚本；服务器升了配置，结果首屏卡在一个没做懒加载的轮播图上。
第一步：把“慢”拆成可以测量的几段
用户说的慢，可能指打开页面时白屏时间长，也可能指点击导航后要等两三秒才切换，还可能是后台编辑保存一直转圈。这几种“慢”对应完全不同的原因，先问清楚具体场景再动手。
浏览器加载一个页面，大致经过：建立连接、服务器返回 HTML、下载样式脚本和图片、浏览器渲染。用浏览器开发者工具的网络面板看请求时间线，或者用线上测速服务从多个地点测同一地址。判断时重点看三个数：
- 服务器响应时间：如果长期偏高，先查后端和数据库，不要急着改前端。
- 资源总体积与请求数：图片、脚本、字体各占多少，请求一共多少条。
- 首屏渲染完成时间：用户真正看到内容的时间，而不是全部资源加载完的时间。
容易遗漏的检查点：改前改后要在同一网络环境下测，并记录数字；只在办公室的宽带下测，往往看不出问题；还要区分首次访问和再次访问，后者有缓存，数据会好看很多，容易让人误判。
不是所有页面都要改：先排优先级
整站逐页优化成本很高，通常先处理三类页面就够了：
- 首页和主要落地页——访问量大，第一印象在这里形成。
- 承接推广流量的页面——用户从外部点进来，等待时间越长流失越多。
- 需要用户填表或下单的页面——交互响应慢会直接影响提交。
列表页、详情页可以排在后面，但要注意它们常常共用同一套模板和同一批组件，改一处会影响很多页面，动之前先确认影响范围。
第二步：图片通常是最大的一块，但要按顺序改
多数企业站的图片占了页面体积的一半以上。处理图片不是简单“全部压一遍”，按下面的顺序做返工最少：
- 先看图片的实际显示尺寸。页面上只显示几百像素宽的位置，不要上传手机原图。
- 再选格式。照片类用 JPEG 或 WebP，图标和纯色图形用 SVG，透明背景用 PNG 或 WebP。
- 然后压缩，保留视觉可接受的质量，优先处理首屏那张大图。
- 最后加加载策略。首屏图正常加载，屏幕外的图用懒加载，避免一打开页面就把几十张图全拉下来。
常见的坑是“压完看着糊了”。判断标准不是文件大小，而是实际显示尺寸下的观感：在手机上放大看主体细节，如果边缘出现明显块状，就把质量参数调回来。另外，后台如果允许编辑自行上传图片，最好同时限制单张大小和尺寸，否则内容同事每次上传原图，优化成果很快被抵消。
第三步：查脚本与第三方服务
统计代码、在线客服、地图、视频播放器、字体库、营销插件，单看都不大，叠在一起就可能拖慢首屏。判断方法很直接：在网络面板按体积排序，看前十条里有多少来自第三方域名。
处理思路是先问“是否首屏必需”。客服悬浮窗、统计脚本通常可以延后加载；地图等用户点击“查看位置”时再加载；视频用封面图代替自动播放；字体文件太大，就只保留实际用到的字重，或改用系统字体。
检查点：调整加载方式后要回归测试相关功能，比如表单能否提交、在线咨询是否还能弹出、统计数据是否仍有记录。变快了但坏了，是这类优化最常见的事故。
第四步：缓存、压缩与分发
前三步做完仍慢，再看传输环节。静态资源设置合理的浏览器缓存，让回访用户不用重复下载；服务器开启传输压缩；有条件的话把静态资源放到 CDN 上，让不同地区的用户从较近的节点获取。
这里的边界要说清楚：CDN 解决的是距离和并发，解决不了代码本身写得重。页面一次加载大量脚本，分发再好也快不起来。另外缓存策略改错会让用户看到旧页面，更新静态资源时要用文件名或版本参数区分。
第五步：服务器与数据库
当服务器响应时间稳定偏高，或者后台操作明显卡顿，问题多半在服务端。先分清是持续慢还是高峰慢：持续慢可能是配置不足或慢查询，高峰慢更像并发或资源争用。可以查慢查询日志、确认索引是否缺失、看看有没有定时任务和备份正好跑在业务高峰。
不建议一上来就升级配置。先确认是不是某条查询没走索引，或者某个页面每次请求都在重复算同样的数据。升级能缓解症状，但只是把问题往后推。
改完怎么验证，以及优化的边界
改完要回到第一步的量测方式重测一遍：同样的工具、同样的网络、同样的页面，对比改前改后的数字。还要在真机上走一遍主要流程——首页、列表页、详情页、表单提交。速度优化最容易出的问题是“变快但坏了”，比如懒加载导致打印或截图时图片不显示，延后加载的脚本导致统计丢失。
也要接受优化的边界：功能复杂度决定了下限，一个带高清视频和大量交互的页面不可能和纯文字页一样快。目标是让用户感觉顺畅、关键内容尽早出现，而不是在跑分工具上拿满分。为了分数删掉必要的功能或内容，是本末倒置。