
We’re excited to hear your project.
Let’s collaborate!
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.
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.
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.
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:
What metrics should you focus your page speed audit on? Here's a list of the 5 most relevant ones:
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.
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.
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?
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.
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.
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:
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:
Here are the most “predictable” culprits that you'll identify during your page speed audit, along with the targeted performance-boosting measures to take:
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.
And there are some handy, straightforward measures that you could take for addressing back-end performance issues, as well:
Here are some... extra tips, if you wish, to perform a page speed audit easily and effectively:
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.
We’re excited to hear your project.
Let’s collaborate!