一、到底为什么要重做？老网站的那个德性我受够了
这Inari的官网，不是我第一次搞了。上一次做的那个静态页面，当初图方便，随便找了个模板套上去。用了大概一年半，毛病就开始往外冒。最恶心的是什么？它不是一直坏，它是随机性的，隔三岔五就给我吐个500报错。我大半夜接到群里的消息，说网站又崩了，我得爬起来远程登录进去看看是不是哪里CSS文件没找到，或者哪个图片路径又走错了。
这种被动挨打的日子，我是真的一天也过不下去了。你不能指望一个不稳定的门面去谈什么品牌形象，那简直是笑话。我直接下定决心，把老网站全部推倒，代码一行都不留，重新弄一套稳定的、快速的，最关键是——能让我睡个安稳觉的系统。
二、推倒重来，选一套不折腾的技术栈
我真想用回Java或者Python搞个后台管理系统，这样起码数据是活的，管理起来也方便。但一想到要搭数据库、配服务器、还要搞复杂的安全配置，我的头就开始疼。我的业务逻辑压根儿没那么复杂，大部分内容都是固定的，我瞎折腾什么？我现在追求的就是一个字：快。然后是两个字：免费。是三个字：少操心。
-
技术选型：我研究了现在流行的那些轻量级框架，什么“岛屿架构”听起来很唬人。我拉过来那个叫Astro的框架试了一下。好家伙，确实快，编译速度跟飞似的。而且它可以让我把前端组件拆得很碎，需要交互的地方才加载一点点JavaScript，不需要的就直接是纯HTML。我一拍大腿，就它了，最大限度避免后端扯皮。
-
部署平台：以前我都是自己买个阿里云学生机，抠抠索索地跑。这回我直接放弃了。我研究了一下，现在做静态托管，要么上Vercel，要么上Cloudflare Pages。我选了后者。为我的主力域名解析就在它家，操作方便，而且带宽流量给得足。关键是，真的不用花钱养服务器，能省下不少饭钱，这对于我们这种小本经营的团队来说太重要了。
三、动手动脚，把设计稿变成代码
我的习惯是，先把内容架子搭建然后再往里面塞肉。我抓起Sketch里的设计稿，开始一页一页地切图、堆组件。我得说，从头写CSS简直就是给自己找罪受。尤其这回要做响应式，得让手机端看着也舒服。我光是调试那个导航栏在不同屏幕尺寸下的收缩动画，就折腾了整整一个下午。我对着手机屏幕上那些错位的按钮，差点没把键盘给砸了。
最要命的是图片优化。新网站上有很多高清产品图，如果不处理，加载速度肯定慢得跟蜗牛一样。我翻出之前整理的图片处理脚本，把所有的产品图都批量跑了一遍，统一转成WebP格式，这样大小能压到原来的三分之一。然后我才敢把它们塞进代码库里。
我当时还遇到个怪事。我把网站部署上去，本地跑得贼顺滑，结果一上线，发现某些组件的交互代码没有被打包进去。用户点按钮没反应。我翻阅了半天Astro的文档，才发现是配置里的一个标记位我给漏了。那个标记位决定了某些组件在浏览器端是否需要水合（hydration）。那一下午，我感觉自己的头发都快掉光了。这种低级错误，我以前也犯过，但每次遇到都想骂人。
四、上线收工，终于能睡个安稳觉了
花了大概三天半的时间，从零开始搭架子，到内容填充完毕，再到的测试收尾。我确认所有页面跳转都对，所有图片都能秒开。我用好几个不同地区的节点跑了测速，结果相当满意。
一步，我把域名解析的指针指向了新的托管地址，然后按下了那个上传按钮。整个切换过程非常顺利，几乎没有停机时间。新的Inari官网，速度确实没得说。用我那台十年前的旧笔记本打开，也是唰的一下就出来了。这才是用户体验！
老实说，这回更新日志写得这么简单，但背后花的精力，只有我自己知道。但我这个人就是这样，喜欢把折腾的过程记录下来，也算是给自己一个交代。现在最大的好处是，再也不用担心半夜被报错电话吵醒了。这比什么都强。