一轮体验修补：让网站用起来更顺手

事情的起因是推文整理。我把过去备份的推文筛选之后导入到了博客的笔记区，一下子多了两百多条内容。导入之前首页加载一直挺流畅的，但这两百多条进来之后，明显感觉到首页变卡了——打开时卡片先刷出来一大片，日历却要等好一阵才出现，整个页面像是在一块一块地拼装。

这让我意识到，之前"所有内容全量加载"的方案已经扛不住了。除了首页卡顿之外，我还注意到文章列表里偶尔有卡片因为标题太长而撑得特别高，打破了整体节奏；主题页面的分割线也是有的有、有的没有，看着不统一。

既然要动首页，不如把这些积攒的体验问题一并处理掉。于是开启了这一轮集中修补。

首页为什么打开那么慢

一开始以为是动画或者脚本写得不好，排查之后发现根本不是那回事——问题出在页面本身太大了。当时整个首页导出的文件大概有两三兆，所有内容一股脑全塞在里面，浏览器光解析就要花不少时间。日历排在最后面，自然就最后才出现。

知道原因以后，思路就清楚了：不需要一次展示所有内容，先显示最近的四十条就好，之后每次点"查看更多"再多加载一批。改完以后，首页文件大小从两三兆降到了两百多K，打开时那种"先闪一大片再慢慢拼装"的体感基本消失了。

日历跳转：一个看似简单实则棘手的功能

首页不再一次性加载全部内容之后，新的问题来了——如果用户点了日历上某个日期，但那天的内容还没被加载出来怎么办？

直觉上觉得不难：先把对应的内容加载出来，再跳过去就好了。但实际操作的时候发现一个时序问题：内容加载需要时间，如果加载还没完成就立刻去跳转，会找不到目标位置。最后的办法是先记住"要跳到哪里"，等内容真正出现在页面上之后再执行跳转动作。这种"先记后跳"的模式虽然不复杂，但如果一开始没想到，很容易在这里卡住。

笔记页面也做了类似的改造——一次先显示十条，之后每次多加载五条，但保留了完整正文而不是只给摘要。笔记毕竟是用来认真读的，只展示开头几行没什么意义。

阅读顺序的小陷阱

改布局的时候还碰到一个有意思的事。之前首页用的是一种"瀑布流"排列方式，内容从上到下填满一列再流到下一列。视觉上挺好看，但阅读顺序是从上到下、再从左到右——也就是说你读完左边一整列才会接到中间那列。

这对全量展示没什么问题，但分批加载的时候就别扭了：你点"查看更多"，新内容可能出现在第一列底部而不是最后一行下方，和心理预期完全不符。所以最终把首页和文章列表都改成了"先横后纵"的网格排列——每一行从左到右排满三个再换行，更符合"往下翻"的习惯。

主题页面的视觉混乱

主题页面的问题比较典型：分割线有两套规则在同时生效，一套是容器级别的，一套是每个条目自己加的。两套规则叠加的结果就是有些地方线多了，有些地方又没有线，看着很乱。

解决方法其实很简单——只让一方负责就行了。最终统一由容器来控制分割线，每个条目只管自己内部的内容，不再各自加边框。道理不复杂，但在样式一层层叠加的过程中，很容易不知不觉就搞出这种"双重管辖"的局面。

顺带还给主题里的书单补齐了几本已经写过读后感的书，按年份做了分区标题，让内容和结构对应得更清楚。

构建过程中的"幽灵报错"

这轮改动过程中，构建工具好几次报出莫名其妙的错误——说找不到某个页面模块。查来查去发现和我改的代码完全没关系，重新跑一次就好了，过一会儿又可能再冒出来。

这种间歇性问题很考验判断力。如果把它当成自己写出来的 bug 去排查，会浪费大量时间；但如果完全忽视，万一真有一次是代码问题又会漏掉。最后的策略是多跑几次确认它确实是随机出现的，确认后继续专注在功能验收上，不被干扰。

几点感悟

这轮工作让我印象最深的有三件事。

第一，性能问题要先搞清楚瓶颈在哪，不要上来就猜。这次如果凭直觉去优化动画或者压缩图片，完全是在浪费时间——真正的瓶颈是页面体积太大。

第二，看起来很小的布局决定（比如"先横排还是先竖排"）会在特定场景下产生意想不到的影响。这种事很难提前预见，只有在实际使用中才能发现。

第三，像主题页书单这样的内容区域，不能建好就不管了。随着文章不断积累，内容之间的链接关系也需要持续维护，否则信息结构会慢慢散掉。