从一台 iPad Air 2 的白屏开始的十二分钟
9 月 12 日晚上 21:06,我在旧平板上输入域名,页面白屏 11 秒后跳首页。改 UA、清缓存、换网络都试过,最后发现问题出在重定向链的第三跳。
周二晚上九点,我在一台旧 iPad 上第七次点开同一个地址,白屏停了 11 秒,然后跳回首页。我决定把这件事写清楚。
9 月 12 日晚上 21:06,我在旧平板上输入域名,页面白屏 11 秒后跳首页。改 UA、清缓存、换网络都试过,最后发现问题出在重定向链的第三跳。
同一段 CSS 在两个内核版本下,卡片圆角在一台设备上是 16px,在另一台上直接塌成直角。这不是设计问题,是渲染管线差异。
老周在群里发了张截图,说清了三次缓存页面没变。我看了一眼他的操作顺序,问题很明确:他只清了图片缓存,没动 service worker。
帮小林看她的企业站,移动端打开整体左移。她把 initial-scale 写成了 0.9,页面为了塞满屏幕做了缩放补偿,看起来就像排版崩了。
9 月 15 日下午,我在测试机上抓下载请求,同一个包被分成三段,第三段超时重试两次。用户看到的"下载失败"多半是分段策略太激进。
用 Charles 抓了一遍网页版入口的全过程,重定向跳了三次,每次都重新建立连接。移动网络下这个成本被放大得非常明显。
9 月 10 日晚上,用户在群里问这句话,我回复了四行排查步骤:换网络、清缓存、关省流、看 UA。他回了个"好了",然后没再说话。
2019 年出版,第 4 章说移动端首屏 3 秒可接受。放到今天,加上首屏之外的重定向,这个数字已经偏保守了。
很多人以为小窗只是播放器功能。实际测试下来,它和页面级的媒体会话绑定,网页入口的媒体权限配置会直接影响小窗能不能弹。
模拟器上一切正常,真机上白屏。这个教训我在 2026 年 8 月 27 日又吃了一次,对象是一台中端安卓机,6GB 内存。
2026 年 9 月 12 日,晚上 21:06,地点是我家书房那张掉漆的旧书桌。桌上摊着一台 2014 年的 iPad Air 2,屏幕左上角还有一道细裂纹。我在地址栏里输入了一个我每天要看几十遍的域名,按下回车,然后屏幕白了。不是加载中的那种白,是干干净净、连 favicon 都没来得及出现的白。我数着秒,一秒、两秒……到第十一秒,页面忽然一闪,跳回了一个我根本没打算去的首页。
这件事恼人的地方在于,它无法被简单归因。我当时手里有四个变量:一台老设备、一个移动端浏览器、一次网页版入口跳转、一条我看不见的重定向链。任何一个人站在我位置上,都会本能地想"是不是网络问题",然后重启路由器,然后发现没用。
我把这次排查从头到尾记了下来,因为类似的场景,过去半年我在群里至少见过四十次。
第一件事,是确认它到底是不是网络问题。我打开同一个页面在另一台设备上,正常。换一个网络环境,还是白屏。好了,网络嫌疑排除。第二件事,清缓存。这个过程我在恢复原来的qq浏览器时踩过坑,所以这次特意确认了 service worker 的注册状态,结果是干净的。第三件事,看 UA。旧 iPad 的 UA 被识别成桌面端,服务端返回了一个为桌面端准备的重定向,那个重定向在移动端内核上执行到第三跳的时候卡住了。
这里面有个细节值得单独说:重定向链的第三跳,目标地址带了一个查询参数,这个参数在老内核里会被截断,服务端收到一个不完整的请求,返回 302 到首页。整个链条走完,用户看到的就是"白屏很久,然后回到首页"。这不是某个功能坏了,是一连串小问题叠在一起,把一次简单的打开变成了一场事故。
说句可能不太受欢迎的话:移动端网页入口这类问题,被严重低估了。
很多团队把它当成"基础设施",默认它不会出问题,于是所有精力都投在功能迭代上。但用户第一次接触产品的路径,恰恰就是这个入口。入口跳一次首页,用户对产品的信任就少一分。我见过一个站,网页版入口的重定向写了四跳,每跳平均耗时 800 毫秒,注意,是平均。在弱网环境下,这个数字会变成三到四秒。没有人会为三到四秒的白屏耐心等待,他们会直接关掉。
第一个观察关于缓存。9 月 22 日,老周在技术群里发了一张截图,说他清了三次缓存,页面还是旧的。我让他把操作过程一步步发出来,发现问题在于他只清了图片缓存,没有处理 local storage 里的版本标记。页面加载时读到了旧版本标记,于是走了旧逻辑。这件事说明,"清缓存"在用户认知里是一个动作,在技术上却是五六个不同的动作,界面把它们藏在同一个入口后面,本身就是一种误导。
第二个观察关于安装包与下载。9 月 15 日下午,我在测试机上抓了一次下载请求,一个 87MB 的安装包被拆成三段,第三段在弱网下超时重试两次。用户看到的提示是"下载失败",但实际上下载只差最后 6%。这个问题在下载最新版49图库app的场景里被反复提到,本质和入口跳转是同一类毛病:失败点藏在链路中间,用户只能看见结果。
第三个观察关于设置项。很多人找不到关闭省流模式、切换内核、管理网站权限的地方,于是把所有疑难杂症都归到"这浏览器有问题"。我在qq浏览器设置在哪里找这件事上花过整整一个下午,把设置层级画成了一张图,才发现关键项被折叠在两级菜单之后。折叠本身没错,错在没有人告诉用户它在哪。
「判断一个移动端入口是否健康,不要看它成功时有多快,看它失败时有多诚实。」——这是我自己记在工作笔记扉页上的一句话,写于 2026 年 8 月 27 日。
说回那台旧 iPad。最后的解决办法并不复杂:服务端识别到老内核的 UA 时,不再走三跳重定向,而是直接返回一个简化版页面,前端再按能力分级加载。改完那天晚上,白屏时间从 11 秒降到了 1.9 秒。我把这个数字记在了本子上,旁边写了一句"还远远不够"。因为 1.9 秒在弱网下依然会变成五秒以上,而用户不会等五秒。
我真正想说的是,这类问题不该由用户去发现。
用户不知道什么是重定向,不知道什么叫 UA 识别,也不该知道。他们只知道一件事:我点开了,页面没出来。把这句话翻译成技术语言,是产品、前端、服务端、运维四个环节的共同责任。过去半年我做的所有记录,本质上都是在做这件事的翻译工作。比如视频小窗和入口的媒体权限关系,比如qq浏览器视频小窗口在网页版场景下为什么有时弹不出来,比如某些图库页面在弱网下的加载失败该怎么定位,这些在新奥门4949图库显示加载失败这类现象里反复出现,我逐一记下来,是因为相信记录本身有价值。
还有一个细节我到现在没想明白。9 月 12 日那天,白屏的第十一秒,页面跳回首页的那一瞬间,我听见设备里有一声很轻的"咔",像是某个加载被强行中断。我反复试了六次,只有两次能听见。这可能只是错觉,也可能是旧设备在某种资源竞争下的真实反馈。我不确定,所以写在这里,留个记录。
现在这个页面本身,用的是我在qq浏览器网页入口下载那篇记录里整理出来的一套加载策略:首屏优先、分级加载、重定向能省则省。不完美,但至少我能保证,它不会让任何人盯着白屏数到十一秒。
写到这里,气消了一大半。剩下那一小半,留给下次白屏的时候再用。
我叫江晚,做前端开发和移动端性能排查已经九年。白天在一家做工具类产品的公司上班,晚上和周末维护这个站。
这个站最早只是我的工作笔记,2023 年 4 月第一次整理成可以公开阅读的形式。起因很简单:同样的问题,我在群里回答了不下五十遍,与其每次重打一遍,不如写下来,给一个能被检索到的地址。
我写东西偏慢,喜欢把过程记全,包括那些最后被证明是错误判断的枝节。因为我相信,排查问题的方法比结论更值得被传下去。
如果你也遇到过一个白屏数到十一秒的晚上,欢迎把过程发给我。我不一定回得很快,但每一条都会看。
「用户不会告诉你重定向哪里错了,他们只会关掉页面,然后去别的地方。」—— 摘自《移动 Web 性能优化(第 2 版)》,第 4 章第 3 节,2021 年,机械工业出版社