系统与基础设施endtimes.dev
14KB 的页面为何能比 15KB 快得多
A 14kb page can load much faster than a 15kb page
2022 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章解释了为什么网页首屏资源控制在 14KB 以内能显著加快加载速度：TCP 拥塞控制的初始窗口通常按 10 个数据包（约 14KB）设计，超过这个大小就需要额外的往返确认，拖慢首次加载。文章据此建议尽量精简首屏 HTML、CSS 等关键资源。
为什么经久不衰：它把 TCP 拥塞控制这一底层协议细节与前端性能优化直接挂钩，多年后（2022、2025 两次上首页）仍是理解网页加载速度的经典切入点。
HN 评论精选
补充了另一个相关技巧：charset 声明要尽量靠前，避免解析器重新解析。
同类优化：确保 HTML 的前 1KB 内包含 <meta charset>，避免解析器误判重启。规范甚至把超过 1KB 才声明字符集定义为错误。当然放在响应头里更好——关键是别在 charset 之前塞太多东西。
hoten查看英文原文
Another optimization in the same vein: make sure the first KB contains the <meta charset> element, to avoid false-starts in the HTML parser. In fact, it's actually specified as an _error_ in the spec to have it come after 1KB! It's mentioned in passing on the Lighthouse docs for the charset audit[1], but here's a great breakdown by hsivonen[2]. Of course, in the headers is even better. Point is, try not to have too much cruft before the charset. [1] https://web.dev/charset/ [2] https://github.com/GoogleChrome/lighthouse/issues/10023#issuecomment-575129051
质疑 14KB 目标的普适性：图片为主的网站即使极简也无法达标。
这只有以文字为主的网站才做得到。我的个人网站摄影板块，图库页面几百 KB，单张照片页接近 1MB，没有框架、没有追踪分析，只有 6 行 JS。连没有截止日期和管理层压力的个人站都做不到，更别指望“网络规模”的网站能实现。
yakubin查看英文原文
That's only doable with a text-centric website. I'm currently finishing a photography section for my personal website, and the gallery pages are several hundred kBs in size, while single photo page is almost 1MB in size (provided you load it on a 28" screen; browser will load smaller variants on smaller screens). Most of that weight is the thumbnails (and almost-full-size photo in the latter case). The only JS I have is 6 lines (before minifying) on single photo pages which allow you to go to next or previous photo with keyboard arrows. I don't use any CSS frameworks, just a single hand-written CSS file. I don't have any tracking, analytics, social media features or anything of this sort. So if even a personal site being done with no deadlines, no pressure from management to include analytics etc. can't do it, because it wants to display a bunch of photos, then I don't think we can expect "web-scale" websites to achieve it.
认为用户对加载速度的预期取决于其惯用网络环境，快几秒未必带来转化提升。
有没有人研究过延迟对用户行为的影响，同时考虑用户对自身网络速度的预期？常用卫星网络或 2G 的用户会调整预期，不会每 7 秒就放弃。只要你的网站不比平均水平慢，可能就不会流失太多访客。当然还是应该尽量做快，但别想当然认为缩短几秒 TTI 就能提升转化率。
onion2k查看英文原文
I wonder if anyone has studied the impact of latency on user behavior while considering the impact of user expectations from their typical connection speed. Whenever I see an article about page speed optimization, the assumption is that a user will give up if a page takes too long to load, ans that everyone gives up after X seconds. Usually X is about 7s based on a Nielson article from years and years ago. The thing is tbough, a user who frequently uses satellite Internet or a 2G mobile connection will learn that pages take a while to download over that connection, and they will adjust their expectations accordingly. Satellite Internet users aren't giving up on pages every 7s. They're waiting because they know the page will load slowly. I suspect most users wait for a page if most pages are slow. So long as your website is no slower than the average then you're probably not losing many visitors. Obviously that's not to say you shouldn't make your website as fast as you can. You should. Everyone will appreciate the effort. But don't assume that knocking a few seconds off the TTI time will actually impact your conversion metrics. It probably won't (but only a proper study can prove it either way).
指出 QUIC/HTTP/3 也采用类似的初始拥塞窗口，该原理依然适用。
相关的 QUIC 草案推荐了类似的窗口大小，所以 HTTP/3 看起来行为也会一样。
strken查看英文原文
The relevant QUIC draft recommends a similar window[0], so HTTP/3 looks like it will behave the same. [0] https://datatracker.ietf.org/doc/id/draft-ietf-quic-recovery-26.html#section-b.1-2.2
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选