去年，有位开发者设计了一个填字游戏 wordle，取得了巨大的成功，最后被纽约时报斥资百万收购。就像众多成功产品一样，wordle 也有很多追随者和模仿者，其中就包括我们做的 mywordle.org。
刚上线时，因为优化得当，排名不错；如今，随着 wordle 游戏的关注度消退，这个产品已经趋于平静，访问量跌入谷底。于是写篇文章总结下技术、产品、运营方面的经验得失。
技术向
技术栈
之前发过笔记：使用 Vite+Vue3+TypeScript+Tailwind CSS 开发 Wordle。
- Vue3 + Vue-router + Vuex
- Vite
- TypeScript
- TailwindCSS
- 骨架屏
- nginx
- i18n （编辑本地 json）
- PWA
纯静态页面，通过构建脚本一次性发布，后面就不需要服务器运算，只需要 CDN，运维成本很低，容易扩展。
前端通过适当的分包实现按需加载，加快打开速度，提升用户体验。实际效果不错，搜索排名和留存都相当好。Lighthouse 一度基本满分。
挑战0：全新技术栈
项目启动时，Vite、Vue3、TypeScript 的内容不算很多，技术生态也没有完全适配，花了不少时间去学习。不过好在当时有时间，慢慢也捋顺了，虽然有一些问题到今天也没能妥善解决，但并没有影响整体进度。
挑战1：多语言多模式共存
当时存在两个模式：
- hourly，每小时一个词
- unlimited，随便玩
以及十几种语言。因为我们是静态网站，想实现 /:lang/:type 和 /:type/:lang 共存，就要同时打包这么多组目录组合。如果将来又增加其它类型，就还要成倍增加。但是几个目录里的内容又是完全一样的，很浪费。
现在想想，应该通过 nginx 来解决这个问题，不要放在前端构建脚本端。
挑战2：WebRTC
我们准备尝试用 WebRTC 实现多人对战，如果能成的话，将来还有很多应用场景。可惜 WebRTC 比我想象中复杂很多，不是抽点时间看看文档就能搞定的。当时我已经开始在 code.fun 的全职工作，时间不如启动时充足。
于是此功能最终停留在 demo，未能整合进产品，更别提上线。
未解决问题
import类型的时候必须import type { xxx } from '@/some/types'，经常出错- TailwindCSS 添加新样式时无法即时生效，需要等下一次更新，或者手动刷新页面
- ESLint 有很多误报，主要是
<script setup>导致的未使用变量问题
产品/运营向
原始版 wordle 一天只能猜一次，一个词。很多玩家感觉不过瘾，所以搜索 wordle unlimited 就很多，我们也是那会儿做好，然后优化得当，排名很靠前，Google 前4（最好前3），吃了不少流量。
但是很快，wordle unlimited 的搜索量就下降了，到现在跌了90%，只有一成。
这部分流量流去了 quodle 关键词，还是这个猜词游戏，但是一次猜 4 个词，更考验技巧和统筹能力。
有趣的是，quodle 主流分两个模式：daily 和 practice。daily 还是一天一次，用的是高频词，比较好猜；practice 相当于我们做的 unlimited，不限次数，但是，用的是全部词库，几乎猜不到。
本来有两个方向，quodle 和 pvp，我说服朋友搞 pvp：我说 quodle 这种玩法太硬核了，没人爱玩；pvp 用 WebRTC 搞联机，成本低效果好，用户粘性大。结果还是我的锅，以前没搞过 WebRTC，搞了两周没搞出来，工作一忙就扔掉了……
总结，wordle 是个比较轻量的游戏，玩法简单，可玩性有限。daily 模式可能更合适；unlimited 有些饮鸩止渴，快速消耗掉了玩家的热情。quodle 的开发者注意到这一点，一方面提供新的玩法刺激用户，另一方面利用全量词库难以游戏的特点尽量将玩家留在每天一次的游戏里。
总结
从这个项目中，我学到很多技术之外的知识，产品和运营方面都刷新了我的知识边界、扩展了我的视野，很有意思。
比如，mywordle.org 是纯静态网站，运维只需要 CDN，加上优化得当，费用很低。凭借早发优势和一些 SEO，流量和广告收入都不错。即使以我的工资标准和开发习惯（动不动重构、选择新技术栈，等）来支付开发费用，也能达到不错的收益结果（目前折算 1/3 吧）。后期收入虽低，但很稳定，也不需要继续投入研发成本，而且还能作为高质量搜索导入来源。以后我应该多做几个类似的网站。
项目启动时，我刚被金山开除，于是可以投入大量的时间去学习使用没接触过的技术栈；后面开始继续全职工作了，就只有一点时间可以支配，以至于 WebRTC 都没能用上。不知道将来还有没有类似的机会——我的心情很矛盾，既希望有，又希望没有，哈哈。
