从这里开始：7 月 19 日晚上十点四十分
2026 年 7 月 19 日晚上十点四十分，我坐在罗湖书城二层靠窗的位子，笔记本电量还剩 23%，浏览器标签页开了 19 个。我点开第 14 个候选入口，页面在半秒内渲染完成，那一刻我确实有点兴奋——因为前面 13 个入口里，有 5 个要么白屏，要么停在加载骨架。
我把这个时间点记在备忘录里：22:43，首屏 0.48 秒，DNS 解析 38ms。这个数字后来成了整张对照表的基准线，也是我决定写这篇反馈的直接原因。
我做这次实测的具体方法
方法是笨办法。我把 37 个候选入口分成四组，每组用同一台设备、同一个网络、同一个浏览器配置，分别记录首字节时间、首屏渲染时间和可交互时间。设备是 MacBook Air M2、小米 14、iPad Air 5，外加两台公司配的旧笔记本和一台公共终端。
最慢的一个入口首屏耗时 4.7 秒，出现在旧笔记本上，浏览器版本是 Chromium 108。我没有修它，只把现象和数据都记下来。这里想插一句：很多人测页面只测最快的那个入口，但真实用户手里的设备是参差不齐的，只报最好成绩等于没测。
关于反馈里反复出现的那几类问题
到 7 月 20 日早上，我一共收到 32 条读者反馈。按关键词粗聚类后，加载速度 11 条，入口有效性 9 条，移动端排版 7 条，内容准确性 5 条。样本不大，但方向是清楚的：大家最在意的还是「能不能打开」和「打开快不快」。
7 月 12 日，徐汇区的陈先生留言说，他 49 岁，用的是一台三年前的安卓机，夜间打开时广告位会遮挡索引列表。这条我单独拎出来说，是因为它指向一个常被忽略的问题：响应式不等于移动端可用。
另外，7 月 15 日下午我复现了两次 PDF 预览崩溃，抓包看到的是 PDF.js 加载器超时。这个和主站入口无关，但既然读者在反馈里提到，我也一并记下来，方便后来人少走弯路。
一个可能有点争议的观点
说实话，我认为「入口越多越好」这个思路被严重高估了。我测的 37 个入口里，真正稳定的不超过 12 个，剩下的大部分是重复路径或者临时镜像。与其维护一堆半死不活的入口，不如把 12 个稳定入口的加载质量再优化一轮。
这个观点在我自己的反馈表里就被反驳过两次，有人说多入口是冗余设计。我接受这个反驳，但仍然保留我的判断：冗余的价值取决于每个节点是否真的可用，不可用的冗余只是噪音。
接下来我准备做什么
接下来一周，我准备把移动端弱网下的同步延迟问题再做一轮复测，目标是给出更细的分段数据，而不是只有一个 8 秒的粗略结论。同时把 32 条反馈里可复现的部分整理成清单，逐条标注复现步骤。
如果你也测过类似的入口，欢迎把设备型号和大致耗时发给我。数据这东西，多一个人测，平均值才更接近真相。