Report: Average Web Page Size Up 15 pct in 2014

[engine]

This is an interesting report as it indicates the trends and detail on the type of page requests, with Flash on a downward trend. This could be mobile impacting, too.

Bigger isn’t better when it comes to web pages, but the internet has continued to put on weight this year. According to the 2014 report from the HTTP Archive, the average size of a web page is up 15 percent this year to 1,935Kb — just shy of 2Mb (or 2,048 Kb) per page. This includes an average of 95 HTTP pull requests per page.

Part of the web bloat is from a rise in images and custom CSS on webpages. CSS sizes are up 24 percent while image sizes are up 21 percent. Flash on webpages is continuing a slow, expected march toward death and decreased 13 percent this year.Report: Average Web Page Size Up 15 pct in 2014 [gigaom.com]

The full report [httparchive.org...]

[wslade]

This is good information...and a primary reason for slower page loads. From a design standpoint, the use of images and CSS has grown a lot! Telling today's sales story is largely visual. And as more whiz bang template features are developed, the CSS requirements increase.

Using my latest site as an example, the index page is 2.9MB and contains 111 requests. I have reduced the file size of my images and gziped everything. Plus I use server and browser caching. It's a battle for me to balance design with page load speed. And frankly the page speed is on the loosing side of the equation.

I don't think we will ever move back towards plain text sites. As long as everyone (including me) feels the pressure to have the latest in design and whiz bang graphics.

Hardware improvements will likely be the only major solution to the page weigh problem. As an example, Solid State Drives have given server speeds a nice boost.

Unless some "less is more" movement makes a huge impact on site design, websites will continue to bet fatter and fatter.

[aristotle]

A lot of big images are being used unnecessarily. A good coder can use css to produce blocks of text that have just as big of a visual impact as most of the big images I see. Many of these big images could also be compressed to much smaller file sizes without having a noticeable effect on image quality. When this is combined with all the code bloat, page loads are slower and a lot of bandwidth is being eaten up unnecessarily.

[lucy24]

1,935Kb
<snip>
This includes an average of 95 HTTP pull requests per page.

Ninety-five requests? Is it possible some sites are overestimating the SEO benefits of a link from webpagesthatsuck dot com?

Periodically I snoop into a page's html code and, among other things, count the number of stylesheets. The maximum has gone up over the years from 11 to 18 to 20-plus to ... my current record is well over thirty. (I forget the actual number, but it wasn't 31.) For a single page, with no way of knowing how many of those 30-plus stylesheets are actually used by the calling page.

I think a lot of the blame has to go to CMS use by people who have no clue what a webpage actually looks like. "Oh, nice addon, I'll just click this button and my page will look so much prettier" -- and bingo, there's another five stylesheets and ten database calls per page.

Corollary question: 95 pull requests to how many different hosts? Bad enough if you're requesting 94 supporting files from the site you're actually visiting. If there's a completely different host for analytics, and a few different hosts for embedded fonts, each requiring their own lookup, that's a serious hit on page-load time.

[ken_b]

Ninety-five requests? Is it possible some sites are overestimating the SEO benefits of a link from webpagesthatsuck dot com?

LOL :)

.

[piatkow]

A lot of big images are being used unnecessarily.

Too many people don't understand that styling the display to look smaller isn't the same as resizing the underlying image file to be smaller.

[lucy24]

styling the display to look smaller isn't the same as resizing the underlying image file to be smaller

And, by extension: styling the display to {none} doesn't mean the resource isn't loaded at all.