问题背景
这类问题常见于业务增长后的前端项目。页面还能跑,但新增需求越来越慢,问题定位越来越依赖个人记忆,最后所有人都怕改公共代码。
字体子集、font-display 和预加载策略要跟设计稿一起定。 这篇文章更关心落地细节:怎么拆问题、怎么写代码或流程、怎么验收,而不是停在概念介绍。
真正耐用的前端方案通常不复杂,但边界会很清楚:哪些数据来自接口,哪些状态属于页面,哪些逻辑可以独立测试,哪些体验需要降级。
推荐做法
- 字体子集、font-display 和预加载策略要跟设计稿一起定。
- 先用 Lighthouse、Performance 面板或线上 RUM 数据确定瓶颈,别凭感觉删代码。
- 把资源体积、主线程长任务、接口瀑布和渲染阻塞分开看,每类问题对应的修法不同。
- 优化后记录前后指标,至少对比同一网络、同一设备、同一路径。
一个可直接借用的片段
const params = new URLSearchParams(location.search);
params.set('page', String(nextPage));
history.replaceState(null, '', '?' + params.toString());
容易踩坑
- 不要为了消除重复就过早抽象,三处相似不一定代表同一个业务概念。
- 不要把后端返回的所有字段原样传到页面深处,字段越散越难维护。
- 不要只在高速网络和新电脑上验收,真实用户环境往往更差。
检查清单
- 是否能说清楚这个改动解决的具体问题。
- 是否有失败、空数据、慢网络或权限不足时的处理。
- 是否留下了后续维护者能看懂的命名和边界。
- 是否用命令、截图或真实页面验证过结果。
好的技术文章不只是告诉你“可以这么做”,还要说清楚什么时候不该这么做。前端工程 的很多经验,真正值钱的部分都在这些边界里。