How do you run a page speed audit from a user experience standpoint? For, let's face it: website performance is user experience!
What are the easiest and most effective ways to measure your Drupal website's performance? What auditing tools should you be using? How do you identify the critical metrics to focus your audit on?
And, once identified, how do you turn the collected data into speed optimization decisions? Into targeted performance improvement solutions...
Also, how fast is “ideally fast”, in the context of your competition's highest scores and of your users' expectations?
Here are the easiest steps of an effective page performance audit, with a focus on the prompt actions you could take for improving it.
1. Front-End vs Back-End Performance
They both have their share of impact on the overall user experience:
Long response times will discourage, frustrate and eventually get your website visitors to switch over to your competition.
Front-End Performance
It's made of all those elements included in the page loading process, as being executed by the browser: images, HTML, CSS and JavaScript files, third-party scrips...
The whole process boils down to:
Downloading all these elements and putting them together to render the web page that the user will interact with.
Back-End Performance
It covers all those operations performed by your server to build page content.
And here, the key metrics to measure is TTFB (Time To First Byte).
It's made of 3 main elements:
- connection latency
- connection speed
- the time needed for the server to render and serve the content
2. What Should You Measure More Precisely? 5 Most Important Metrics
What metrics should you focus your page speed audit on? Here's a list of the 5 most relevant ones:
a. Speed index
The essential indicator that will help you determine the perceived performance on your Drupal website:
How long does it take for the content within the viewport to become fully visible?
When it comes to optimization techniques targeting the speed index, “battle-tested” techniques, like lazyloading and Critical CSS, are still the most effective ones.
b. Time to first byte
As previously mentioned, the back-end performance:
Measures the time passed from the user's HTTP request to the first byte of the page being received by the browser.
c. Start render
The time requested for rendering the first non-white content on the client's browser.
Note: the subsequent requests are “the usual suspects” here, so you'd better ask yourself how you can reduce, defer or relocate them. Maybe you'd consider a service worker?
d. Load time
How long does it take for the browser to trigger the window load event? For the content on the requested page to get loaded?
Note: consider enabling HTTP/2, with a dramatic impact on individual page requests.
e. Fully loaded
It measures the time of... zero network activity. When even the JavaScript files have all been already fired.
Note: make sure your third-party scripts are “tamed” enough. They're the main “responsible” factors for high fully loaded times.
3. How to Perform a Page Speed Audit: 5 Useful Tools
Now that you know what precisely to analyze and evaluate, the next question is:
“How do I measure these key metrics?”
And here are some of the easiest to use and most effective tools to rely on when running your page performance audit:
Use them to:
- collect your valuable data on all the above-mentioned metrics
- get an insight into the page rendering process performed by the browser
- identify the “sore spots” to work on
- automate repeated page speed tests
- keep monitoring your website (SpeedCurve) across multiple devices and in relation to your competition's performance
- get a peek into your web page's structure and into the process of downloading resources over the network (Chrome DevTools)
4. 3 Key Benchmarks to Evaluate Your Website's Performance
So, now that you've got your “target metrics” and your toolbox ready, you wonder:
“What should I measure those metrics against?”
And here, there are 3 major benchmark-setting processes to include in your page speed audit:
- determine your competition: your current production site before its rebuild, your direct and indirect “rivaling” websites
- determine the key pages on your Drupal website: homepage, product listing page, product detail page etc.
- measure your competition's web page performance
5. Most Common Performance Bottlenecks & Handiest Solutions
Here are the most “predictable” culprits that you'll identify during your page speed audit, along with the targeted performance-boosting measures to take:
Factors Impacting the Front-End Performance & Solutions
a. Too many embedded resources
Too many embedded stylesheets, JavaScript and images are an extra challenge for your page loading time. They'll just block the rendering of the page.
Each connection setup, DNS lookup and queuing translates into... overhead, with an impact on your site's perceived performance.
The solution: consider caching, minification, aggregation, compression...
b. Oversized files
And images (stylesheets and JavaScript) sure are the main “culprits” for long response times on any Drupal website.
The solution: consider aggregating/compressing them, turning on caching, lazyloading, resizing etc.
c. Wrongly configured cache
Is your website properly cached? Have you optimized your cache settings? Or is it possible that your Drupal cache could be broken?
If so, then it will have no power to reduce latency, to eliminate unnecessary rendering.
The solution: look into your response headers, URL/pattern configuration, expiration and fix the problem cache settings.
d. Non-optimized fonts
Your heavy fonts, too, might play their part in dragging down your website.
The solution: consider caching, delivery, compression, and character sets.
In conclusion: do re-evaluate all your modal windows, third-party scripts and image carousels. Is their positive impact on the user experience worth the price you pay: a negative impact on your page loading time?
Word of caution on caching:
Mind you don't overuse caching as a performance boosting technique. If there are serious back-end performance issues on your website, address them; using caching as the solution to mask them is not the answer. It works as a performance improvement technique on already working systems only.
Factors Impacting the Back-End Performance & Solutions
And there are some handy, straightforward measures that you could take for addressing back-end performance issues, as well:
- Consider optimizing the page rendering process directly in the CMS.
- Upgrade your server's hardware infrastructure (e.g. load balancing, RAM, disk space, MySQL tuning, moving to PHP7).
- Keep the number of redirects to a minimum (since each one of them would only add another round trip, which bubbles up to the TTFB).
- Reconfigure those software components that are lower in the server stack (caching back-end, application container).
- Consider using a CDN; it won't serve everything, plus it will lower the distance of a round trip.
- Consider using Redis, Varnish.
6. Final Word(s) of Advice
Here are some... extra tips, if you wish, to perform a page speed audit easily and effectively:
- remember to run your audit both before and after you will have applied your targeted performance improving techniques
- grow a habit of tracking weekly results
- define the goal of your Drupal website performance test: what precisely should it test and measure and under which circumstances?
- … for instance, you could be analyzing your site's back-end performance only: the time requested for generating the most popular web pages, under a load of 700 concurrent visitors, let's say (so, you won't be testing connection speed or the browser rendering process)
- pay great attention to the way you configure your page speed audit system if you aim for accurate and representative results
The END!
This is the easy, yet effective way of performing a website speed and optimization audit. What other tools and techniques have you been using so far?
Photo by Veri Ivanova on Unsplash.
