设计与产品blog.chriszacharias.com
页面重量很重要
Page Weight Matters
2012 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇博文讲 YouTube 工程师 Chris Zacharias 的一次页面瘦身实验：团队做了一个更轻量的页面版本，起初从整体平均加载时间看反而更慢；按地理区域分层后才发现，轻量版对网速慢地区的用户有显著提速。文章借此说明页面重量会直接影响真实用户体验，也提醒分析实验数据时要控制混杂因素。
为什么经久不衰：它用一个反直觉的真实案例说明页面体积与加载体验的关系，也因辛普森悖论和早期 YouTube/Google 的性能实践而反复被提起，今天在重前端和移动网络下仍有现实意义。
HN 评论精选
抱怨现代页面塞满广告、社交组件和 JS，导致快网下仍加载缓慢，主张用拦截工具清理。
我用的线路相当快，但有时仍会被页面加载时间震惊，而且往往是因为加载我毫无兴趣的内容：评论、广告和图片、页头、侧栏、工具栏、菜单、社交网络组件、meebo 栏（Google，真的吗？），以及用来加载这些垃圾的 JavaScript。更惊人的是，页面常常要将近一分钟才能开始阅读，或者页面各部分跳动、移位和滚动。我发现把各种广告服务器指向 localhost 的工具、Adblock Plus 这种加载垃圾但不显示的工具，尤其是 Adblock Plus 的过滤规则能清掉垃圾，会有帮助。哪天我想写个类似 Adblock Plus 的扩展，专门找出并移除 jQuery 垃圾……
jerrya查看英文原文
I'm on a pretty fast line, and I am sometimes appalled with how long it takes pages to load, and often it comes down to loading content I have no interest in: * comments * ads and images * headers * sidebars * toolbars * menus * social network tools * meebo bars (really google, really?) * javascript to load all of the above crap The amazing thing is how often I can't even begin to read the page for what seems like much of a minute as the page takes so long to render, or various pieces of the page jump, and shift and scroll. I find that tools that localhost various ad servers help, and other tools that load the crap but keep it off the page help like adblock plus, but even more so, adblock plus' filters that let me shitcan all the crap. One of these days I want to write an extension similar to adblock plus that seeks out and removes jquery crap. A lot of the reasons I can't read pages anymore seems to be jquery slideshows, jquery toolbars, jquery popups and the like. I am pretty sure that graphing this out and we find the end of the web occurs sometime in 2018 when page designers and their bosses and engineers and marketing pukes have so larded down pages that the net runs out of available bandwidth and any page takes 4:33 to load.
用 Linux 流量整形模拟慢速高延迟卫星网络，发现绝大多数网站几乎不可用，建议开发者做全球网络模拟。
因为我家路由器和无线接入点都跑 Linux，我可以做各种恶作剧式的路由、隧道和流量整形实验。之前我在一个专用无线 SSID 上模拟过‘来自地球另一端的卫星互联网连接’：用 Linux 的流量控制/队列规则把该 SSID 出站吞吐限制到 32 kbps、入站限制到 64 kbps，给收发包加 900 毫秒延迟，并随机丢弃 4% 的进出数据包。结果极少有网站还能勉强使用，非常惊人。我觉得对 Web 开发者最有用的产品之一，是一个‘世界互联网模拟器’盒子，放在电脑和网络之间，点选国家就能模拟该国的速率、延迟和丢包，让开发者感受其他地区用户的痛苦。
rwg查看英文原文
Since my home router and wireless access points all run Linux, I can play all kinds of sadistic games with routing, tunneling, traffic shaping, etc. One of the experiments I did a while back was creating a "satellite Internet connection from halfway around the globe" simulator on a dedicated wireless SSID. Basically, I created a new SSID and used Linux's traffic control/queueing discipline stuff to limit that SSID's outbound throughput to 32 kbps, limit inbound throughput to 64 kbps, add 900 milliseconds of latency on sent and received packets, and randomly drop 4% of packets in/out. Very, very few sites were even remotely usable. It was astonishing. I think one of the most useful products that could ever be created for web developers is a "world Internet simulator" box that sits between your computer and its Internet connection. (Maybe it plugs into your existing wireless router and creates a new wireless network.) It would have a web interface that shows you a map of the world. You click a country, and the simulator performs rate shaping, latency insertion, and packet loss matching the averages for whatever country you clicked. Then devs can feel the pain of people accessing their websites from other countries. (Thinking about this for a minute, it could probably be done for about $30 using one of those tiny 802.11n travel routers and a custom OpenWRT build. It would just be a matter of getting the per-country data. Hmmmmm...)
自选样本造成辛普森悖论，按地区分层后轻量版其实显著更快。
这是一个有趣的例子，说明实验中随机化为什么重要。如果你让用户自行选择进入实验组或对照组，然后天真地看结果，结果可能和预期相反，这叫辛普森悖论。在这个案例里，只有页面加载本来最慢的用户选择了更快的页面版本，所以直接看页面加载时间会让页面显得更慢。但 Chris 控制地理区域后，发现确有显著改善。教训是：做随机 A/B 测试，或者分析结果时非常小心。
aaronjg查看英文原文
This is an interesting example of why randomization in experiments is important. If you allow users to self select into the experiment and control group, and then naively look at the results, the results might come up opposite from what is expected. This is known as Simpson's Paradox. In this case, it was only the users for whom page load was already the slowest that picked the faster version of the page. So naively looking at page load times made the pages look like they loaded slower. However once Chris controlled for geography, he was able to find that there was a significant improvement. Moral of the story: run randomized A/B tests, or be very careful when you are analyzing the results.
Google 曾以 20K gzip 预算死抠每个字节，jQuery 会让搜索页体积和延迟翻倍。
2009 年我加入 Google 时，正处在 Larry 2007 年发起的延迟优化运动的尾声。当时整个搜索结果页的 gzip 后预算是 20K。我记得 2010 年视觉改版把页面重量从 16K 增加到 19K，高层为可能耗尽全部延迟预算而非常焦虑。我们做了很多疯狂的事来压字节：每次改动都数字节，有工程师写了工具对比 demo server 的 gzip 大小差异；默认 foreach 循环写成 'for(var i=0,e;e=arr[i++];)'，因为比显式自增少一个字符；能不加结束标签的 HTML 标签就不加，能不加引号的属性就不加；CSS 类名用手工 1-3 字符缩写并另存字典。我还试过在搜索结果页用 jQuery（当时全是原生 JS），结果页面字节数和延迟翻倍，完全不可行。
nostrademons查看英文原文
When I joined Google in 2009, we were on the tail-end of a latency optimization kick that Larry had started in 2007. At the time, we had a budget of 20K gzipped for the entire search results page. I remember working on the visual redesign of 2010, where we had increased the page weight from 16K to 19K and there was much handwringing at the higher levels about how we were going to blow our entire latency budget on one change. We did some crazy stuff to squeeze everything in. We would literally count bytes on every change - one engineer wrote a tool that would run against your changelist demo server and output the difference in gzipped size of it. We used 'for(var i=0,e;e=arr[i++];) { ... }' as our default foreach loop because it was one character shorter than explicitly incrementing the loop counter. All HTML tags that could be left unterminated were, and all attributes that could be unquoted were. CSS classnames were manually named with 1-3 character abbreviations, with a dictionary elsewhere, to save on bytesize. I ran an experiment to see if we could use JQuery on the SRP (everything was done in raw vanilla JS), and the results were that it doubled the byte size and latency of the SRP, so that was a complete non-starter. At one point I had to do a CSS transition on an element that didn't exist in the HTML, because it was too heavy and so we had to pull it over via AJAX, so I had to do all sorts of crazy contortions to predict the height and position of revealed elements before the code for them actually existed on the client. A lot of these convolutions should've been done by compiler, and indeed, a lot were moved to one when we got an HTML-aware templating language. But it gave me a real appreciation for how to write tight, efficient code under constraints - real engineering, not just slapping libraries together. Alas, when I left the SRP was about 350K, which is atrocious. It looks like it's since been whittled down under 100K, but I still sometimes yearn for the era when Google loaded instantaneously.
历次讨论
同类还值得读
贝塞尔曲线入门
A Primer on Bézier Curves
Pomax 编写的贝塞尔曲线在线教程，从基础概念一路讲到曲线求交、投影、曲率等进阶内容，并配有可交互的示例和配套的 bezier.js 库。
设计与产品上首页 7 次 · 2014–2022pomax.github.io编辑精选WebGL 水面模拟
WebGL Water
Evan Wallace 制作的 WebGL Water 演示：在浏览器里实时渲染一片水面，展示折射、反射和焦散等 GPU 图形效果。
设计与产品上首页 6 次 · 2011–2025madebyevan.com设计建议：永远不要使用黑色
Design Tip: Never Use Black
设计随笔提出“永远不要用纯黑”的建议，主张在界面和绘画中改用深灰或带色相的暗色，并借阴影与色彩关系来论证。
设计与产品上首页 5 次 · 2012–2021ianstormtaylor.com用于思考不可想象之物的媒介
Media for Thinking the Unthinkable
Bret Victor 的这个页面围绕《Media for Thinking the Unthinkable》展开，探讨我们用来思考和表达复杂问题的媒介，以及以文字/符号为主的传…
设计与产品上首页 5 次 · 2013–2020worrydream.com编辑精选在抽象阶梯上上下下
Up and Down the Ladder of Abstraction
Bret Victor 的交互式长文，以“抽象阶梯”为隐喻，讲如何在不同抽象层级之间上下移动来理解、设计和可视化复杂系统。
设计与产品上首页 4 次 · 2011–2021worrydream.com编辑精选