How Does Your Web Application Performance Stack Up?

In the last couple of years, the web landscape has dramatically shifted. People want more interactive and fluid experiences. And they want them fast. Speed is one of the most important metrics people use to assess the quality and web application performance of solutions today.

Think Google Instant pages and progressive apps. Even leveraging some of these tools to optimize performance, users may not stick to your site. That’s why today designers and developers must strive to remove every obstacle between users and the rich experiences we create. Several optimization techniques and experimental features can help teams accomplish this.

Acknowledging the need for speed

Users don’t need to demonstrate their desire to move through an experience at rapid-fire speed. They show it with each logged interaction.

• 47% of users visiting a site will abandon it if it’s not loaded within 3 seconds.
• 88% of online consumers are less likely to return to a site after a bad experience.
• 44% of online shoppers say that slow online transactions make them anxious about the success of a transaction.
• We remember wait times as being 35% longer than reality and base our satisfaction on this remembered web application performance rather than reality.
• The abandonment rate for mobile shopping carts is 97%, compared to 70-75% for desktop carts.
• The total cost of abandoned shopping carts for online retailers has been estimated at more than $18 billion per year.
• 85% of mobile users expect pages to load as fast or faster than they load on the desktop.

Variables affecting web application performance and speed

1. Median web page size

Sources have shown median web page size is constantly increasing. At the end of 2014, the median website was composed of 1958KB, but as of April 15, 2016 that size has grown up to 2296KB. The more you add to your application, the more the user has to download on his phone/computer — the harder it is to maintain web application performance. This costs development and product teams both time and money.

In just a year and a half, the median website size has increased with 17%. This makes sense as websites are becoming more interactive. The problem? This trend shows no signs of slowing down.

2. TCP slow start

Internet speeds are improving, meanwhile TCP slow start regulates the amount of data that can be sent out with each packet through the TCP/IP connection. This is done in order to avoid the traffic congestion that will slow things down even further. Maintaining web application performance and speed isn’t as simple as adding more servers or increasing the bandwidth.

3. Media

Time to first paint has dramatically increased due to the richer resources we provide to our users.

4. Site prioritization

Users don’t get to see all the information on your site when they first load it. This makes sense. What’s the point of downloading all a site’s resources when only some of them will be actually used?

With some clever resource hinting and prioritizations (things we will touch upon later on), we can define our critical/must-have resources as high-priority and assign the others a lower priority.

5. Mobile vs. desktop

The experiences the mobile platform can offer compared to desktop are fairly limited. Mobile doesn’t offer the same CPU, GPU and RAM. In general, mobile does not have access to a network speeds that we are used to while using desktop. Yet, the user perception for speed on mobile seems to be on the exact opposite of what the platform actually offers. People expect faster speeds on mobile when compared to desktop. This is important for app developers, considering:

• 30% of all US e-commerce sales in 2015 were done on mobile
• 55% of all time spent on retail websites takes place on a mobile device

That said, we must play the role of moderator and decrease the disparity between what users want and what the platform can offer.

Measuring and managing render speed

Achieving high web application performance and low page load speeds is no longer just a matter of giving users what they expect. Page load speed is now factored into SEO, the measurement that helps the Google algorithm determine which results to show and those to bury.

Tackling web performance issues in a sustainable way means quantifying them first. By setting constraints, we can easily explore the necessary optimizations. A user’s perception of speed can easily be summed up in two words – 1 second. This is all it takes for a user to start thinking about something else while waiting for a slow page to render. Just try it yourself.

For example, let’s look what a single HTTP request would look like going out of a mobile device.

On 3G in the average case, we would have is a 400 ms budget left to actually render our page, based on what we have downloaded. Remember, this is the time it takes for just one request.

Beyond this constraint, the first row shows something that could eat up all of our render budget at once, and this is something we can’t control at all. The control plane represents the idle to connected latency between your phone and the control tower. All the optimizations in the world might not help you if there is high latency between your device and the control tower. Nonetheless, by highly optimizing other variables we can help mitigate this.

Performance testing ‘time to first paint’

There are a variety tools that allow debugging and profiling of the network, memory and render performance. The most popular are the development tools associated with the latest browsers.

It may surprise some, that we won’t spend much time on the Network Panel of the development tools. But, we care less about when the page loads and more about when the page produces its first visually-enhanced and interactive frame.

For the first paint time, we recommend using just the Timeline panel of Chrome Canary (latest development version of Chrome).

Going to that tab and just refreshing the page, it will immediately start recording the whole chain of events produced by the parser, renderer and JavaScript engine. It will also mark the first paint, dom content loaded and load events visually.

Green vertical line – first paint event
Red vertical line – page loaded
Blue vertical line – dom content loaded

We can also see what exactly was our browser doing before it actually produced that first paint frame. In the case above, there was some HTML parsing, JavaScript execution and style recalculation — all things required before painting.

For debugging, this is also great. But what if we want to see what a user experience look like should a user load our page halfway across the world?

Web application performance testing UI

WebPagetest.org offer a free, open-source tool for teams to diagnoses and assess content performance at real consumer connection speeds. It offers the capability to complete multi-step transactions, content blocking and video capture.

For example, we might want to see our application load time as it might be experienced from the other side of the world. Remember, the servers hosting our application are often situated somewhere near us, so it is perfectly normal for our site to load fast locally. But what about people in Brazil or Asia?

This is exactly where WebPageTest shines, it allows you to choose the test location and still get the same timeline with all the data you need to iterate on later.

After a couple of minutes (there is an understandably large queue for this service), it will produce a timeline.

Note that we are also given some valuable statistics like Load Time, First Byte and Start Render. Also, all these statistics are available for the initial view and for a repeated view, which might tell you something about the effect of your cache methodologies.

This tool also provides solid intelligence and hints about what can be optimized (i.e. enable gzip compression, minify resource, use CDN and more). You can export the data in JSON format and plug that in Chrome, so you can debug the timeline even further.

Google’s PageSpeed Insights provides a similar tool. It will immediately give you a performance score, for both desktop and mobile based on a set of many requirements, like optimizing your images, eliminating any render-blocking resources in the above-the-fold content, avoiding redirects and optimizing images.

Remote debugging for higher quality web application performance

Bugs are unwelcome visitors in homes and software alike. Chrome allows using its exact same developer tools on mobile as you would use them on desktop. To activate those on your phone (at least for Android), just connect your phone via USB to a computer and and enable Developer Mode on the device.

Pro tip, when using these tools, always work in a closed sandbox, i.e – incognito mode. This will deactivate all browser extensions that may have some performance-damaging effect in the timeline view. It will be a lot harder for you to read the timeline, if there are many unknown events all over it. For the best insights, always use the latest tools, i.e Chrome Canary.

The last consideration when performance testing isn’t a tool — it’s a mindset. Read and iterate. Everything you add on your site will lower its performance. Consider each element with the complete experience in mind.