独立站点async.cat最近贴出一个总大小956字节的示例网页,同时上线了1kb.club,专门收录体积低于1KB的作品。作者的说法很直接:AI能免费批量产出网站之后,页面做得精不精致已经证明不了作者水平,唯一还没被模型学走的是取舍——敢不敢把一个字节都删不动。
这个判断值得琢磨,但它更像一份审美宣言,不是被验证过的行业结论。体积达标和作者有没有品味、是不是纯手工完成,是两件不能互相证明的事。
956字节是怎么算出来的,又漏掉了什么
原文没有说清956字节到底是页面源码、还是gzip压缩后的体积,更没说是否包含外部字体、图标这类资源。这三种口径差得可能不止一倍,直接套用会误导。
它也不等于用户实际加载时消耗的带宽——请求头、TLS握手、DNS解析这些成本不会体现在网页本体大小里。
956字节和常见的产品网页,本来就不是同一种"网页"。
| 维度 | 956字节示例页 | 常见产品落地页 |
|---|---|---|
| 目标 | 秀极限压缩 | 完成产品功能 |
| 依赖 | 手写HTML/CSS,几乎零框架 | 框架+图片+动效+懒加载 |
| 典型体积 | 1KB以内 | 普遍以数百KB起步,图片字体常占大头 |
| 安全校验/无障碍支持 | 大概率精简或缺失 | 通常是硬需求 |
两者谁也替代不了谁,拿其中一个的标准去套另一个,本身就是个错误比较。
体积达标证明不了品味,也证明不了纯人工
作者给了一个检验方法:删掉页面里任意一个字节,如果页面照样能用,说明之前留的是冗余;如果意义跟着一起消失,才说明这段是真被抠出来的。
这个检验方法能区分冗余和克制,但区分不了作者是谁。模型确实更擅长按常见套路生成偏冗长的实现,这一点没错。
但开发者完全可以让模型出草稿,再用压缩工具、反复测试把体积压到1KB以下。工具没有拒绝参与压缩,只是不会主动往这个方向走。"LLM做不出1KB网页"这句话站不住脚。
所以956字节达标,能证明的只是工程耐心,证明不了作者的审美,更证明不了这是纯手工完成的。
独立开发者和产品负责人该怎么看
对独立开发者和网页设计师,极简站点更像一份能拿出来验证审美和耐心的作品集。放进1kb.club,比简历上写"熟练CSS"更有说服力。
对产品负责人,这套标准不该拿来当前端性能红线。现代应用要背的安全校验、交互反馈、兼容性和无障碍支持,天然会撑大代码量。为了凑体积砍掉这些,砍掉的不是冗余,是可用性。
更实际的用法,是把它当成评估AI编程工具的一个侧面测试——看模型能不能配合人完成极限压缩,而不是把它当成下一代前端的性能标准。
接下来最该盯的变量,是1kb.club会不会补一套验证提交者是否人工完成的机制。如果没有,这场"字节竞赛"迟早会被同样擅长压缩的AI工具卷进来,身份信号也就跟着失效。
