Why App Speed Matters: Revenue

By Kellen 

Everyone wants their pages to load quickly. For many growing teams improving page speed becomes an optimization conundrum: do we take time to optimize what we have for speed or continue to build out features that our users want? Within this article, we're going to talk about why people like fast pages and how fast pages benefit creators. After that, we'll roll into what you can do to ramp up the speed of your pages.

People 'Like' Fast Pages

Ramesh K. Sitaraman conducted a study in which he and his peers observed that for every 1-second increase in startup delay for streaming media content, the abandonment rate increased by 5.8%. This means that after 5 seconds, greater than 25% of the potential audience had already vanished.

Later in the paper, a corollary suggests that the faster an individuals' internet is, the quicker they will abandon content that loads slowly. Or: Once you've tasted the blazing speed of < 2 second page loads, anything less feels... sap-y.

Being around in the early days of the internet, where a 14.4kbits/s connection would trudge pages out line-by-line, it's been remarkable to see the evolution of Internet speeds. Content has become richer and connections have become faster. However, the expectation on modern devices and networks is one of immediacy. People want things instantly. This is a trend that's unlikely to reverse.

Services continue to arrive that cater to our desire to have things "now"; same-day delivery, tap-to-pay, Google's AMP trimming and delivering once-bloated content, 24/7 chat support -- keeping up with this trend as a creator; developer or engineer, is a challenge. A challenge that - if left un-accepted - has some deflating consequences.

Creators <3 Fast Pages

Previously, Google conducted the Delay Experiment which artificially lowered speeds of Google searches for a subset of users. They discovered that a 200ms increase in latency reduced daily searches by -0.36%, while a 400ms increase reduced them by -0.74%. In a fascinating twist, they found that reduction within the 400ms group persisted -0.21% even after speed had returned to normal.

A summary of these results suggests that page speed had a direct impact on how often a user conducted searches and that users who had exceedingly poor performance were turned off from the service entirely, likely heading to a competitor. With Google studies, it's always staggering; a reduction of -0.74% searches for a company that conducts 3.5 billion searches per day is a reduction of 25,900,000 searches -- that's for only a .4 second increase in latency! Wah-wah-wee-wah!

Last year, Optimizely conducted a similar experiment. However, instead of measuring number of searches, they created artificial latency then observed the reduction in pageviews. They increased latency by 4, 8, 16, then 20 seconds.

Visualized, this is what they found:

Render speed impact on pageviews graph, from Optimizely.com data

The results come as no surprise; the slower your pages, the less pages your users will view. Given that most people have a threshold of time they'll spend exploring your pages before heading elsewhere, every moment within this threshold is of vital importance. The less pages users view, the less chance your funnel has of accomplishing the user action you're hoping to encourage.

Now, let's consider mobile. The proliferation of mobile browsing changes the performance dynamic considerably. The primary reasons are the inconsistent speeds of mobile networks and the variance in processing power from device-to-device. Less powerful, congested networks require optimized pages - which is often an after-thought.

Google, in their quote-ably deep wisdom, analyzed 11,800 popular web-pages on a "3G" connection and determined that 77% of sites took longer than 10 seconds to load, and on average took 19 seconds to load. With average "4G", they determined a not-much-better 14 second average load time. Later, they discovered that 53% of mobile site visits are abandoned if the site doesn't load within 3 seconds.

Let's summarize. Studies, experience, and intuition seem to suggest:

Therefore, you should prioritize page speed because page speed = revenue.

Radical Benefits

We'll break down the benefits of a blazing-fast web page into three key areas...

1: Better TTFB = Better Search Rankings.

When Google announced that they would start rewarding fast sites with better search rankings, it was unclear what metric would define whether one site was faster than another. Moz, the SEO experts, unearthed no correlation between "page-speed" and search rankings. This considered both "fully-rendered" pages - with all images, snippets, content, and so on included - or when the page is "document complete", which means 'still loading but can be interacted with'.

What they did find is a stark correlation between Time-to-First-Byte and page-ranking. It makes sense; TTFB is the easiest way that Google can assess the general back-end performance of millions and millions of web pages.

Time-to-First-Byte is measured in three parts:

The initial request is impacted by the time it takes to conduct DNS lookup, the quality of the clients connection, and the distance to the server. The processing time fluctuates depending on how much "churning and bubbling" your infrastructure needs to do before it can communicate something back. If your assets are cached somewhere, that makes it much quicker; otherwise it takes time to activate processes and query databases. The returned response varies given connection quality. Once the very first byte is received, the TTFB is set.

You can find the TTFB of a page using curl, as below:

curl -kso /dev/null -w "TTFB: %{time_starttransfer}\n" example.com

By decreasing your Time-to-First-Byte you've ensured that - as far as performance is concerned - you're in optimal standing for SEO.

2: Faster Sites = More Pages Visited.

We touched upon this in the previous section. More pages, more conversion, better revenue! But let's dig in a little, especially when mobile is concerned...

When Google sampled its 11,800 web pages, their sampling also showed that the average mobile page-size is ~2.5mb; ~816kb for advertisements and ~1.49mb for content.

The most recent statistics for global mobile network speeds suggest highs around 37mbit/s, to as low as 6mbit/s. The global average of 17.4mbit/s can render the average 2.5mb mobile page in 1.19 seconds; but this is a raw figure and isn't applicable - what does that become when we consider latency added by distance, the SSL handshake, connection quality, and back-end performance?

In 2006, Amazon's Greg Linden famously presented that every 100ms in latency leads to a 1% reduction in their sales. When using Developer Tools like those offered in Chrome, you can add emulate mobile and add connection throttling:

Mobile and throttling in Chrome Dev Tools

Are your pages fast on all connections and devices?

3: Faster sites = A better experience.

The crème de la crème: A fast experience is better. It feels better. It's more fun to interact with a fast page. The quicker a user can get to your content or explore your application, the better their experience will be.

How to Make Your Things Fast

There are two parts to fast pages...

Build It Fast. If we consider a 2-second render as the standard within which something should load, how much of that 2-seconds is spent loading the quality that you're trying to put in-front of your users? How much of it is spent on other factors?

Let's consider a few questions for reflection:

Speed is a feature. As connections get faster, the expectations for fast websites will only keep rising. It's a feature that will become more challenging to implement manually over time.

Deliver It Fast. If you're looking for an immediate improvement in speed, consider how you currently deliver your application. Reflection, again!

Fast delivery is something that you can have today with minimal effort; it's where Fly fits in.

Fly Fast

Fly can serve your pages and caches from our global network of edge-servers. A global network shortens the trip that an individual needs to take to access your pages. By bringing your users closer and reducing distance-to-server, it reduces the latency added to each request. This improves the overall speed of the experience as well as your TTFB, which enhances SEO relative to performance.

Another strength is within server-side Middleware. Instead of inflating the amount of data being loaded onto your clients, you can bring analytics and other third-party features to our network of edge-servers. An example is within our Server-Side Google Analytics Middleware. Not only does Google Analytics become unblockable by client-side blockers, any overhead in the rendering is eaten by Fly's edge-servers.

Speed is valuable! Faster sites generate more revenue and, best of all, provide a better experience. Signup with Fly to super-charge your applications. Fly started when we wondered "what would a programmable edge look like"? Developer workflows work great for infrastructure like CDNs and optimization services. You should really see for yourself, though.