打开GitHub看了一圈，网站star数靠前的论文开源CMS项目，issue区里躺得最多的网站不是功能请求，而是论文“怎么把页面加载时间压进一秒”。这事情挺讽刺——我们造了无数框架、网站打包器、论文微前端方案，网站结果用户感知最强烈的论文，还是网站那个旋转的加载圈。

我去年帮一个本地画廊做官网。论文对方预算不高，网站要求倒挺多：要有作品瀑布流、论文虚拟展厅、网站还要接线上预约。论文按老套路，网站React+Node+数据库一套下来，没两个月搞不定。后来我直接上了个静态站点生成器，图片走CDN，预约表单扔给第三方服务。整个项目压缩到三周，上线后Lighthouse跑分接近满分。画廊主不懂技术，他就觉得“网页点开就出图，跟翻画册一样快”。这反而让我想明白一件事：网站开发的本质不是炫技，是交付体验。

技术选型这块，我见过太多人把简单问题复杂化。一个企业展示站，非得上微服务架构，美其名曰“为将来扩展做准备”。结果呢？运维成本比开发成本还高，服务器一崩，全公司抓瞎。倒是有些用WordPress的老站点，靠着一堆缓存插件和良心主机，坚挺地跑了七八年。别误会，我不反对新技术——我自己写Side Project也爱用最新的边缘函数——但商业项目里，稳定和可维护性永远排在“技术时髦度”前面。

真正让我对网站开发改观的，是一次处理图片懒加载的细节。之前习惯性地用第三方库，后来发现浏览器原生loading="lazy"属性已经覆盖了绝大多数场景，代码量直接砍半。这类事情积累多了，你会逐渐形成自己的“少即是多”原则：能写静态页面就不上JS框架，能用CSS解决的就别引动画库，能靠浏览器特性搞定的就别发明新轮子。

当然，过度简化也有翻车的时候。有回贪图省事，用了某个聚合API做数据源，结果对方一个接口变更，整个前端数据层全得重写。自那以后我养成了个习惯：任何第三方依赖都要加一层薄薄的适配器，哪怕多写几个映射函数。这就像家里接电线，直接裸接能用，但套个绝缘管才安心。

写代码的人容易陷入性能指标的执念——首屏必须800ms以内，包体积不能超过200KB。可真实用户在乎的是“我能不能快速找到联系你的电话”。有个做电商的朋友，转化率一直上不去，后来发现是结账按钮颜色跟背景太接近，老年用户根本看不清。这跟技术有半毛钱关系？没有。但这就是网站开发里最考验人的部分：你得同时当工程师、设计师、甚至半个心理学家。

所以现在你看我写代码，经常是半天在调样式，半天在抠数据字段。有人觉得没效率，我倒觉得这才是常态。网站开发走到今天，早过了“能跑就行”的阶段，也过了“性能压榨到极限”的偏执期。它更像一门平衡的艺术——在技术债务、用户体验、业务需求之间找那个微妙的平衡点。那个点找不到的时候，翻翻早期互联网那些纯HTML页面，反而会清醒不少：信息传达到位了，形式简单点，真的没什么不好。

(责任编辑：知识)