Web Page Sizes: A (Not So) Brief History of Page Size through 2015

Web designers and developers have always adapted to advancing Internet technology. One facet of web design that has been particularly subject to change is the size of web pages (as measured by ?weight,? or total bytes delivered to the browser). This is driven by a number of factors including both hardware and software, trends in the use of web languages, and the speed of the Internet at large.

Why Web Page Size Matters

Web page size matters because it impacts the user experience and engagement. Heavy pages tend to be slow pages, and slow pages mean unhappy users. (One study by Kissmetrics showed that 40% of users leave a website after 3 seconds of waiting, and a Yottaa report on top retail websites found that page weight was the strongest correlating factor with page speed.) Some secondary considerations are specific to mobile, which is now the dominant browsing medium: the cost of bandwidth usage incurred by heavy pages, which may make users hesitant to return; market reach, as some mobile devices can?t handle heavy pages and thus limits the addressable audience; and the negative impact on battery life caused by heavy usage of the wireless radio.

As the number of devices used to access the Internet has exploded, designing and developing for the web has evolved to require a sophisticated approach that takes into consideration a wide variety of browsing contexts. It?s not just mobile or desktop any longer ? it?s a world of specific device capabilities, screen sizes, and connection speeds, as well as considerations for how the page size affects the user experience in these many scenarios.

Here?s a look at how web page sizes have evolved over time with the growth and expansion of the Internet and mobile technology.

The Early Days of the Internet

While the ideas behind it developed over decades, Tim Berners Lee is credited with the invention of the World Wide Web. In 1980, Lee was working on a project known as ?Enquire,? a simple database of people and software who worked at Berners Lee?s company. Through his work on Enquire, Berners Lee experimented with hypertext, a text that can be displayed on devices through the use of hyperlinks. Never actually published, Enquire formed the conceptual basis for the future development of the World Wide Web.

But Lee had a need to share knowledge and information with other physicists around the world, so in 1989, he set about compiling a proposal for a centralized database that contained links to other documents. In 1990, Berners Lee joined forces with fellow physicist Robert Cailliau, who rewrote Lee?s original proposal. While there was little initial interest, Berners Lee continued the development of three major elements that would shape the World Wide Web: HTTPHTML and the world?s first web browser.

The World?s First Website. Image via W3.org

Websites first entered the scene in the 1990s, with Berners Lee creating the first web page that, appropriately, outlines what World Wide Web is. This page is only 4 kB in size, roughly the size of the most basic type of analytics tracking script present on today’s websites, or a tiny, well-optimized image.

These early websites were simple, plain-text websites with images only beginning to appear alongside text in 1993 when browsers first began to support them. When websites were comprised of text and simple graphics, web page sizes were of little concern. At this time, the average web page was just 14.1 kilobytes ? the file size of a one-page, text-only Word document. As Mike Sall points out in an article on Medium.com, at this point making pages was like building Stonehenge: ?it was a feat just to get something in place.? 

Plus, few people were accessing the Internet at this time, so there was little variation in the devices, browser resolutions, and connection speeds being used to access websites. Browsers generally supported only 16 colors, which were widely known as ?web-safe colors.?

Even if one of these primitive websites loaded slowly because of the slow dialup connections in use, it was not considered a problem with the website. There was no preexisting expectation for speed among users — the web was too new.

 

Infographic via WhoIsHostingThis.com

NexusMosaic, and Netscape Navigator were the primary web browsers in the early 1990s. Netscape Navigator was the first browser to support on-the-fly page loading and was deemed so powerful that many websites carried a notification stating ?Best if viewed in Netscape!? However, it was Mosaic that first supported text and images appearing alongside one another, and Mosaic was also the first browser to adopt the layout that continues to be favored by most browsers today.

 

Infographic via HubSpot

HTML Shapes Early Web Page Design

HTML was born in 1990, a year before that first web page. HTML shaped early web design, when tables and nested tables became the method of choice for organizing information on a web page. But tables were fragile structures that sometimes were difficult to maintain. For instance, if the content contained within a column exceeded the available width provided by a browser or screen size, the most carefully laid-out web page designs appeared broken and disjointed.

Newer Technology Solves the Limitations of HTML

Several technologies emerged offering various solutions to the limitations of HTML, which ended up having major implications for web page weight. JavaScript (as it was later known) was among first technologies to promise greater flexibility, allowing for features such as popup windows or the ability to dynamically modify the order of web page content. But as JavaScript is a layered technology, it has to be loaded separately — and thus contributed to the beginning of the steady uptick in the complexity of web pages.

Flash also emerged as an answer to the limitations of HTML around 1996, allowing designers to make use of shapes, animations, any layouts and fonts, and other elements, packaging the complete design as a single file that is loaded in the user?s browser. Flash consumed a lot of processing power and wasn?t search-friendly, leading Apple to abandon Flash technology when it released its first iPhone in 2007, marking the beginning of the deterioration of Flash for web design. To this day, use of Flash is in steady decline, but it?s still used in certain instances requiring animation and interactive games.

CSS also entered the scene, around the same time as Flash, allowing designers to separate web page content from presentation. The biggest obstacle in the early use of CSS was browser adoption, but this was solved before long.

Utilizing these languages and others adds to the number of bytes being sent to the browser. In the early days, though, they were used judiciously, in line with the relative simplicity of web page design. They didn’t initially have a major effect on page size. In the early 2000s, when the web started to increase sharply in popularity, the average page was still under 100 kB. (Today single pieces of JavaScript — ones that control automated A/B testing, for instance — weigh more.)

But more importantly, these innovations enabled an expansion of the idea of what web pages could be, and the increased complexity that ensued was the beginning of a steepening ramp to heavier pages.

Late aughts and Web 2.0 bring an explosion of complexity

“Web 2.0” is the term that describes the era of social media, and the transition of many websites from having brochure-like qualities to taking on the features and functionality of an application. Users were for the first time able to interact with these web apps at a huge scale: leaving comments, sharing on social media, interacting with live chat, and manipulating interactive graphic elements. In the middle to late 2000’s, this trend toward complexity accelerated as broadband Internet access became pervasive, online shopping trusted and commonplace, and social media ingrained in the lives of younger generations.

The phenomenon of Web 2.0 had the greatest effect on page weight of any web trend to date. The average page tripled in payload in the five years from 2004, when the term web 2.0 was popularized, to 2009. Pages grew to feature dozens of images, not handfuls; and they expanded to include a litany of newfangled tools for interaction and tracking that execute via JavaScript. Banner ads became increasingly served by automated ad exchanges instead of being hosted by their publishers. And at the center of it all were interactive elements and eye-popping designs that balooned the size of basic elements like HTML and CSS. 

Mobile Complicates Matters

Before we continue in the chronology of page sizes, we should address mobile. Around the same time that Web 2.0 was coming to full bloom, browsing the Internet via mobile devices became not only a possibility, but a common occurrence, creating a whole new set of challenges for developers. Screen sizes, once limited to the common screen sizes of users? desktop computers and laptops, now suddenly had a much broader range. Web page designs that looked flawless on a desktop or laptop often failed to render even close to appropriately on the tiny screens of mobile devices.

 

Infographic via KISSmetrics

Most notably, the first iPhone’s release in 2007 changed the way the world thought about smartphones and the mobile web. The almost-out-of-nowhere explosion of mobile web usage made it necessary for developers to create both desktop and mobile versions, with mobile designs being an alternative, often slimmed-down version of the desktop website.

 

Image by comScore via SmartInsights

These mobile “m.dot” sites tended to be much simpler than their desktop counterparts, in response to the theory that mobile users were “different”. The assumption was that mobile users had unique wants and needs in the mobile context, and thus the offering could be pared down. While this is true in some contexts, such as the frequency of users searching for a business phone number, the overall theory was largely debunked. Mobile users turned out to be quite like users in the desktop context, in terms of wanting full functionality. What’s more, they were put off when met with unfamiliar designs and structures. Nonetheless, the m.dot sites did benefit from better performance due to their streamlined nature. A 2014 Yottaa study found that the home pages of retail sites using an m.dot solution were 40% lighter than those using responsive web design.

 

The Emergence of Responsive Design

Following the failures of “m.dot” sites to answer to the needs of the exploding number of mobile web users, a new answer emerged: responsive design.

Ethan Marcotte coined the term ?Responsive Web Design? in a 2010 paper at A List Apart, advocating for a shift in design thinking from the fixed to the responsive and adaptable. ?Flexible designs make no assumptions about a browser window?s width, and adapt beautifully to devices that have portrait and landscape modes,? Marcotte points out. ?But no design, fixed or fluid, scales seamlessly beyond the context for which it was originally intended? In short, our flexible design works well enough in the desktop-centric context for which it was designed, but isn?t optimized to extend far beyond that.?

Image via Web Performance Today

The concept of responsive design exploded after Marcotte?s paper, and especially in more recent years asmobile has outpaced desktop in terms of users accessing the Internet.  In January 2014, mobile devices accounted for 55 percent of Internet usage in the U.S., and by August 2014 comScore reported that mobile devices accounted for 60 percent of digital media consumption.

Responsive design has one major flaw, however, and it’s directly related to weight: without custom optimization, a responsive design website will send the same payload of bytes to a mobile browser as it does to a desktop browser. This despite the fact that mobile users often only see a fraction of the content they would on a desktop, since elements are either shrunk down (as with images) or forced down the page out of sight. Sometimes elements are even intentionally hidden from view, but still sent to the browser. Given that mobile devices have less processing power and are often connected through mobile networks like 3G or 4G with less bandwidth, page weight and its performance implications has become a defining issue for RWD.

By January 2015, the average size of a web page delivered to a mobile device was approximately 1MB ?nearly double what it was in 2012. With a median growth rate of around 28 percent, we can expect the average size of a web page delivered to a mobile device to exceed 2MB in 2018. As more users become “mobile first”, so will the development process.

2010 and Beyond: Near-Exponential Rise in Weight

Back to the desktop world. From the “Web 2.0” era of the late 2000s to today, the dual trends of increased complexity and weight have only accelerated. As fast as organizations have found creative ways to augment the experience on their pages, they’ve just as quickly heaped more bytes onto them.

Image via
WebsiteOptimization.com

By one measure, in 2010 the average web page size was already 702 kilobytes. (The chart above has it at around 600 – samples and methods differ). And sometime in 2012, the average web page size exceeded 1MB (1024 kB). That means the average web page size grew approximately 50 percent from 2010 to 2012. 

Another report finds that between 2012 and 2013, web page sizes grew by 32 percent, exceeding 1,700Kb ? slower growth but still historically large.

That trend has more or less continued to present day: no longer accelerating rises year over year, but strong growth nonetheless. By the end of 2014, the average web page size had experienced a 15 percent year-over-year growth, averaging 1,953Kb ? just shy of 2Mb ? and this year, 2015, it was reported that the average page exceeded 2MB. For those keeping track at home, that’s a nearly 7000% increase in 10 years. 

Even if remains true that we saw an all-time peak in page weight growth back in the 2012-2013 time frame, it seems like the prospect of page weight staying static from year to year is a long way off. A reduction in page size from year to year? That’s even less likely.

What Contributes to the Added Weight of the Web Today?

Image via Web Performance Today

 

Images are the largest contributor to the weight of web pages today. They’ve grown larger (in display size) and more numerous over time. Advancements like Retina displays have caused higher resolutions to proliferate, adding even more bytes per image. Images now comprise around 64 percent of the average page?s payload.

Ironically, images are one of the easiest web elements to optimize — they can be compressed to a fraction of their original size with simple online tools. But it requires more effort and skill to accomplish a configuration that will allow for all three “legs of the stool” of image optimization: proper display size for all devices, adequate resolution for all screen types, and optimal compression level.

Many companies struggle to balance the design imperative to add lots of high quality imagery with the need to reduce page size. The trend to more images is unlikely to stop as more sites undergo redesigns for the modern web, but they can be dealt with by a new crop of tools that use contextual information to determine what?s sent to the client.

Image via mobiForge

Another key aspect of page weight is scripts, like JavaScript. While comprising far fewer total bytes than images on most pages, they are a great deal more troublesome. Less can be done to cut down their size; other than minifying, which means removing the extra whitespace in the code, there are few options aside from rewriting the code itself to be more efficient. Third party scripts, the ones that were created by other companies and placed on a website, are even less adaptable. At times they pull in content (such as images or media) that the page is not configured to handle.

Finally, consideration should be given to the fact that, other than a single culprit, complexity itself contributes to the weight problem. When pages host a dizzying array of content that?s been added incrementally by a number of different people and teams, it?s difficult to simply clear away the morass and start fresh. There are too many dependencies, too much risk in something falling apart if its messed with. Many businesses end up with bloated pages for no reason other than fear of repercussions of taking elements away.

Summary

By 2014, its 25th year, there were more than one billion websites on the World Wide Web. The current era of the web is one of responsive, fluid, and readily adaptable designs that accommodate the growing numbers of smartphones, tablets, and varying laptop and desktop sizes now being used to browse the Internet. It’s also clearly an era of massive web pages. The most important effect of this trend is that even as broadband has reached saturation in most developed countries, and mobile networks are constantly improving speed and coverage, web pages are not getting faster. At least not dramatically so. 

According to Google, back in 2012-2013 load times were getting marginally faster for desktop users, and about 30 percent faster for mobile users. But other reports indicate a slowdown in load times during the same time period. Now, as then, there are a litany of ways to measure page load time, and a practically infinite array of possible environmental scenarios and samples. It’s a topic (and industry) unto itself. What’s consistent across almost every study of performance, though, is that pages are not getting significantly faster.  And that page weight, a much easier and more objective thing to measure, is universally agreed to be one of the top factors.

Image via TheNextWeb

Today, the most-repeated motto of web businesses is (in some variation) to “provide great user experiences.” What’s needed to meet that goal is not a regression to simpler pages, but a rethinking of how pages are delivered. Performance-focused organizations are getting creative — thinking of pages less in terms of a bunch of bytes that all need to get from point A to point B, and more like the complex creatures they are. The bottom line: heavy pages are here to stay. The next frontier is figuring out how to make them fast.

Source: http://www.yottaa.com/company/blog/applica...