The average top 1,000 web page has grown 150% in three years | Hacker News Reader

The average top 1,000 web page has grown 150% in three years

webperformancetoday.com

45 pointssebg55 comments

The explosion in use of web fonts is something I find a bit mystifying. There's nothing more jarring than watching the font of a web page change at load time. It's hard for me to imagine that the positives outweigh this one potential negative. It's like watching someone put their wig on in the morning.

I'm sure that there are tons of sites using webfonts in a way such that load time isn't visually compromised. However, I've seen the "font flip" at sites such as nytimes.com which I assume pay great attention to performance.

That's precisely why webkit chooses to instead not render any text depending on the font. I find that even more annoying, as I often get to see images first, then wait a lot more to see text.

Afaik only Firefox chooses to change fonts later.

That behavior is something that site owners can choose to enable with some asynchronous font loaders, not browser specific.

For example, TypeKit adds a .wf-loading class to the <html> element immediately, begins loading the font asynchronously so as not to block page rendering, and then removes that class once the font has loaded. So, if you're loading a TypeKit font for your H2 elements, you could use CSS like .wf-loading h2 { visibility: hidden; } to hide those headings until their font is available.

If you don't take advantage of the loading class, that's when you see a basic font at first and then see a visible change from the basic font to a web font.

Unfortunately, the only way to avoid either outcome is to load the font synchronously in the head of the page, which blocks the page from loading or rendering further until the font loads and is generally unacceptable for most sites.

Using web fonts is one of the most annoying web design trends. My browser sometimes loads the wrong font for some reason, which for example leads to news rendered with a unreadable baroque typeface.

I would prefer to have them disabled completely, but didn't find an easy way to achieve this.

Since most fonts are loaded from Typekit and such, you can use something like Ghostery or Adblock to blacklist those domains (Ghostery actually blocks Typekit by default).

I used to find it pretty confusing to. I mean, most of the shit I worked in I was quite happy with Arial or some monospace font.

Since then, I've worked with some truly excellent designers. They're people who are great at design, but know very little about the web, so they tend to bring some of the more 'traditional' design concepts with them.

I've seen that the difference in feeling/perception a font can convey for your message when used well is much more significant than I ever would have presumed.

Simply put, there is an aspect of your message that cannot be conveyed with fonts that are available across every device and operating system. (What... Arial, Verdana, Georgia and Times New Roman?).

I still don't necessarily grasp the difference between, say, "Proxima Nova" and "Montserrat" (Google Web Font), but at this point I'm a little more willing to trust the designer.

It would be interesting to know what the median has done.

The average doesn't really tell much of a story, since there's a lower bound at 0MB but no real upper bound. My guess would be that a certain subset of sites have gotten a lot bigger and pulled the average up, while the remainder have seen more modest growth.

Anecdotally, it definitely seems like news sites and blogs have seen a pretty staggering increase in page weight in the past few years. It's not uncommon to see a ridiculous number of resources loaded from 30+ domains on a single site anymore (CNN.com, I'm looking at you).

Advertising and linking to every social network under the sun. As well as a lot of gratuitous javascript dancing baloney.

Is 'page size' alone enough to worry about this sort of thing? We don't download all the assets used every time we load a page.

Just a thought, but the total size of assets on the page ignores the use of caches and CDNs for common assets - if I visit 100 websites that all use Google's CDN to deliver jQuery I'll download a few hundred kbs and do 99 HTTP requests that return just a "nothing changed" header. The fact that those 100 websites are all a few hundred kb bigger than they were a few years ago means very little.

If I visit the same website every day for 100 days straight I'll probably only download jQuery once even if it's hosting the file itself because of my browser cache.

Obviously it's preferable if a site optimises things where it can, but I don't think a 150% increase in total page size equates directly to a 150% increase in data usage. It might for archive.org, but they're pretty atypical web users.

tl;dr Overall page size is less important than setting caching headers properly.

ok, but the article says that there is more images (btw, other media too), i.e. images make 50% of web page now and image size growth contibutes ~400KB out of ~900KB, images tend to change, given that top 1000 pages are dynamic, thus, no cache will help. Also I find it interesting that stylesheets are growing, given that css3 are more powerful now and IE6 is likely to be retired for most of these sites. What is interesting is what makes this "other" part? is it just webfonts or some media (also very cross-site cache friendly)?

Image size could include things for retina displays, higher standard resolutions, CSS sprites and so on. Again though, a lot of images in sites are standard reusable assets that are held in the browser cache between visits - it's just editorial and user-contributed content that won't get much benefit from a well configured http server.

Sidenote: I found out about kraken.io on HN a while ago. I use it for all my images now. Usually gets at least 5% reduction on a well created picture, and 50%+ on a bad one. (No affiliate, just like it)

I don't think that CSS sprites should be bigger, given that css is improving, I don't know about the sample analysed, but usually the editorial and user-contributed content images (as well as ads) take much more bandwidth than style related images, unless the site has exotic design. aside: kranken.io is nice

I don't usually like to host my JavaScript elsewhere such as on the Google CDN. Are there any web standards in the works where you can specify a hash of a file to be cached regardless where it is?

I haven't seen one, but that would be very beneficial, it would not only make everything faster, but also avoid the privacy concerns and remove the additional point of failure that external CDN creates.

Absolutely. Actually in that case we could just do something like this:

    <link rel="stylesheet" hash="b6792c2dcaafc7678f18236f6e7289152756a14f" href="...."></link>

Now that I look at it.. where do we suggest this to the web people?

http://lists.w3.org/

You could use a magnet "link" (which is really just a hash anyways) to pull the file from the Kademlia DHT.

well, that would not work well with backwards compatibility, also it adds extra protocol to implement to browser vendors (extra bugs, here they come :)

Why, pray tell? Isn't the Google CDN:

- faster for people in different geographic areas

- at least as reliable as your infrastructure

- already cached (this would be nullified by your proposal)

I ask because normally I wouldn't think twice about using the Google CDN libraries.

you are right about first, but >- at least as reliable as your infrastructure this doesn't mean that Google CDN is down the same times that your server is, thus it adds downtime (or time when something is broken in the site), i.e. if your server doesn't work, nothing works, if your server works but CDN doesn't, again something is broken and if this time doesn't overlap, it is just additional risk, even if tiny one. Also, what happens when Google decides to charge for use of the CDN?

Ignoring the last point, this is probably why the HTML5BP loads from the CDN but fallsback to a local version if the CDN can't be reached.

It's fairly trivial to load jQuery/other libraries from the Google CDN and fall back to a local copy if it fails as long as you're not using async/deferred.

We've got it baked into our boilerplate.

If Google decides to charge for use of their CDN, then I wish them luck. They don't have any billing information and short of serving a bastardized jQuery (simply not serving it will trigger the fallback) our projects will continue as they've always been.

You're also passing off your user's information to someone else. It's a minor concern, but for some people that might be important.

Genuinely interested - what information?

A 2007 Yahoo investigation found 40-60% of Yahoo's users came to the site with an empty cache, accounting for 20% of page views. Empty cache experience is important.

http://www.yuiblog.com/blog/2007/01/04/performance-research-...

I'd be interested to see if this has changed much in the almost 7 years since that study was done.

It depends on how much the browser caches have grown to compensate for page bloat. Ie8 and below had a limit of 50 mb for all sites, ie9 upped it to 250 mb.

My browsers are all set to dump cache and cookies upon exit.

>Is 'page size' alone enough to worry about this sort of thing? We don't download all the assets used every time we load a page.

Actually we do download most of them. Browser caches are mostly useless for most of the stuff, including widely use JS frameworks and fonts. There were a few widely circulated articles on this.

99 http requests still take some time even if the response is 304.

That's not how you cache. You shouldn't have any 304s for images, js or CSS. If you are, your setup is wrong.

Mark minified js & CSS with a file hash in the path or query string & serve a far future expires header. Browser won't even 304 it and serve straight from local cache.

I wonder how much of this growth is due to retina images. A consequence of the page bloat is that the ipad 1 has become almost unusable to browse the web because it has only 256 mb ram. If the current page doesn't fit in ram, safari closes down. I remember at one point that browsing slashdot and amazon on a machine with 128 mb ram worked just fine. There's no reason for the current bloat aside from simply not caring about efficiency.

I'm guessing this is due to the current trend towards "infinite" scrolling pages with lots of images instead of the old "everything above the fold" school of design.

Much of this is being driven by mobile devices forcing users to become used to scrolling anyways, may as well take advantage of that.

For mobile surfing, I'm much happier with one large slow page than trying to navigate a bunch of smaller sub pages, each of which is also slow and hard to get to.

Two remarks:

- Median would be nice to have as well, as it is more robust to outliers.

- I would like to know whether this is driven by big new pages receiving many visits (changes in user behaviour), or by existing pages becoming bigger over time (changes in web practices).

I think many of us expected this. In previous years, much of the discussion and knowledge-sharing among web developers has been about ways to minimize page-loads, and about flash dying.

Nowadays with the proliferation of JS MV*, Node on the server-side, HTML5 games in JS, much of the focus and attention has been about how to find better performance in our JS code, how to more efficiently deal with the DOM and re-paints, how to get JS to a state where we can have a lot more complex games inside the browser. Also has to do with the nature of putting everyone on the client-side and the increased amounts of libraries being used (many of which are probably in the user's browser cache already).

That said, I'm not sure if it's the change in focus alone, or if it's also because many of the new-er web developers haven't yet been working for the web back when the discussion was about page-loads and when people cared more about supporting legacy-legacy-legacy browsers (I'm glad we're slowly letting that go...).

Regarding web fonts, well I guess it has to do with our obsession with pretty apps and thus, pretty fonts too.

I think the problem is in part due to looking at raw data. In economics, any serious data set for analysis needs to be adjusted for inflation. When talking about bandwidth usage we need to do the same: how do the increases in data compare relative to the increases in bandwidth. Perhaps several graphs (one for mobile and one for desktop infrastructure). I suspect the growth in inflation adjusted terms is probably still significant, but if we're looking at a time period where many users have gone from 3G to 4G on mobile. I suspect the custom font behaviour is driven in part by how easy/inexpensive custom fonts are on native platforms and the fact that brands now try and associate a font as part of their identity in technology. We saw this with Helvetica and other fonts as an expression of corporate identity in the real world in a time period where conformity was more valued, but now the culture is everyone trying to be unique, so it's not surprising to see resources spent on different custom fonts.

While the initial chart is telling, I find the subsequent analysis disappointing.

* It's not all about raw data amounts. Sure, images are the biggest share of traffic, but their size "only" doubled in the last 3y (according to my eyeing the article's chart).

* On the other hand, scripts seem to have tripled or quadrupled in size.

* The "Other" content also looks significant enough to warrant a deeper look, since it currently seems to be bigger than Flash, HTML and CSS combined, and has also grown most significantly. What's this "Other" content, and in what amounts? Web fonts? XML? JSON?

* The pie chart under #2 of the article is horrible.

* How do CDNs and caching factor into all this? How much of the shown amounts must really be downloaded every time?

.. and yet I hardly see any speed difference on cable, because many websites use CDN/Cache. Also many users switched from heavy websites to green sites. Very light and fast. Using alternative DNS like OpenBSD helps ^_^

I think a chart of average load times would be a lot more interesting.

If they are getting slower than us web developers are doing it wrong.

How does this affect un-upgradable computers like ultrabooks? Can't even add more RAM to them

Not much.

In the current market, you're supposed to upgrade your laptop every 3-4 years anyway.

That's not going to happen, once you put an SSD in your old laptop the only advantage on a new one is the battery lasts a bit longer.

Depends on what you do. If all you do is programming, mail and web surfing, maybe.

For anything that's not 1998 level technology though, you'll want something new after 3-4 years.

Stuff such as: video editing, digital audio, photography, multimedia etc (oh, and games). Even casually editing 24 megapixel RAW images as a hobbyist is not that comfortable, even with a state of the art machine.

I would find it interesting to know how the average height changed over time. It seems now it's much more acceptable to have really tall pages unlike the above-the-fold way of thinking of the previous years.

The title is very misleading, I'd argue that it's link-bait.

The average is for only the top 1,000 sites.

I expected a large scale study of the Web. The top 1,000 sites are a very poor representation for the wider Web.

Yet, they represent a overwhelming part of the site-loads users experience (certainly >50%, at least for people from big countries).

What's the benefit of using src='data:image for the images?

You save an http request

But the browser won't cache the image?

Also, you can't post the page to Google+ and have the image show in the post or post a link to the image direct etc.

I only noticed because I couldn't post it.

Am I the only one here who thinks a 151% increase in 3 years is modest at best?

If I am not mistaken, the cost of wholesale bandwidth continues to drop at a near exponential rate year after year.

What about the speed of home connections?

In my experience, design/UX needs will always trump dev/ops. I don't see this changing in the near future. I think we need to figure out ways to make browsers and/or delivery improve instead.

>In my experience, design/UX needs will always trump dev/ops

What does that have to do with anything? Things are not getting bigger because of UX needs, they are getting bigger contrary to UX needs. They are getting bigger because marketing weasels have always wanted things to be this bloated and shitty, and now they think everyone has high bandwidth, low latency connectivity so they can force designers to do it now.

Performance is all about User Experience

I believe most of those Flashes are Ad or Youtube link.

Reply on news.ycombinator.com