Website Page Speed Optimization
Have you ever clicked on a website and it took so much time to respond?
I'm sure that's a definite YES! On several occasions, we've experienced annoyance with how long it's taking a page to load. A good page speed is important for optimal user experience.
What do users want when they visit a website? They want to:
Immediately see content on the screen once they type a URL in the browser.
Get an instant response when they tap on a keyboard or screen.
No hiccups while scrolling on a web page.
Do not want their mobile data to be used up.
When a user types a URL into a browser, the browser sends the request to the server that the website is hosted on, to retrieve the data. In a nutshell, what happens here is:
The browser does a DNS lookup to find the IP address/DNS server, next a reliable and secure connection is established via a TCP and SSL handshake. The request is made and the server responds to the request.
In this post, I'll share how I identified and improved a site's performance by making its pages load faster.
Performance Test using WebPageTest
To measure page speed, I used the WebPageTest tool to conduct a performance test. It is a free web performance tool used to measure a page's load time, and it shows metrics that indicate how quickly a page loads. These metrics are First Byte, Start Render, First Contentful Paint (FCP), Speed Index, Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Total Blocking Time (TBT), and Total Bytes.
You can find how to use the tool here.
Recommended Scores For Important Metrics:
First byte or Time to first byte - measures the time between the browser's request for a resource and when the server responds with the first byte of page content. A good score is 0.8 seconds or less.
FCP - First Contentful Paint measures the time from when a page starts loading to when any of its content is displayed on the screen. A good score is 1.8 seconds or less.
LCP - Largest Contentful Paint measures the time from when a page starts loading to when the largest element is loaded on the screen. To provide good user experience LCP should be 2.5 seconds or less.
CLS - Cumulative Layout Shift measures the visual stability of a page from when it starts loading to when it finishes. A good CLS should be 0.1 or less.
TBT - Total Blocking Time measures the total amount of time a page was blocked, making it unresponsive to user interaction. A good TBT for mobile should be 0.2 seconds or less.
From the image above, you can see that the website I tested is loading really slowly as it has failed to meet any of the recommended metrics that affect page speed.
The time between the first byte and the start render (when the browser starts showing something on the screen) is far apart. This indicates that something is blocking the rendering of the page and to be able to render, the browser has to construct the DOM and CCSOM.
The time between the start render and LCP is also a gap I will like to close, alongside the TBT to ensure a good user experience.
I really love using the WebPageTest tool because it helps me figure out how to improve a site's performance and what impact any measure I take will have on the site.
Here's a waterfall view of a site showing every HTTP request that the browser sent to the server in the order it was sent. There are lots of insights to get here; you can see the render-blocking resources, and when you click on each request you will see the request made, size of the request, if it is actually blocking rendering, the load time, the response, and more.
Here's an article explaining how to read the waterfall diagram.
Using the Coverage tab in Chrome DevTools, I identified unused JS and CSS files on the home page of this particular website.
You can see here that the page is using only 4% of the code, with 96% unused. For each URL here, the green colour signifies critical resources required for the first paint while the red colour is for code not required for critical page function.
The tricky part is in identifying which of these unused files are not important for loading the portion of the page users see once a page loads.
NOTE: Do not delete ALL unused code, the experiment feature in WebPageTest can help you figure out what is needed to render the first paint without breaking the website.
So, I did a series of tests using the insights from the opportunities and experiment tab in WebPageTest to identify the effects a likely recommendation will have on the website.
Factors Slowing Down Page Speed
The opportunities and experiments section in the WebPageTest will outline factors affecting the page speed, usability, and resilience, with recommendations on how to improve.
These are the elements that were slowing down the page's speed:
Web Hosting: This website is using a shared hosting provider which is one of the reasons that the site has a slow first-byte time. Shared hosting can affect page speed because the server is shared with other websites.
JavaScript and CSS: JavaScript and CSS are usually render-blocking resources on a page because they delay the browser from rendering a page's content. The browser has to construct the DOM and CSSOM before it can render.
Web Fonts: These are custom fonts used on web pages, e.g Google fonts. Since they are hosted on another domain, it will take longer to load due to DNS resolution and connection. Also, the fonts on this website had default display settings for hiding text while loading causing a flash of invisible text instead of showing text to users immediately.
Images: These can significantly slow down a page's speed if they are large, uncompressed, and not responsive. In the case of this website, the LCP is an image and it was lazy loaded causing the LCP to be high.
How I Improved The Website's Page Speed
Having identified what was slowing down the website, I had to find a way to fix it. My aim was to improve the site's initial load time which is the time it took to display content in the viewport, as this is what users see first once they land on a page and will impact how they perceive it. A page that renders quickly is perceived to have a fast load.
Since I am not a "Developer", I found a way to do this using a plugin called "Litespeed Cache". Litespeed cache is a plugin that can be used to cache pages on a site and also for website optimization. But first, I backed up the website contents so I can easily reverse any errors that may occur.
How I optimized page speed using this plugin:
SET UP CDN & CACHING: I used a CDN alongside caching to store the website's contents and deliver them faster to users when they return, no matter where they are. This helped reduce the load on the server and decreased processing time.
Enabling Cache Settings: Caching reduces the load on website servers by temporarily storing the contents of a web page when a user visits the first time and serving the cached copy when next they visit.
Litespeed Cache - Cache - Cache tab - Left on Default
TTL tab (Time To Live) - Left on Default
Purge tab - Left on Default (you can set up rules to purge your pages for situations like when you make changes to your website)
ESI tab (Edge Side Includes) - Left on Default (used to enable public and private caches for logged-in users)
Browser tab - Set to ON (to cache static files like images, fonts, or even videos in the user's browser to reduce repeated server requests when a user visits again)
2. Setting Up CDN: A Content Delivery Network is a group of servers that deliver content to users faster regardless of their geographic location.
QUIC.cloud CDN - Set to ON (to cache both static and dynamic content on the website)
Set up a QUIC.cloud account to be able to use its optimization features. This post touched on how to do that.
OPTIMIZED CSS & JS: I optimized render-blocking and unused CSS and JS using the page optimization tab in the plugin by; minifying CSS and JS to remove unnecessary characters and reduce their file size, inlining critical resources required for above-the-fold content in the HTML, and deferring non-critical ones. This optimized the critical rendering path.
LiteSpeed Cache - Page Optimization - CSS Settings Tab - CSS Minify set to ON - Load CSS Asynchronously set to ON (this setting automatically generates critical CSS required for above-the-fold load and inlines them into the HTML code).
NOTES: Clear cache after saving these settings.
Also, check out this article on how to defer non-critical CSS.
LiteSpeed Cache - Page Optimization - JS Settings Tab - JS Minify set to ON (this setting minifies JS and also inlines critical ones) - Load JS Deferred set to Deferred.
OPTIMIZED IMAGES: I optimized images by; lazy-loading images except for the ones in the viewport, serving responsive images, and compressing large ones.
LiteSpeed Cache - Image Optimization - Image Optimization Summary - Gather Image Data - Sent Optimization Request for the first batch of images to ensure everything was working well.
LiteSpeed Cache - Image Optimization - Image Optimization Settings - Auto Request Cron set to ON - Optimize Losslessly & Create WebP Versions set to OFF.
LiteSpeed Cache - Page Optimization - Media Settings Tab - Lazy load images set to ON
LiteSpeed Cache - Page Optimization - VPI tab - Viewport Images set to ON (this setting excludes all above-the-fold images from lazy loading).
NOTE: Always save changes before moving on to the next configuration.
PAGE SPEED AFTER IMPLEMENTING CHANGES
There are improvements in:
Start render and FCP
The time between start render and LCP
CLS
TBT
Number of requests made by the browser
Total bytes
First byte is reliant on the server a website is using, and since this site is using a shared hosting provider, it is expected that the time it will take the server to respond will be slow. Using a dedicated hosting service can fix this issue. TTFB is not a core web vitals metric, but it can affect the performance of other metrics as Harry Roberts mentioned in his article.
CONCLUSION
As Technical SEO Specialists, part of our job involves diagnosing page speed issues and recommending ways for optimization to web developers. It is important to note that every website is different and as such requires thorough audits and experiments to identify factors slowing down page speed and how to fix them for optimal user experience.