Speed test- Is my site Fast or slow?
Here we will talk about speed tests and what factors we can fine tune for optimum performance of our Website.
We all want a fast website. Personal experience proves a slow loading website is a turn-off.
We hit the back button and try another site. How do we determine how our site performs for visitors. Not just us?
First remember you spend a lot of time in your site. Your browser caches information for your subsequent visits.
It loads quickly for you because of that. But not so for new visitors.
We have to view our website the way our visitors will see it. When our website loads, it does so in their browser window.
All the code and information that renders your website is transferred to “their browser” which assembles it to display your site.
The speed at which that happens is the difference between being a fast or slow site.
We don’t want a slow site, people won’t wait for it to load.
Let’s do a speed test
To test this we first need to use one of the many online Speed test tools. Below are my favoured ones
| WebPageTest | GTmetrix | Pingdom |
Google PageSpeed is also available but of recent times it is not so intuitive nor easy to understand as other speed test sites.. Let’s leave it out for what we are doing here.
Here I am using WebPageTest speed test site.
(Click on the link – it will open in a new tab)
Enter your website domain name in the test box then press test.
It will run a diagnostic of your site loading. It will then list what resources were loaded.
At the top of the resulting speed test report we see the view in the image below.We have a menu at the top to navigate WebPageTest website.
Below that you see this site speed test report.
The test site scores well with 5 green “A”s.
As speed test go – you can expect to see letters A-F and colors Green thru to Red.
Intuitively you know a Red “F” is very undesirable.
The last one is an “X” to say not applicable. This site does not use a CDN.
We also have a menu to navigate our report. You will also notice we are on the summary tab of the report menu.
We see that 3 Tests were run for this report. One speed test is never a good idea.
Three allows for momentary glitches with the web, traffic and server bottlenecks. The resulting average is safer data to believe.
———————————————————————————————————————————————————————
First you will get a summary of the critical speed test points.
- Usually you will get an overall load time
- time to first bite (this is the time your host took to respond to load your site.TTFB)
- time to first render
- time to visible paint
- how many data requests were sent to fully load the site.
- Then below that summary you get a detailed report to drill down deeper to see each data request and how long it took.
In the above speed test summary you can see what we spoke about. A lot of things make up your load time.
The above result is ok but 3 seconds some would say is right on the border of good and and not so good. (more on that in a minute)
First Byte is a ticklish subject. Here we had .413. That is not lightning quick but is average. It is also a snakey one to pin down.
- Part of it is how fast your server responds. (is your hosting service doing their bit)
- Part of it is where your server is located. (geography still plays a part on the internet, servers and zones are not all equal)
- Part of it is the location the test was done from. (a test run from North America may show delay on a site hosted in Sydney Australia)
- Part of it may be what configuration the speed test was set to by default. (there are options on this site to alter these)
Next you see a speed index 1.817sec. This is indicative of when a visitor is actually getting rendered visual for this site in their browser.
With this particular site you see the last painted Hero image was there at 2.5 secs which means the site was visually complete.
That further .443 seconds was waiting for some non visible JS script download. (I picked that up looking at the detailed report)
Further along you see the fully loaded site had made 52 requests totalling 565 kb of data. That is quite a small amount of data compared to many sites I have seen. (1-1.5mb is common) This site is barely half a megabyte. But it was engineered to be that way with careful optimization.
While many people will tell you a 3 second load time is borderline, its not really that simple. This particular speed test at WebPageTest allows you to view your results in a number of ways. One additional way is a visual/filmstrip view. This exposes the site speed a little differently. (click on Filmstrip view on the right sidebar in any of the 3 detailed reports)
This is a great way to see the users experience in a visual way.
- From the summary we know ttfb was .410 so that takes care of the first frame above.
- Then the next two frames (2 x 0.5 sec =1 sec) are blank, nothing visible to the user and 0% loaded.
- But then in the next half second we have 98% complete visual.
- Then the notable thing to load in that last 2% or half second was a custom font. See the title on post? “Is my site Fast or Slow”.
- For many people the experience would feel like a 2 second load time.
Now I must point out something here. This site does use a Caching Plugin to control the load order of assets.
In this example I found that the Font Family for the Post titles was a custom Font.
It was being called from a link on the web.
It was slow to load and delayed other assets from loading. The site was loading in above 5 to 7 seconds.
I deferred (means making it load after other critical assets) the load of this Font so the primary assets and visuals could load cleanly. And hey!! it works.
Yes the Speed test says 2.943 sec to load. There is a final .443 seconds to account for.
Not all assets show as visible content.
One that many people defer is JS script. Why? because it does not manifest as visible content.
It mostly relates to the active functions on your website. The stuff that makes buttons, menus and widgets work.
Nobody’s’ going to be pressing menus and buttons till they have a visual of your site.
First they scan the page for items of interest. Make the JS load last if it can.
Below that speed test summary, will be the full report for the full load. I wont show that here.
(Go to WebPageTest and punch in your Domain) This link opens in a new window so you won’t lose your place here.
It may help you to become familiar with your site and this tool. Maybe some comparisons with what I show here might expose what is possible.
Next let’s just get an idea of what sort of data is in the load. We need some names for the different types of data in the load process.
Then we can understand how to optimise our site to load quickly as it can.
Below is a Pie Chart from the same speed test. It is found in the third tab of the report menu.
It shows us what groups or families of files make up the 52 load request. We will all have these same categories.
As a sample, the left hand pie shows the number of requests for images was 42% of the overall.
While the right hand pie shows 20.9% of the transfer in bytes (file size) was images.
Not shown here but there is a breakdown in actual bytes on the same page.
The speed test results above are good figures.
This particular website and the images are optimized/compressed using best practice.
Very many sites won’t match these scores. So let’s do a quick rundown on what’s in this pie chart content.
CSS or Cascading Style Sheets contain the data pertaining to the appearance default colors etc.
Fonts are exactly that. Some are native on our site. Some are download links to font suppliers like Google Fonts, Font Awesome etc.
HTML is the code.
Images we know.
JS or js script is active script files.
Other contains everything else not covered above. Could be social media share buttons, web links, Google Analytics and so on.
We usually don’t want to directly mess with any of the above files. So how do we optimize them?
Every website needs a Caching (noun: Cache) plugin.
Every time a website loads it does so in a default sequence.
Some things load quicker than others.
Some things can hold up the load if they take to long because of size, type or location.
Some resources come directly from your websites database.
Other things may come from other locations on the web.
Fonts are often loaded from third parties like Google. Social Media links from Facebook etc.
If we could step into this process and take control of the problem areas we would be able to approach the best load speed.
For instance we could:-
-
- Reduce file sizes. (minification)
- Change load order.
- Defer unnecessary files.
- Compress all this into fewer files. (reducing the number of requests)
- Refresh this data regularly.
A caching plugin addresses these problems. The one I like most is W3 Total Cache. Well over a Million users to date.
The default configuration out of the box greatly improves speed test performance. That may give you the boost you needed.
If not, it also has a sixteen pages of settings. You can fine tune everything or any one thing – only If you chose to.
Some things are not turned on by default. Minification is one of them. You can enable it to run in auto or manual configuration.
Once you start reading the recommendations in your speed tests – each of W3TC settings will start to make sense.
W3TC gives you access to make the changes, simply ticking the required option or button within its settings.
The primary factor we can control is keeping the payload small. Less is more. In keeping with that – W3TC can enact Minification on CSS, JS and HTML files.
This greatly reduces their size and hence their transfer speeds. So that takes care of 3 out of the 6 pieces of pie. Lets move on to the last 3.
Fonts
Fonts are a double edged sword. This is because
- there can be default Font sets native on your website. (In this case they will be delivered by W3TC in the minified content.)
- as well as Font sets that are called from the web.
- theme, pagebuilder, widgets can all add extra font families. (one to watch, and possibly deal with)
- Why is this? Well this is because there are so many of them.
- Additionally remember that web your fonts may be already cached on a visitors browser
- calling a Google font from the web should be a lot quicker than from your site. (Google has fast servers everywhere)
- Still after all this Fonts can need special attention. Extra Font Families add to the load time. Watch them and get W3TC to defer their load if they are holding things up.
Images
Images should be, and is a separate topic for the sake of best practice. The reality is, you cannot have a fast website without including this topic.
Images have a high impact on speed. I Have and will continue to write Posts about this topic.
You need to consciously clean them up BEFORE you upload them. Nothing will change that. It is a special topic with special needs.
(But don’t despair if you did not do that. You can still revisit them and gain a significant boost in site speed.)
Cropping and resizing their dimensions should reflect the maximum dimensions your site can display.
If you don’t do that then you are uploading files with too much redundant data.
This will slow the site loading and bulk up your database and disc space on the server.
Images need to be optimised and compressed using best practice.
A caching plugin does great work, but it does better work with already optimized images.
Also you will benefit greatly by installing a plugin called ShortPixel. A full post on this topic can be found here.
Getting back to our Speed Test results we can see the impact our Images have.
We see it in the “detailed report” and in the ‘Content breakdown report’.
But there is another great tool here to see which images could benefit from further optimization.
In the report menu select Image Analysis. (second from right)
This starts an Analysis of the images in the load. It takes a few seconds to run through all of them.
Next it gives a visual and Analysis of each image. It notes the name and size of the current image.
It then gives a list of the different image formats you could use, and the compressed size benefits.
Again this report scores Images from A-F and Green to Red. You can quickly identify poorly optimised images.
Here you see the image I used earlier in this post. It has a perfect score and no optimization required.
You see it scores a Green A. It is a WebP format at 13.8kb.
You can see the Potential Smart Compression shows 3 suggested formats and smallest compressed size.
The WebP wins hands down.
On the right my Image is 100% the optimised size. Notice the 829×331 – 829×331?
This is another element the Analysis checks. In this case the original image size exactly matches the size it renders in a browser.
If the image were larger than the space for it to render – it could be sized down to save more kilobytes.
Hence load quicker and reduce your sites time to render.
Don’t know what size to make your original images? The answer is here.
The Blue Button “See More” IS A MUST. It holds a treasure trove.
This is the detailed info of your image. There are not a lot of places you can see all this info or recommendation together like this.
But more. You see the other potential file formats.
Not only that. You can actually click on and save them to your computer if you had such a need. (a little more on this later)
We looked at a perfect image result. Now lets look at one thats not so perfect. One that is more indicative of what you are likely to see.
This is the Header image on the site. It gets a Green “B”. So what do I read here? It is a WebP so thats good.
But it is bigger kilobytes than the Potential Smart Compression recommendation. Why? Well the answer is on the right 71,9%.
My image is 1024×373. The speed test said it renders only at 958×349 when shown in a browser.
I could save 4.9kb by reducing its dimensions by that amount. If I were chasing every tiny scrap of speed I should do that.
Obviously if the original Image were 100’s of kilobytes, there would be a big benefit in savings and time.
When the file is this small for a large header image, maybe I am not so worried. Maybe I will do it when I get time.
WepP Images
One important proviso about downloading WebP image variations.
WordPress by itself does not natively support WebP format unless you use a plugin.
It is yet to be enabled in the core development. Without a plugin, If you try to upload a WebP to your Media library it will fail.
There is a script you can add to your functions.php to overcome this but only partially.
It will let you upload the WebP but your Media Library may not render a thumbnail to view it.
Instead you will get a grey box with a title. Also it may not have a mechanism to serve the WebP to a browser request.
The “ShortPixel Plugin“ compresses and optimizes images on your site.
It also has the ability to create and serve WebP copies of all the Jpeg images during the compression and optimization process.
Ticking a box in its settings enables this. It also intervenes in the website load process.
If the visitors browser supports WebP images, ShortPixel not WordPress, serves them up in preference to jpegs.
If their browser does not support WebP they will get the optimized jpeg or png.
Your Media library stays unaffected. It has all its original jpeg and png thumbnails for your viewing.
ShortPixel is a must have tool.
It saves hours of work manually compressing images.
The WebP function alone is priceless.
I recommend you do a speed test on your site, take a note of the results.
Then Download and activate shortPixel.
You will need to setup some configuration initially. This includes ticking two boxes to enable WebP creation and serving.
Then you will run the bulk image process for the first time.
It does allow you to just process the original but you can also process all the thumbnail sizes also , but only if you chose to.
Try another speed test to see any improvements in load time.
Next Download W3TC and Activate it.
Once activated do another speed test and compare the results.
There should be an improvement just with the default configuration.
From there start enabling some of the common settings and watch the performance as it changes with each subsequent test.
The general page is the starting point. From here we enable or disable features.
- Across the top of the page is a quasi menu.
- These are just shortcuts to sections further down the General section page.
The actual main menu is on your left.
- It is the one that then takes you to the dedicated pages for each of the features to further fine tune them.
- Be aware some setting differ depending on the type of hosting you use.
- There are a lot of good articles on what settings work well.
- Just understand that there is no single right way that covers all peoples website and hosting servers configuration.
There are a lot of pages here but some wont be relevant to you. Some only have a few settings. And some are just information.
A lot of people have written good tutorials to guide you through the setup. I wont try to invent the wheel and do it again here.
One I found which had good concise instructions accompanied by clear graphics can be found here
Hopefully this post exposed some of the major factors that affect load speed of a website.
- It showed how to do a speed test for your site. (For Free, no web developer involved – except me – haha)
- It showed a breakdown of the elements in your speed test results.
- It gave you a tool to view what is loading on your website.
- It showed ways to manage and optimise elements for better load performance.
- It did this with two invaluable plugins that will continue to perform automatically 24/7 and reduce manual intervention. (Both Free)
- It gave you access to areas and functions you previously had little control over.
That’s all for the humble but crucial speed test for now.
Join me for future tutorials and follow along the path to optimize and develop your Website.
Don’t have a Website? Check out my tutorials on how to fix that problem also.
