我关注的手机QQ浏览器在线打开

昨天下午三点十七分，我坐在小区东门那家叫「行知」的咖啡馆靠窗位置，把 Redmi Note 12 放在杯垫上，用手机QQ浏览器依次打开了三个页面：一个是某视频站的详情页，一个是本地图书馆的检索页，另一个是我自己上周做的静态页。我用秒表记时，第一个页面白屏到可交互花了 4.8 秒，第二个 1.9 秒，第三个 0.7 秒。差距之大让我愣了一下，因为这三者在我笔记本上的表现几乎看不出区别。

这不是一个评测。我没有跑分，没有录屏，也没有做对照组。我只是在写这个站的过程中逐渐发现，「手机QQ浏览器在线打开」这件小事，牵出的其实是移动端渲染、缓存策略和用户耐心三者之间的一场不对称博弈。我原本打算写一篇关于页面加载优化的笔记，结果写到这里，注意力被另一件事吸走了：为什么同一款浏览器，在不同页面上表现得像两台不同的设备。

先给结论：我认为问题主要不在浏览器本身，而在页面把多少工作推给了客户端。这个判断有点武断，我会在下面把依据摊开，也会提到一个我至今没想通的例外。

说句可能不太受欢迎的话：在移动端，对「在线打开」体验伤害最大的，往往不是浏览器，而是页面作者对性能预算的漠视。我知道这句话会被一些同行读成推卸，因为浏览器内核确实有它该背的锅。但这次实测里那 4.8 秒的构成，七成以上能归到页面自身的资源决策上——字体、大图、第三方脚本、未压缩的 CSS。手机QQ浏览器只是那个把结果如实呈现出来的容器。

另一个让我失望的地方是，我原本想找一份公开的、针对手机端「在线打开」场景的性能基线数据，翻了半天没找到足够新的。能查到的多是三四年前的报告，样本也偏桌面。这类基础设施级的数据缺口，比单个页面的慢更值得在意。于是这篇笔记只能退回到个人观察，样本小，结论也谨慎。

收获是意外的：老周那句「在等浏览器帮你做决定」比任何优化清单都更贴近本质。一个页面写得好不好，很多时候就看它给了浏览器多少不必做的决定。这个判断不够精确，但我愿意先把它放在这里，等以后有更多实测再来修正。