I recently came across an interesting poll on CSS-Tricks about the ideal page weight/size for today’s modern web design. We worked really hard at optimizing the front end of this very site for page load time, using asynchronous assets, CSS sprites and tons of other things to create a happy user experience, but I’d never thought about the total page size ’til now!
So I opened Firebug to check out Dyn.com, which clocked in at 195.9K and could change a few kilobytes per day depending on the featured images we have on our homepage. Chris Coyier suggests that very few sites today come in at under 200K which “used to be a common goal”.
Used to be? Why can’t it still be?
I think the real question is what’s the size of the assets on your site that count towards a completed document and not the time for it to be fully loaded?
I don’t really care about async code that renders after the document completes and I also won’t care about assets that don’t block a user from being able to read and use a page. According to WebPageTest on the day I checked Firebug’s calculation of page weight, there were 147KB for our document complete time (1.401s) and 163KB for a fully loaded page (1.835s). Then, our repeat page view only grabs 13KB for a complete document and 14KB for a fully loaded document.
Just to be sure, I checked a blog post page using WebPageTest and braced myself for the results knowing how many external resources are loaded for our blog post sharing and commenting. But still, the document complete total was 340KB, fully loaded was 552KB. Load time was 2.227s which I can attribute to careful loading of resources and a really solid foundation of HTML, CSS and images that were already optimized, leaving room for the extra JS.
In the end, this shouldn’t just be about page weight. It should be about how well you’ve optimized resources for loading efficiency, how many requests are needed and the time to document completion.