Dan Luu 写系统问题时，习惯先测量、再对照、最后才下结论。把「How web bloat impacts users with slow devices」放到智能体、评测和线上系统里，真正要问的是：默认做法会不会系统性失败。下面用中文整理成可执行的工程笔记，去掉原站导航和无关链接。

Appendix: gaming LCP

In 2017, we looked at how web bloat affects users with slow connections . Even in the U.S., many users didn't have broadband speeds , making much of the web difficult to use. It's still the case that many users don't have broadband speeds, both inside and outside of the U.S. and that much of the modern web isn't usable for people with slow internet, but the exponential increase in bandwidth (Nielsen suggests this is 50% per year for high-end connections )

CPU performance for web apps hasn't scaled nearly as quickly as bandwidth so, while more of the web is becoming accessible to people with low-end connections, more of the web is becoming inaccessible to people with low-end devices even if they have high-end connections. For example, if I try browsing a "modern" Discourse-powered forum on a Tecno Spark 8C , it sometimes crashes the browser. Between crashes, on measuring the performance, the responsiveness i

Appendix: the selfish argument for optimizing sites

For anyone not familiar with the Tecno Spark 8C , today, a new Tecno Spark 8C , a quick search indicates that one can be hand for USD 50-60 in Nigeria and perhaps USD 100-110 in India. As a fraction of median household income, that's substantially more than a current generation iPhone in the U.S. today.

In the table below, every row represents a website and every non-label column is a metric. After the website name column, we have the compressed size transferred over the wire ( wire ) and the raw, uncompressed, size ( raw ). Then we have, for each device, Largest Contentful Paint* ( LCP* ) and CPU usage on the main thread ( CPU ). Google's docs explain LCP as

Appendix: designing for low performance devices

Largest Contentful Paint (LCP) measures when a user perceives that the largest content of a page is visible. The metric value for LCP represents the time duration between the user initiating the page load and the page rendering its primary content

LCP is a common optimization target because it's presented as one of the primary metrics in Google PageSpeed Insights, a "Core Web Vital" metric. There's an asterisk next to LCP as used in this document because, LCP as measured by Chrome is about painting a large fraction of the screen, as opposed to the definition above, which is about content. As sites have optimized for LCP , it's not uncommon to have a large paint (update) that's completely useless to

Appendix: articles on web performance issues

Although CPU time isn't a "Core Web Vital", it's presented here because it's a simple metric that's highly correlated with my and other users' perception of usability on slow devices. See appendix for more detailed discussion on this. One reason CPU time works as a metric is that, if a page has great numbers for all other metrics but uses a ton of CPU time, the page is not going to be usable on a slow device. If it takes 100% CPU for 30 seconds, the page w

The color scheme in the table below is that, for sizes, more green = smaller / fast and more red = larger / slower. Extreme values are in black.

Appendix: empathy for non-rich users

If you've never used a low-end device like this, the general experience is that many sites are unusable on the device and loading anything resource intensive (an app or a huge website) can cause crashes. Doing something too intense in a resource intensive app can also cause crashes. While reviews note that you can run PUBG and other 3D games with decent performance on a Tecno Spark 8C , this doesn't mean that the device is fast enough to read posts on mode

We can see from the table how many of the sites are unusable if you have a slow device. All of the pages with 10s+ CPU are a fairly bad experience even after the page loads. Scrolling is very jerky, frequently dropping to a few frames per second and sometimes well below. When we tap on any link, the delay is so long that we can't be sure if our tap actually worked. If we tap again, we can get the dreaded situation where the first tap registers, which then

Appendix: comments from Fabian Giesen

Another thing we can see is how much variance there is in the relative performance on different devices. For example, comparing an M3/10 and a Tecno Spark 8C , for danluu.com and Ghost, an M3/10 gives a halfway decent approximation of the Tecno Spark 8C (although danluu.com loads much too quickly), but the Tecno Spark 8C is about three times slower ( CPU ) for Medium, Substack, and Twitter, roughly four times slower for Reddit and Discourse, and over an or

If take a site-centric view instead of a device-centric view, another way to look at it is that sites like Discourse, Medium, and Reddit, don't use all that much CPU on our fast M3 and M1 computers, but they're among the slowest on our Tecno Spark 8C (Reddit's CPU is shown as ∞ because, no matter how long we wait with no interaction, Reddit uses ~90% CPU ). Discourse also sometimes crashed the browser after interacting a bit or just waiting a while. For ex

值得单独记下的观察

• Google : *you* also don't have slow 3G. These two settings go together. Empathy needs to extend beyond iPhone XS users in a tunnel.
• Discourse : Literally any phone of vintage iPhone 6 or greater is basically as fast as the "average" laptop. You have to understand how brutally bad Qualcomm is at their job. Look it up if you don't believe me.
• Google : Are 100% of users on iOS?
• 2015: Maciej Cegłowski: The Website Obesity Crisis Size: 1.0 MB / 1.1 MB
• 2015: Nate Berkopec: Page Weight Doesn't Matter Size: 80 kB / 0.2 MB
• 2017: Dan Luu: How web bloat impacts users with slow connections Size: 14 kB / 57 kB
• Tecno Spark 8C : 0.5s / 0.3s Scrolling and interaction work fine.
• 2017-2024+: Alex Russell: The Performance Inequality Gap (series) Size: 82 kB / 0.1 MB

落地时建议先做的 5 件事

1. 用自己的真实负载测，而不是只用公开榜或厂商数字。
2. 把评测设计成能抓到失败模式：平均分好看但尾部崩溃，仍然算失败。
3. 智能体默认不会好好用测试；要写进流程，而不是写在口头规范里。
4. 性能和正确性都要有基线，改模型或改语言前后必须能对比。
5. 结论写成可回滚的决策：哪一版配置、哪一版评测集、谁签字。

和智能体产品怎么接

龙虾PRO做 OpenClaw 落地时，同样吃「先测量再扩面」这条纪律：技能、数字员工和网关都要有可复现评测，而不是只看一次演示通过。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源