
Page Weight Matters (2012) - shubhamjain
http://blog.chriszacharias.com/page-weight-matters
======
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.

~~~
kuschku
Remember, [http://google.com/custom](http://google.com/custom) still loads
instantly ;)

~~~
chinathrow
Yeah and no TLS handshakes need to be performed either.

~~~
ksrm
Why don't they provide an HTTPS version of this? It's a bit of a shame.

------
dpweb
If you have an engineering mind and care about such things - you care about
complexity. Even if you don't - user experience matters to everyone.

Have you ever seen something completely insane and everyone around doesn't
seem to recognize how awful it really is. That is the web of today. 60-80
requests? 1MB+ single pages?

Your functionality, I don't care if its Facebook - does not need that much. It
is not necessary. When broadband came on the scene, everyone started to ignore
it, just like GBs of memory made people forget about conservation.

The fact that there isn't a daily drumbeat about how bloated, how needlessly
complex, how ridicuous most of the world's web appliactions of today really
are - baffles me.

~~~
jkaptur
Honestly, I think "a daily drumbeat about how bloated, how needlessly complex,
how ridiculous most of the world's web applications really are" pretty much
describes every HN conversation on any article with even a remote connection
to web technologies.

~~~
kragen
What would be super awesome would be a daily drumbeat about how to slim down
and simplify applications, with working, open-sourced code.

Here, I'll beat a drum a little. Maybe it will inspire somebody.

I just wrote this tiny text-rendering engine, mostly yesterday at lunch. On
one core of my laptop, it seems able to render 60 megabytes per second of text
into pixels in a small proportional pixel font, with greedy-algorithm word
wrap. That means it should be able to render all the comments on this Hacker
News comment page in 500 microseconds. (I haven't yet written box-model layout
for it yet, but I think that will take less time to run, just because there
are so many fewer layout boxes than there are pixel slices of glyphs.)
[http://canonical.org/~kragen/sw/dev3/propfont.c](http://canonical.org/~kragen/sw/dev3/propfont.c)

The executable, including the font, is a bit under 6 kilobytes, or 3 kilobytes
gzipped.

~~~
titzer
Impressive!

~~~
kragen
Thank you, but I don't think it's impressive! It's still nearly an order of
magnitude slower than memcpy(). But if we want simpler systems, I think doing
experiments like this is a big part of how to get there.

------
jonahx
This is a fascinating example of Simpson's Paradox:

[https://en.wikipedia.org/wiki/Simpson%27s_paradox](https://en.wikipedia.org/wiki/Simpson%27s_paradox)

It also reminds me of the phenomenon, in customer service, whereby an increase
in complaints can sometimes indicate success -- it means the product has gone
from bad enough to be unnoticeable to good enough to be engaged with.

~~~
jfoutz
In WW1, helmets were introduced to protect soldiers. Surprisingly the
frequency of head wounds went way up. It took a little while to realize
soldiers were "just" being wounded, rather than outright killed if they had no
helmet.

~~~
BostonEnginerd
There's a similar story about putting armor on planes during WWII -
[http://www.johndcook.com/blog/2008/01/21/selection-bias-
and-...](http://www.johndcook.com/blog/2008/01/21/selection-bias-and-bombers/)

------
lnanek2
Pretty funny story considering YouTube is back to unusable on slow
connections. They used to buffer the full video, so you could load up a page,
let it sit until the video buffers, then watch it eventually, maybe after
reading your social news sites. Nowadays the buffering feature has been
removed and you'll just come back, hit play, get a second or two of video,
then it has nothing again for a long time.

Feels bad for the engineer who spent all that time reducing the size and
finding out it made YouTube much more usable across the globe. Amusingly,
disabling buffering was probably some penny wise pound foolish way to save
bandwidth.

~~~
flippant
It's for the average user with a decent connection that skips parts of a
video. This is tedious, but if you want to buffer a YouTube video try youtube-
dl[0] or using VLC.

[0][https://rg3.github.io/youtube-dl/](https://rg3.github.io/youtube-dl/)

------
beatpanda
I went to work for a company that makes a travel product used by people in
almost every country in the world, after trying to use it in southeastern
Europe. I told them their page weight was killing the experience, and wanted
to join the front end team to fix it.

After 6 months of banging my head against a wall, I realized the reason we
weren't fixing page weight was because our product managers _didn 't care_
about the experience of users in poorer countries, because they didn't have
any money to spend anyway. Even though we had lots of users in those
countries, and even though we made a big show of how you could use this app to
travel anywhere in the world.

If there's a lesson there, its that as long as cold economic calculations
drive product decisions, this stuff isn't going to get any better.

------
Splines
If you're on Windows you can use the Network Emulator for Windows Toolkit
(NEWT):
[http://blogs.technet.com/b/juanand/archive/2010/03/05/standa...](http://blogs.technet.com/b/juanand/archive/2010/03/05/standalone-
network-emulator-tool.aspx)

I've used it to emulate what it's like on a high-latency or high-loss network.
Relatively easy tool to use.

~~~
latortuga
Chrome also has this feature if you switch to device mode (Ctrl+Shift+M).

------
motoboi
Coming from a low bandwidth, high latency part of the world, I can't confirm
this enough.

Today, I have 2 mbit and can use Netflix or Youtube just fine, but mere 4
years ago, I had 600k and, boy, that was hard. Hard as in loading youtube URL
and go for a coffee.

UPDATE:

In case Duolingo developers are listening, please test your site on high
latency and very low bandwidth scenarios. I just love your site, but lessons
behave too strangely when internet is bad here.

~~~
malka
> Hard as in loading youtube URL and go for a coffee.

You can't even to that now. Youtube videos buffer about 1m30 of videos and
stops after that :(

~~~
voltagex_
I understand that Google is doing this to save an immense amount of wasted
bandwidth. These days if I need to wait for something to load, I use youtube-
dl.

------
teach
Comments from the last time this was posted:
[https://news.ycombinator.com/item?id=4957992](https://news.ycombinator.com/item?id=4957992)

~~~
tedunangst
Wow. The verge was the poster child for most bloated site even three years
ago, long before the recent ruckus.

~~~
mattmanser
What was the recent ruckus?

~~~
tedunangst
[http://blog.lmorchard.com/2015/07/22/the-verge-web-
sucks/](http://blog.lmorchard.com/2015/07/22/the-verge-web-sucks/)

------
SandB0x
It is insane. One of my favourites is the "about.me" site, which is meant to
be a simple online business card. Picking a random page from
[https://about.me/people/featured](https://about.me/people/featured), you get
a page weighing over 3MB!

[http://tools.pingdom.com/fpt/#!/F4VDN/https://about.me/penta...](http://tools.pingdom.com/fpt/#!/F4VDN/https://about.me/pentatonicfunk)

------
mbrock
Everyone's sometimes on spotty WiFi or foreign expensive 3G. I'm more inclined
to trust fast-loading sites and apps.

I wonder what would happen if for example iOS decided to visually indicate
page weight, kind of like how you can see which apps use the most energy.

~~~
peterjmag
I think that's a great idea. Make it more visible, and then you get normal
people to care about it and put pressure on content owners, developers, etc.
Like Google did with their "mobile-friendly" tag; I could yell at my managers
all day about how we need to improve our site's mobile experience to no avail,
but Google steps in and threatens lower rankings and suddenly it becomes top
priority.

Perhaps the simplest solution is for Google to start penalizing heavy pages,
but as far as I know, page weight isn't part of their mobile-friendly
criteria.

------
gketuma
As a web dev I always have this in mind but the challenge is convincing your
client who wants a video background. Maybe we need a media query that detects
internet speed.

~~~
scrollaway
Even then, it's fairly easy to load the video asynchronously and as part of
the last assets, make its intro blend in to a single-color background, voila,
problem "solved".

I find video backgrounds ridiculous most of the time (though they can be done
really well), but that's not the real problem here - the real problem is
including 200-800kb javascript code that does nothing but track your user, and
often enough doesn't do it for _you_! (Hi Facebook!)

The real problem is using massive js frameworks for the sake of adding dynamic
functionality to your site that, often enough, isn't actually worth it.

The real problem is that very often, these "features" are only as necessary as
the marketing team says they are... the people who have the ability to ask
"why?" and the ability to understand "why not" don't have the voice (or
guts...) to do so.

~~~
pswilson14
"Massive" JS frameworks aren't the issue, not by themselves. AngularJS, for
instance, is only 39.5kb. Bloat sneaks into web applications in other ways,
but merely bringing in a framework isn't enough to add a noticeable load on a
web page.

~~~
kuschku
I’ve seen sites loading Angular, React, jQuery(+jQuery UI) and some custom
frameworks. Different parts of the site rendering in different frameworks.

------
misterbwong
Isn't this phenomenon getting worse now that responsive design is in vogue?
We've collectively decided to shoehorn a website designed for the connectivity
and speed of a desktop browser into a lower powered device with slower/spotty
connectivity.

Genuinely curious: Why is this better than a mobile-friendly site designed
specifically with the constraints of a mobile device in mind?

~~~
jonahx
Simple answer: Writing a responsive site is much faster and easier to maintain
than creating two versions of the same site. And it wouldn't it be just two,
you also have to support tablets, various desktop sizes, and various mobile
sizes. Custom versions for each one isn't feasible.

Also, if you care about page and weight and optimization, your site will be
light everywhere, and the criticism of shoehorning a big bloated desktop site
into a phone won't apply. This is not that difficult to achieve.

------
paulirish
More than page weight, this article demonstrates that _averages are dangerous_
, especially for performance metrics. All key metrics should be plotted in
50/90/95/99 percentiles, and for latency-sensitive ones, geographic breakouts
can often reveal a serious delta from the mean.

------
bsimpson
Thought certainly an interesting anecdote, I don't understand how a video
streaming site like YouTube would be useful in a market where a 100K download
takes 2+ minutes. You'd have to open a page, walk away for an hour, and hope
everything was OK when you got back.

~~~
IkmoIkmo
Well think about it. Imagine you had no alternative to getting any video on
the internet? After all, if not youtube, anything else was probably slower at
the time. Obviously you wouldn't simply lose the desire to watch relevant
videos, it'd be dimmed quite significantly sure but you'd still want to watch
a video every now and then. Whether it's a music video, or a chess match or a
farming lecture, there's just a ridiculous amount of content available. I have
plenty of videos I'd want to watch even if I'd have to wait hours. (take
torrenting for example, or pre-youtube & pre-streaming file sharing, video and
music on p2p networks were incredibly slow yet incredibly popular).

But if you couldn't even load the pages to browse through the videos, that'd
pretty significantly reduce your watching even further.

Liken it perhaps to a library where you could only get 1 book per week. Well
that's not much, but at least you can get 1 book. But if you go to the library
you have to wait in line for an hour, and after examining one book section of
10 books, you have to wait 5 minutes to examine the next one. Choosing the
weekly book would become such a chore you'd probably not even bother to go
anymore. But if you'd suddenly be able to examine the entire library with only
1 minute of total waiting, many more would be much more inclined to do so,
even if they could still only borrow 1 book per week.

Beyond that in my experience, lots of requests in a slow connection often
fails before completing fully. I don't know why exactly, I've never been a
network engineer. While streaming in a slow connection eventually gets there.
So it's entirely possible that even browsing normal pages was failing entirely
before for some people, even though (if they ever did load the page and choose
a video), the video download worked fine albeit at a very slow pace.

~~~
CDRdude
> you'd still want to watch a video every now and then

My favorite example of this is YouTube repair tutorials. If I need to get
something done, these can be irreplaceable. If I had a slow connection, but my
car was up on the jack stand, I'd just have to wait.

------
andrewstuart2
Page weight may matter, but I think amortized page weight matters most. It's
like the marshmallow experiment for the web. If you can make one request at
10x the size, but it's only made 1/100th as often (presumably spans multiple
pages) then as long as people come back enough to justify that initial extra
cost, you've effectively decreased to 1/10th again.

That's why I think AJAX, web manifest [1], indexedDB, localStorage, etc. need
to be leveraged much more. Imagine most of your app loading without making a
single request, except for the latest front page JSON, or the latest . You
have a bunch already in indexedDB so you just ask the server "hey, what's new
after ID X or timestamp T?"

So your two minutes just became a couple milliseconds (or whatever your disk
latency happens to be), and the data loads shortly thereafter, assuming
there's not much new data to send back. And if you don't need any new
resources, you only had to make a single request.

[1] [https://github.com/w3c/manifest](https://github.com/w3c/manifest)

~~~
nostrademons
The _initial_ page load matters a lot. That's the one where the user is
deciding whether he'll be coming back to your site. The unfortunate thing
about many caching technologies is that they speed up subsequent page loads,
but do nothing for the initial one. You still need to pay attention to clean-
cache load times. Indeed, it can often be worth it to pay a cost on total page
load time to get first-paint time down - that's the time at which the first
visual representation of the webpage appears, even if it's just the header,
layout, and a bunch of boxes.

------
jjzieve
For some reason this whole problem reminds me of early game developers dealing
with small amounts of RAM. Which clearly isn't a problem today. So would it be
fair to say we should focus on increasing bandwidth to most of the world. I'm
not saying page weight doesn't matter, but if you're just trying to get
something off the ground maybe you shouldn't worry about it so much. I mean,
why worry about users with poor bandwidth, if you don't even have users? If
you already have a growing user base, then by all means refactor, reduce the
footprint. But if you don't, code the damn bloated thing first.

~~~
PavlovsCat
Sure, most games these days are probably more CPU/GPU bound, but then again
people usually don't have more than one game running at a time, while caching
the assets of thousands more.

Also, isn't adding bloat "more work"? And just like in real life, I think
losing bloat is often harder than gaining it. Why not worry about carousels or
endless scrolling or video background when even just _one_ person misses that
stuff? Where are all the highly successful websites that started to reduce
bloat after they got off the ground? It's not a rhetorical question or
sarcasm, I am interested, but I honestly can't think of even one example, it
doesn't really mesh with my own (admittedly rather pedestrian) experience. A
site starts with a blank design doc, and empty file and a white screen, and
adding something and later removing it isn't easier than simply not adding it
in the first place.

------
nicolethenerd
Nice to see this again - I've told this story to many of my web dev students.
:-)

------
cr4zy
I highly recommend turning on page throttling in the Chrome Dev Tools
sometime. You'll be amazed at even how slow even 4G seems.

------
hyperion2010
Heh, I've been using flask tempting to make some html forms for exploring
large datasets. Turns out when you have 6000 terms that show up in 6 different
UI elements putting those in as raw html results in a 13mb file that
compresses down to 520kb. Pretty awful use case for forms. I'm pretty
prejudiced against JavaScript, but having seen this I now deeply appreciate
being able to send something other than raw html.

------
secondwtq
" I learned a valuable lesson about the state of the Internet throughout the
rest of the world. Many of us are fortunate to live in high bandwidth regions,
but there are still large portions of the world that do not. "

lol, I'm in China and all what you're discussing just does not exists here.
What you'll get is just a "Connection Reset", no matter how compact the page
is.

------
foxbarrington
If it takes two minutes to load a 100kb page, does it take twenty minutes to
watch a 1MB video? Over three hours to watch a 10MB video?

~~~
gwern
Probably not. Downloading the video is going to depend more on throughput than
on latency. The initial connection & page load, as it hits all the domains and
resources, is going to be much slower because it relies more on latency and
roundtrips.

~~~
Brakenshire
The article says that the page would have taken 20 minutes to load under
previous circumstances.

------
csense
The more things change, the more they stay the same.

I remember visiting microprose.com with my 14.4k modem in the mid-90s and
being mad that they used so many images I had to wait for about 5-10 minutes
or so. I couldn't effectively read it at home and usually ended up reading it
at the library.

------
userbinator
This is a bit tangential, but how did we get from "size" to "weight"? It seems
a bit of an odd phrasing to me. With the exception of ESL mistakes, I don't
know of anyone or any software which refers to "file weight", for example.

~~~
plonh
Because the weight is hidden behind the visible page content, which had a
different size. Page weight is the sum of the sizes of the resources used to
build the page.

------
ninjakeyboard
If it took two minutes to load the framing page, how would they be able to
stream the video?

------
pneumaio
It's not surprising large numbers of internet users in emerging markets
skipped the web entirely. Delivering product via SMS and chat starts to make a
lot of sense in context.

------
drikerf
Great point and very important in times when bundling howmany? js dependencies
for client apps.

------
chadwittman
Fantastic

~~~
imperialdrive
Ditto - Loved reading this. I work on similar projects but it's a tough battle
to win against marketing these days.

------
sirtastic
WOW! Faster load times and lighter code makes for a better user experience?
(mindblown)

~~~
jp555
whoosh! You missed the whole point.

~~~
sirtastic
That you can't always look at a single metric as a basis for success? This is
rudimentary analytics here. Is there a single person who believes making
client side code heavy is the way to go? Do people really think user
experience should take a back seat to cool stuff on a site like YouTube?

~~~
tedunangst
Try "what makes a site merely inconvenient for some can render it completely
unusable for others, and so one should not overlook minor issues because they
don't seem worth fixing."

~~~
sirtastic
Excuse me. I didn't realize this wasn't obvious.

