Time to check your data usage? The average page served to mobile devices is now 1 MB in size.


If you asked me to name the single greatest indicator of performance for pages served to mobile devices, I’d say this: faster pages are (almost) always less than 1 MB in size. Show me a fat page, and I’ll show you a slow page.

This is why it was alarming to discover that, according to the Mobile HTTP Archive (which tracks page metrics for the top million Alexa-ranked sites), the average page served to mobile devices carries a payload of 1109 KB. As the graph below illustrates, this number has more than doubled since 2012, when the average page was 511 KB.

Mobile page growth: 2012 to 2015

Looking at the year-over-year numbers, it’s interesting to note that growth has been consistent, with a median growth rate of around 28%. If this continues, the average page will be well over 2 MB in size by 2018 — a year that doesn’t seem that far away.

But we don’t need to get hung up on the future. The present is troubling enough.

When it comes to mobile performance, there are three key problem areas: images, scripts, and fonts. Today, let’s talk about each of these areas, why it’s a problem, and how to fix it.

1. Images account for 64% of the average page’s payload

The graph below gives an historical breakdown of how the average payload is distributed amongst images, scripts, HTML, stylesheets, etc. When I generated this graphic, the first thing that jumped out at me was the fact that, today, images alone (711 KB) account for more payload than the entire web page (682 KB) just two years ago.

Mobile page growth: 2012 to 2015

Some of this growth can be attributed to garden-variety page bloat, a topic I’ve written about many, many times in the past. But a small but growing issue is responsive design being implemented without consideration for performance

Last year, I did an ad hoc performance survey of 60 sites that had all been lauded (from an aesthetic perspective) for their RWD implementation. Of these 60 sites, only 12 sites — just one out of five — had pages that were less than 1 MB in size. Not surprisingly, these pages were also the fastest. Among the other 48 sites, it wasn’t uncommon to see pages that were 3 to 5 MB.

Last year, I was at a conference where the UX lead for a high-profile tech company was on stage presenting. He recommended using the largest possible images in RWD and letting the browser scale them. From a performance perspective, this is terrible advice, but the terribleness of this advice is clearly not as widely known as it should be.

I love RWD, so I want to be clear: responsive sites can be fast. Rather than shoehorning your old site into a responsive layout, re-imagine your site from the ground up. Create a responsive framework that prioritizes performance. It can be done.

2. More than half of all pages served to mobile contain 11+ JavaScript requests

Images aren’t the only potential performance issue for pages served to mobile devices. Payload from JavaScript has grown by almost 150% in the past three years — from 97 KB in 2012 to 241 KB today.

Mabile page growth: Scripts

When it comes to JavaScript requests, payload is just one thing to worry about. Page complexity is arguably an even greater concern. As the graph below demonstrates, in 2012 most pages contained 10 or fewer JS requests. Today, just over half of the pages measured by the Archive contain more than 10 JS requests. Each of these requests increases the complexity of page rendering, as each request must be downloaded and parsed by the browser. While mobile browsers have made huge strides in a few short years, this added complexity places a significant burden on them.

Mobile page growth: JavaScript requests

While not all of these scripts are from third parties, many are — and this presents yet another performance challenge. Every “simple” single line of third-party code you inject into your pages creates a new potential point of failure. You don’t need to reject them, but you do need to plan ahead and monitor your third-party scripts in order to mitigate their risks.

3. Almost half of all pages served to mobile use custom fonts

Some of the JavaScript increase discussed above can be attributed to the rise in popularity of custom fonts. Today, 42% of pages served to mobile devices use custom fonts — up from 4% three years ago. While custom fonts are great for controlling design and branding elements, they can also incur major performance penalties. Some fonts require massive amounts of CSS code, while others use super-heavy JS. Either way, load times suffer.

Mobile page growth: custom fonts

Your best bet? Disable custom fonts for mobile devices. If that’s not an option, then use them only where absolutely necessary, i.e., headers and key typographical elements. More tips here.

Why should you care about mobile performance?

If you’ve read this far, I’m guessing you already care. But if you need to convince others to care with you, here are some compelling reasons:

  • More than 1.2 billion people use the web via mobile devices. [Trinity Digital Marketing]
  • 55% of all time spent online takes place on a mobile device. [comScore]
  • By 2017, mobile commerce is expected to comprise 26% of total ecommerce sales. [eMarketer]
  • 90% of people move between devices to accomplish a goal. [Google]
  • The average online shopper makes 6.2 visits to a company’s website, using 2.6 devices, before they buy. [SeeWhy]
  • 30% of mobile shoppers will abandon a transaction if it’s not optimized for mobile. [MoPowered]
  • Just a 1-second delay in mobile load times can hurt conversions and cart size by up to 3.5%. [Radware]

Takeaway: Mobile performance is a right-here-right-now issue

Web pages served to mobile devices are continually growing in size and complexity, and this growth has a significant impact on load times — and ultimately the user experience. Users expect pages to be at least as fast on their smartphones and tablets as they are on the desktop, and they don’t care about the many factors that limit mobile performance. They don’t care that mobile devices don’t have the processor power to deliver a speedy desktop experience. They don’t care that the browser cache is relatively tiny compared to desktop. And they don’t care about slower networks and greater latency. As far as most mobile users are concerned, these are our problem to fix, not theirs.

If you care about delivering the best possible experience to mobile users, the first three places to look for low-hanging optimization opportunities are your images, scripts (particularly third-party scripts), and custom fonts.

Tammy Everts

As a former senior researcher, writer, and solution evangelist for Radware, Tammy Everts spent years researching the technical, business, and human factor sides of web/application performance. Before joining Radware, Tammy shared her research findings through countless blog posts, presentations, case studies, whitepapers, articles, reports, and infographics for Strangeloop Networks.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Locations
Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program

CyberPedia

An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

CyberPedia
What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Blog
Security Research Center