Now Available React Programming: The Big Nerd Ranch Guide
Front-End ReactBased on our React Essentials course, this book uses hands-on examples to guide you step by step through building a starter app and a complete,...
Metrics, Metrics: How We Improved our Website Performance
Our Nerds love graphs. Developers geek out on numbers, designers labor over information visualization, and ops + marketing love upward trends.
Web developers, too, love upward trends, particularly in web optimization. We derive excitement from web performance graphs, like time-to-first-load and info gleaned from Google Analytics.
Count the Cost
The web’s humble beginnings left many with the impression that performance is not all that important for the web. However, analytics would beg to differ.
A load time above 3 seconds could cost you 40% of your traffic, and it’s unlikely those users will return. Just an extra 1-second delay can cost about 7% in conversions (or, equivalently, sales).
Visitors who stumble upon your site from search engines are especially vulnerable: even if your result ranks high, people will just click on the next result if your page takes more than 2 seconds to load, and they will likely avoid your site in the future!
A slow site could also affect your standing with search engines. In February, Google added mobile “friendliness” as a ranking factor; but since 2010, PageSpeed score has been part of ranking.
So PageSpeed-Driven-Optimization may not be such a bad thing after all, especially if the information you disseminate is readily available from competing sources.
Still, it’s easy to go overboard with optimization. Premature optimization is a velocity-killing rabbit hole that drains the lives of products and company budgets. So when should optimization become a priority? Will shaving a few bytes noticeably improve the user experience?
Measure Twice, Cut Once
“What’s measured improves.” – Peter F. Drucker
Before diving into the “bucket-list” of optimization techniques, you need to have a comprehensive idea of how our site currently performs.
To qualify performance, you need to determine which metrics are important to you, or which affect your market.
There are a number of general metrics that are useful on most sites.
- Time-To-First-Byte (TTFB): The time from the first HTTP request to the first byte of the response.
- Time-To-First-Render (TTFR): The time before the browser first renders the page. This varies from browser to browser, but is generally after the HTML page and resources in the
<head>tag have finished downloading. - Time-To-Visual-Completeness (TTVC): The time it takes for the main elements of the page (e.g., content and images, but not ads or widgets) to load and remain visually static (e.g., styles are loaded and parsed).
- Time-To-First-Interaction (TTFI): The time elapsed before the app is fully interactive (e.g., scripts are loaded and executed). This metric is useful in full-fledged web apps.
These higher-level metrics are all facets of “perceptual” performance, but for the average user, Time-To-Visual-Completeness will be the most important. TTVC is often a reference to above-the-fold TTVC, although many convincingly argue that there is no such thing. For our audit, we concurred with the “no-fold” opinion.
Why TTVC? A user’s perception of site speed is a great determinant for how likely they will visit again, better than Time-To-Load-Absolutely-Everything. While in actuality it may take some time to load all of the page’s resources like JavaScript and analytics, the user will be more likely to convert or make a purchase if the page feels like it finished loading quickly (by prioritizing content and basic styles).
We can improve these perceptual metrics by addressing smaller constituents. We primarily rely on three tools for in-depth performance auditing:
How do you qualify improvement and goals? The first part is easy: just use the same metrics against your top pages! We targeted main landing pages, which coincidentally covered the different layouts of our site:
When optimizing your own site, you should set your goals based on your marketing and current standing. We aimed to get PageSpeed scores near the 90s (green zone) and reduce TTVC to 2 seconds.
What Are the Hurdles?
Modern browsers are incredibly sophisticated and diverse, but they share some basic similarities when it comes to page loading. The speed of this loading process depends on the critical rendering path.
As the HTML source is streamed, the parser begins building the DOM. As soon as it discovers a script or stylesheet, it blocks the parsing process and dispatches a request for the resource. Only after the request completes does it continue building the DOM.
Some browsers continue parsing the document looking for other resources (images, or fonts in stylesheets), but it still blocks the DOM. Usually, these resources are scripts and stylesheets in the <head> tag (often labeled “blocking” resources). To speed up TTFR, we need to get rid of blocking resources and shrink remaining blocking resources.
Shrinking resources can provide a major boost, but it would be better to avoid extra requests altogether. Most pages are made of ~75 small resources; at this size, latency (TTFB for a particular resource) far outweighs the actual time it takes to transmit the resource.
To reduce latency, we needed to cut server response time and the number of requests. The latter can be done with image sprites, CSS/JS concatenation and caching techniques.
What Now?
In theory, we understand where our site’s bottlenecks are, so we should be well on our way to making it snappier! But beyond wishing bytes away, what techniques can we use to speed up the critical rendering path, and ultimately Time-To-Visual-Completeness?
Next time, we’ll apply optimization techniques and examine the results. Want to learn how to write your own interactive, performant web apps? Come take our JavaScript bootcamp!
