客户说网页打开慢，面试慢排先别急着查代码。客户这问题十有八九是反馈链路问题，不是网页应用问题。我处理过上百起类似工单，打开真正卡在后端逻辑的面试慢排不到三成。

第一步，客户问清楚“慢”是反馈什么概念。是网页首屏白屏要五秒？还是页面加载完但图片半天出不来？这两者排查方向完全不同。我见过最离谱的打开案例，客户抱怨慢了一个月，面试慢排最后发现是客户他自己电脑开了代理。所以先让客户提供浏览器F12的反馈Network面板截图，看具体哪个请求耗时长。网页这一步能过滤掉一半的打开伪故障。

如果确认是服务端响应慢，那就按顺序查三层。第一层查网络，用ping和tracert看客户端到服务器的延迟和丢包率。有个真实案例，客户在新疆，服务器在上海，延迟八十毫秒本来正常，但客户坚持说慢。后来抓包发现是运营商跨网调度问题，TCP三次握手就花了三秒。这层问题你改代码没用，只能换CDN或者加节点。

第二层查接入层。看Nginx的access log和upstream_response_time字段。如果响应时间正常但客户端感知慢，多半是带宽瓶颈或者TCP拥塞控制问题。我遇到过一台服务器带宽跑满，但监控图表显示CPU和内存都空闲，查了半天才发现是某个爬虫在疯狂下载大文件。限个速就解决了。

第三层才轮到应用和数据库。先看慢查询日志，再看应用日志里有没有长时间阻塞的线程。这里有个容易忽略的坑——连接池耗尽。曾经有个电商项目，高峰期数据库连接池被打满，新请求全部排队等连接，表现就是页面转圈十几秒。DBA排查半天没找到慢SQL，其实是连接获取超时。调大连接池上限，加个等待队列就缓解了。

还有个经常被忽略的点——客户端渲染性能。如果接口响应只要200毫秒，但页面在客户手机上渲染要两秒，那就是前端问题。查一下是不是引用了太多大体积JS库，或者图片没做懒加载。这种情况后端工程师容易甩锅，但运维得懂点前端知识才能定位。

最后说个通用技巧。别一上来就查日志，先看监控面板。如果你们有完善的APM系统（比如SkyWalking或Pinpoint），直接看链路追踪，哪个环节耗时占比最高一目了然。没有APM的话，就在Nginx层加个请求耗时日志，配合业务日志的时间戳比对，也能大致定位。

排查顺序总结成一句话：先看网络通不通，再看接入层堵不堵，然后看应用卡不卡，最后看前端重不重。按这个顺序走，百分之八十的问题能在半小时内定位。剩下的百分之二十，多半是玄学——比如某天某个机房光缆被施工队挖断，这种只能靠冗余架构扛过去。