The subject of site speed comes up many times throughout the year and I have written about website speed before. However there are two items that regularly come up that I have written on many times for clients and I figured it was time I just wrote a blog article about it. These are the two items that seem to cause the most concern while also posing the largest challenge to “fixing”. This article explains these two items and why they may not be easy fixes.
At FatLab we manage a lot of websites of which very few we actually built. Many of these sites were built without load-time performance in mind, are many years old and loaded heavy with plugins. These are all considerations when we are asked to evaluate website load time.
A website’s performance is mainly effected by the following:
- How well the website was built.
- How many files are required to load the site and its required functionality. A plugin heavy WordPress site for example will be much slower than a website on the same server with less plugins and complexity.
- How simple the site is. A text heavy site is always going to perform better than a site filled with images, video and other media.
- How optimized the media on the site is. For example when images are added to the site, have they been optimized (made to be smaller file sizes) or are they large requiring the visitor to download megabytes and megabytes of media.
- The server it is on. Is the server optimized to keep connections alive, take advantage of compression (gzip) and use expire headers to cache content so that the user only has download certain assets once? Does the server have enough resources to respond to requests quickly (memory, CPU, bandwidth)?
There are a lot of “low hanging fruit” items that can be done to immediately speed up a website. These include:
- Optimizing media
- Utilizing a CDN
- Enabling keep-alive on the server
- Enabling GZIP for compression
Ok Lets Get to The Point
The Tough Ones
Eliminate Render-Blocking Scripts
The ‘fix’ here is to move the problem scripts lower on the page so that they are loaded after the page is visible or partially visible and/or setting them to “asynchronously” which means that it will load as it can, but the page will not wait before becoming visible.
Things to consider when working with WordPress.
It is the nature of WordPress to load scripts in a particular order, plugin and theme authors also set how they would like their scripts ordered. This is often in conflict with various speed reports (especially with Google Pagespeed Insights reports) and we have little control over a lot of this for 2 reasons:
- Without hacking plugins and/or utilizing other optimization plugins we often can’t change the order the scripts are loaded.
- Often scripts are required to be loaded for certain visual effects to be seen. So changing the the load order can either break the appearance of the site or cause the site to appear broken to the user before “popping” back to normal once those scripts have loaded.
Take away: This may be improved but because of how WordPress works, we will probably never be able to resolve all these issues. Sure you can find articles where people have accomplished this but if your site is plugin heavy, not built very well, utilizes a feature rich commercial theme it may be a considerable overhaul and likely an unrealistic expectation that this be remedied.
Server Timing (Response Times / TTFB)
We sometimes get directives form out clients that our servers need to be faster. This comes from receiving a message from a testing platform like Google’s PageSpeed Insights, GT Metrix, Pingdom and others that report a slow TTFB.
Time to First Byte: The time it takes for the browser to receive the first byte of information from the web server after making its request. In other words when you type in a URL, the request is made for that page from a web server, the TTFB is the time it takes to get the very first bit of information that is going to allow that page to display in your browser.
TTFB and the Server
An overloaded, under-powered or misconfigured server can very well be the culprit when dealing with a slow TTFB. The speed testing platforms often direct site owners to contact their server administrators. We also hear this a lot from SEO professionals (though I often feel they should know better).
So assuming the server is not misconfigured, overloaded or under-powered, there is no speed knob that we can just turn up or worse, forgot to turn up causing our clients slow TTFB reports. We can prove this because on the same hosting platform we have sites with incredibly fast TTFB times and we have sites with incredibly slow TTFB times.
It’s Probably Not Just the Sever
Despite what SEO consultants often say and what the speed reports suggest. I have found that the server (assuming it is well configured and maintained) is often not the cause of a bad TTFB. The issue: The website.
It breaks down to simple model of the work required to build the page. A page with a few images, scripts and a low number of database queries is going to be processed by a server (and sent back to the browser) much faster than a site with a lot of images, scripts and database queries. It’s a simple issue of the server having to do 10 things or 100 things. 100 things are going to take longer no matter how powerful the server is.
The WordPress sites we see the most issues with TTFB are sites that have a combination of the following:
- Complex commercial themes
- Feature rich sites (animations/visual effects)
- Lots of plugins
- Poorly built themes
- Lots of scripts and CSS files called
- Hardcoded script references in the header or footer
- Duplicate resources called
- Features like sliders, slideshows, carousel, animated menus etc.
But Could You Just Get a Better Serve?
The short answer here is yes. If you have an 8GB server on a 100MB network then a 16GB server on a 1000MB network is certainly going to process the page faster and improve TTFB. However if you are on a solid hosting configuration the costs and practicality of getting a faster server may simply make it out of reach. In which case you need to to look to how the site was built.
What We Do About TTFB
When we work to make a site faster we do what we can with code optimizations knowing the limitations explained above. But the following steps typically will typically result in an improved TTFB, sometimes a dramatic improvement:
Utilize a CDN. Utilizing a CDN to host static assets like images and scripts reduces the load on the web server. In the model described above it reduces the number of things the server has to do to build the webpage and therefore speeds up TTFB.
Enable Page Caching. There are many methods to cache web pages and I’m not going to describe them for this post. However by caching page you can greatly reduce the TTFB because the a page does not need to be processed in order to be rendered. For example by caching a page you eliminate the need for database queries to be run which greatly speeds up the page delivery. At FatLab we can do this on the firewall level.
Image: William Warby