Boosting your Google PageSpeed result using RapidWeaver - Stage 2
So you want to boost your PageSpeed result using RapidWeaver and Stacks - Stage 2. Here is some tips on how to interpret the results that PageSpeed provides.
Interpreting the Google PageSpeed Insights results
How do I use Google PageSpeed Insights?
Go to Google PageSpeed Insights and enter your website URL for the page you want to check, and press Analyze.
After a short time your results will be shown for the Mobile analysis of your page. To see the Desktop result, select Desktop.
Why 2 different Mobile and Desktop results?
The mobile analysis runs set of clever test algorithims specific to mobile use, that simulate a typical slower delivery of mobile data onto a narrower device, that requires different checks to the desktop check. This takes into account the reality that mobile users will have a poor mobile data connection.
Why is my mobie result much lower than my Desktop result?
So we are starting to get the real core of how useful PageSpeed Insights can be. Just because your web site is responsive, it doesn't mean it's ready for the wide world. If your Desktop score is high and the mobile is low, then by comparing the 2 sets of results you can gain access to what the problem issues are.
How do I interpret the results?
METRICS results
Essentially you want to see green symbols and text everywhere, At the top of the results is an area headed METRICS with 6 important results. Looking at the image of the results below you will see a healthy score of well less than half a second, 0.3s.
- All 6 results under 0.5s second is very good and the numeric result (100%) is almost irrelevant at that stage.
The FIRST CONTENTFUL PAINT score is the time taken for the first screen to be fully displayed, i.e. in 0.3s this site will look ready to any visitor. You are really chasing this time instead of a percentage value but Google has to present this result into a more easy to understand format for the majority of users.
DIAGNOSTICS results
This is the valuable area that will show you where the delays in loading your web page have been detected. Again we need to pay attention to anything in red or orange. Note that each line can be expanded for further details.
Check out the Image Optimisation posts on this blog that address how you can load smaller images, for any image related DIAGNOSTIC results.
You need to look in particular for large file sizes that are slowing down the page loading. Everything that is loaded will add up and slow your page, so the less you load, the faster your page will load fully. A large file could be considered to be anything bigger than about 25Kb, and if you see something like a 400Kb font file or Icon file being loaded then this is a major warning. Similarly look for large individual or multiple CSS or jS or script files that are being loaded.
Lots of large CSS or script files loading are a result of your framework or individual stacks loading these. One way to try to work out what is loading tehse files is to remove certain stacks, and by a process of elimination, find out what is loading these huge files. Failing that, ask the developers of all of your stacks for the sizes of the files that are loaded.
Note that each files size and contribution to the loading delay is also given, i.e. you may see something like:
…f/interv.woff2(webdeersign.com) - 50 ms, 45.61 KiB
This is a large variable font (interv.woff2) being loaded that is 45.61Kb in size and takes 50ms to load. So out of the 0.3s to load the site, 50ms or 0.05s is needed to load the fonts for the whole site. If the woff version of that font was used instead, it would double the time to load. E.g. If that font was 500kb then it would add a further 0.5s to the loading.
Can I ignore some DIAGNOSTICS results
Yes you can, and this is what some users find hard to interpret. PageSpeed reports everything that slows the loading process, but if the contribution to any loading delay is negligable, then it can be ignored. An example of Diagnostics warning that can be ignored:
- Large DOM sizes and Child Elements are not necessarily bad if what you are building with is tiny. E.g. on the Webdeersign home page, there is a FAQ that contains a lot of lists and each one is added into the Child count. However, each set of lists is just simple HTML code, all inside 1 micro footprint Coder stack. So yes, technically, even though the Child size is larger than PageSpeed likes, the first important METRIC speed of 0.3s tells us that the DOM/Child count size in this case is not important.
The important thing is to try to assess the importance in terms of time of the Diagnostics. Remember PageSpeed will report what it finds whether it is significant or not.
Can I improve on a 100% PageSpeed result
Absolutely you can. E.g. If you get a 100% PageSpeed result and you are not using proper delivery of webP images with a jpg/png backup, then doing so, is almost always, well worth doing for a further significant speed improvement. It all counts and best practice image delivery is one of the most important things to get right.
Use PageSpeed to test and then retest after making each improvement.
The full analysis of PageSpeed Diagnostics is beyond the scope or this post, but it is the subject of many good sites and text books, so by Googling any result will provide you with further insight.
Why is all this stuff being loaded?
That is the important question to ask to then determine if you can stop these large files being loaded. Checkout the Stage 3 post on Google PageSpeed Insights.