Scores of 0-49 are considered poor, 50-89 as needing improvement and 90-100 as good. The audits used along with their contributing weightings to the final score are below.
Just for fun and to explore the PageSpeed results using interesting examples I put all 20 premier league (2020-2021) teams through the PageSpeed API to see who’d score the best and then reviewed (for learning purposes only, not to be critical) each site based on the PageSpeed results as well as looking at the sites manually.
Note that with each PageSpeed run scores and timings can fluctuate so team positions can change. The top and bottom three however have been very stable with Newcastle nearly always top, Everton nearly always second, BHA always third and the bottom three always being West Ham, Villa and Man Utd (usually in that order).
Table ranked by PageSpeed performance score
The table below shows the PageSpeed scores for all 20 teams. Note in this run I’m only reviewing desktop scores.
As can be seen above Newcastle are on top in this run. Congrats to them. 96 is a very impressive score to get and it indicates their site scores well for all performance measures Google uses. It also means there was a conscious effort by the developers to make the site fast as scores of 96 don’t just happen.
Very low request payload size of around 1.7mb and very low request count of around 47.
While they don’t use Googles WebP Image format they do appear to be compressing images to 80% quality which results in significantly reduced file sizes and contributes to the low 1.7mb payload above. The largest image download is 355kb. That being said Google estimates lossy WebP images are 25-34% smaller than equivalent JPGs and many CDNs can automatically serve WebP to the user so there appears to be some very small scope for improvement here.
Joint best First Contentful Paint time of 0.6s. FCP measures how quickly the first piece of text or image is painted. Newcastle’s site appears to load almost straight away. Contrast this with West Ham who have an FCP of 1.7s which means the user has to wait before seeing anything happen.
Low Time to Interactive of only 1.5s. TTI measures the time when the user is fully able to interact with the page. Many sites appear to be ready as they have a low FCP (above) and low Largest Contentful Paint but to actually use the site some scripts still need to finish running or some other resource still needs to download. Low total requests, small request sizes and limited JS execution help here.
Only Everton have a lower TTI than Newcastle at 0.9s. We can again contrast this with West Ham who have a TTI of 10.7s which is huge.
Total Blocking Time of only 10ms is seriously impressive due to limited blocking requests for JS and CSS as well as limited JS execution.
Cache time of only 30m on their JS, CSS and font files. These files are only small but 30 mins is quite low and many fans would visit the site multiple times a day (particularly on match days) so not sure why these are set so low.
PageSpeed is flagging that a percentage of the loaded CSS and JS is unused and we can see from the Chrome Developer Tools coverage tab below (click on the image for a larger view) that this is indeed the case.
Removing it would further reduce overall request size down on the homepage BUT its possible that the JS and CSS represented in red above is used on other pages and for ease of development the whole site just shares a common layout or header which includes the same JS and CSS for all pages.
Have been on top the odd time as their home page is very fast and have seen them getting above 90 too and thus entering the ‘Good’ category.
Homepage is a splash page for the shop. No actual content in terms of news or interviews etc. on the homepage so while their score is great its a lot easier to get high scores when your page is simpler so this makes Newcastle’s site stand out even more.
BUT Everton are doing pretty much everything they can do performance wise on their page..
Only 18 requests at around 1.5mb of total request size is hugely impressive and beats all other teams.
Page visibly starts to visible load (FCP) very early at only 0.6s (matching Newcastle and City) but is ready to use (TTI) at 0.9s which is less than Newcastle’s and the lowest of all teams.
Some requests served over HTTP/1.1.
The only measure out of the six that Everton don’t score ‘Good’ on is Largest Contentful Paint which is the time the main image or text block is written to the page. Two examples of LCP are below. The first example shows the main image or text block is loaded last.
BUT the second example shows that the largest image or text block doesn’t have to load last.
Everton’s LCP time is 2.1s compared to 1.1s of Newcastle’s. Both very good and even better when compared against an LCP of 10s for Wolves.
Everton have matching or better scores than Newcastle for everything except LCP and given that it’s weighted at 25% (full breakdown below) this is why Everton are 2nd.
If Everton really wanted to beat Newcastle.. and who doesn’t they can aim to lower their LCP time. According to Google..
In Everton’s case they could try to remove the very small amount of render blocking resources they have by inlining critical JS and CSS and deferring or removing the rest.
** Remember **
The times here are small but could make a difference particularly on slower connections. To find out what actual CSS is needed on a page the Chrome Developer Tools Coverage tab (Edge has it too) can be used.
In Everton’s case they only pull in one stylesheet but 98.6% of the CSS in it is unused (on the homepage) and so inlining the 1.4% that’s actually needed would reduce blocking and negate the need to download the stylesheet at all. The Coverage tab will show you exactly what CSS is used so this is what can be made inline.
As noted above many sites have a shared or common layout page which includes all required CSS and JS files for all pages so while Google PageSpeed or Chrome Developer Tools may flag some CSS as redundant on a particular page it may be used on other pages.
The ideal technical setup from a performance perspective is that pages only ever include CSS and JS that they need. The trade off from this however is that its technically more difficult to implement but a lot depends on what actual publishing platform or CMS is being used.
Finally although they are image light given that their Largest Contentful Paint element is their main splash image which is 354kb another thing they could try to lower LCP is serve WebP images rather than JPGs which will allow them to save 25-34% bytes.
Always 3rd in the table any time I’ve put all teams through the PageSpeed API. Really nice looking fast loading site, one of my favorites.
2.2mb request size, 56 requests.
Images load progressively as you scroll down the page. Highly optimised images with very small file sizes. Could implement WebP but savings would be small although it could make a difference on slow mobile connections. If using a CDN which supports it, it could be very easy to configure.
No caching on many resources but this may be deliberate. This won’t affect their score as PageSpeed won’t ever cache items but 99% of visitors are probably return visitors (fans) so caching these resources will help. It looks like they might be using AWS CloudFront so caching is likely to be a configuration setting somewhere and easy to trigger.
BHAs lower overall score compared Newcastle and Everton is mainly due to a Total Blocking Time as this metric accounts for 25% of the overall PageSpeed score. BHAs time of 100ms is poorer than a good few other teams but compared to Man Utd (TBT 1450ms) they are not doing too bad. Their main stylesheet style.css is blocking, critical elements can be taken out and inlined to reduce TBT and First Contentful Paint.
Fulham have scored 75 in this run, but have seem them score as high as 89 (on a Sunday evening) so there might have been a large load on their server or redirected traffic at the time of running.
Around 3.6mb total request size and 88 requests which isn’t too bad
but serving some requests over HTTP/1.1 which means no multiplexing. Enabling HTTP/2 might prevent requests for certain resources having to wait which in turn might boost Fulham’s overall score.
Perfect Score of 0 for Cumulative Layout Shift which measures the amount of movement in a viewport. Unfortunately for Fulham this metric only accounts for 5% of the overall score. Everton also score a perfect 0. Compare this to West Brom who have a CLS of 1.14 which is huge (more on that later).
Doesn’t use WebP, opportunities to use this to compress images further and to reduce their overall request size and potentially bring down their Largest Contentful Paint time (currently 2.5s).
LCP makes up 25% of the overall score and in Fulham’s case it is the homebanner.jpg shown below in the network tab in Chrome Developer Tools. Its only 175 kb but since its served over HTTP/1.1 there might be more waiting time so its a good idea to reduce this image (and all others) as much as possible.
As an example I used ezgif.com to convert the original homebanner.jpg (copied here for long term reference) to a WebP lossy image at 85% quality and the resulting file size was 67.5kb. If you open them side by side in different tabs and flick back and forth you’ll see some very slight sharpness differences .. but football fans don’t care about this..
Around 150 requests and high 7mb+ total request payload
Payload above is mostly images which makes up over 6mb in total. Most images are moderate BUT one image is about 1.9mb. This isn’t as big as the 3+mb GIFs West Brom serve but its still huge.
Google PageSpeed (manual run) flags these images as not being served in formats such a WebP to enable reduced file size.
Looks like quite a lot of savings can be made. Looks like Leeds uses CloudFront as their CDN but I’m not sure if that supports serving WebP automatically to browsers that support it.
Serves some resources over HTTP/1.1 which doesn’t support multiplexing so some requests may be queued until others complete. Most browsers enforce a maximum of six TCP connections per host.
Here’s what the network tab from Chrome Developer Tools likes like for some of the images Leeds serve over HTTP/1.1. The white bars to the left of the green indicate queuing due to unavailable TCP connections. Some of the requests highlighted in red were queuing for 1.5 seconds. Click on the image for a larger size.
While here’s a snapshot from Google Developer Tools showing the waterfall timeline for images served over HTTP/2.. much less queuing time (but not zero queuing time).
The funny thing is both sets of images seem to be served from CloudFront CDN
High request size – about 7.5mb. Although when I run Palace through a manual run and directly in Google with Developer Tools open payload appears to be closer to 10mb… likely the page has changed.
High request count – 208
A couple of 1mb+ images. Not good for mobiles with slow connections and likely to hurt scores such as Largest Contentful Paint.
Making use of WebP for a good few images but not the very large ones.
Largest Contentful Paint of 5.5s. Only a couple of teams have higher. Largest Contentful Paint has a very strong relationship to total request size and total request count. When both are high LCP also seems to be high (in most cases).
Amongst the lowest overall request transfer size at around 2.2mb
Moderate amount of requests at around 120
Not serving WebP images but are serving highly optimized ones with low request size which helps keep payload at around 2.2mb. Images load as you scroll down the page. Similar to BHAs site, might use same provider/platform.
Relatively high Total Blocking Time of 340ms which is much higher than everyone above and higher than many below. TBT counts towards 25% of the overall score so is definitely lowering Arsenals score.
Scored 58 on this run, but have seen them score a lot higher and be as high as 5th in the table on occasion.
153 requests and 2.6mb overall request payload which is really good
In the below PageSpeed screenshot from a manual run JS execution time was 2.7s. We can see many of these resources are third party so City may be limited in what they can do here but it looks like something in nr.js is running slowly.
Joint best First Contentful Paint time of 0.6s. This is the time when the first image or text is painted to screen. 0.6s matches with Everton and Newcastle and can be West Ham FCP of 1.7s.
A very moderate 82 requests BUT a huge 13.5mb of total request transfer size. Only Wolves with around 22mb have higher. Compare 13.5mb to Everton’s best in league total request size of only 1.5mb.
I thought the 1.9mb image Leeds were serving couldn’t be outdone but I was wrong. West Brom are serving four huge images at 3.3mb, 3.2mb, 3.2mb and 2.7mb which is well over 12mb.
These are actually very small animated gifs which are displayed well below the fold and I can see that Google flags them in the manual run I did…
and we can see in the network tab in Developer Tools in Chrome that there is a huge amount of download time as indicated by the four blue bars. Click on the image for a larger view.
Optimising those GIFs or switching to a video format as Google suggests could dramatically cut overall request size which in turn should impact Largest Contentful Paint times. A potential problem here though is that these GIFs look to be advertisements for their main shirt sponsor so there may be commercial constraints here as obviously the advertiser would want their advertisement looking as well as possible.
Serves many requests over HTTP/1.1 which results in queuing of requests as shown above in the white bars which I’ve highlighted in red.
Decent Total Blocking Time of 70ms which is bettered by only five other teams. TBT accounts for 25% of overall Google PageSpeed Score so their TBT time here is saving them from being even lower.
West Brom have the highestCumulative Layout Shift value of all teams in the league. Remember CLS measures the amount of unexpected layout or element changes on a page from one rendered frame to another. A lower score is better as it means the page is more stable.
West Broms CLS is 1.139. Everton and Fulham both achieved a perfect zero score. Google considers anything over 0.25 as poor.
According to Google…
From Google PageSpeed we can see that in West Broms case most of the elements which cause the largest layout shifts are those with images in them. This is because the images don’t have explicit width and height dimensions set so the browser doesn’t know what space to reserve until the actual image is finally downloaded.
And we can see what CLS on West Broms page looks like in practice below. Please click on the image for a larger view.
Note between initial load and final load the navigation links shift to the left, while all the images and hence the associated headlines shift to the right. According to Google this results in a poor user experience, I tend to agree.
Note Cumulative Layout Shift is part of Googles Core Web Vitals which are three metrics (also including Largest Contentful Paint which is measured in PageSpeed) they believe are essential to measuring user experience on the web.
Google believes having more websites score well for their Core Web Vitals will improve the overall quality of the web and thus have indicated that from sometime in 2021 they will be including them as ranking signals for search. This won’t matter to football clubs like West Brom as there’s only one West Brom so they are not in competition with other sites for top spot on Google but if your an ecommerce site with a bad CLS your ranking could take a hit.
High amount of requests with 171 and large total request size of 6.5mb.
Largest image is 680kb which isn’t massive but with around 5mb of images served in either JPG or PNG they could potentially switch to WebP (or further compress their JPGs) to reduce overall download size as indicated by the PageSpeed results from a manual run.
Moderate First Contentful Paint (1.1s), Largest Contentful Paint (2.9s) and Cumulative Layout Shift (0.215).
Loading a huge amount of data (21-22MB), mostly images. Imagine being on a capped possibly slow speed mobile plan and having to download 22mb of data.
Some absolutely huge images including one at 1.7mb and a couple at 1.2mb. This single 1.7mb image is equal to Newcastle’s entire request payload and is even .2mb larger than Everton’s. It is not the largest however… that honor goes to West Brom who serve a couple of 3+mb GIFs.
Most of their images are JPGS and can be converted into WebP format for a much reduced file size. Eg. this image of Mick McCarthy is 1.2mb (saved here for reference) while this Lossy WebP one is 113kb. Right click on them and open them each in a new tab and flick back and forth to review the differences, they are almost invisible BUT the WebP is 1mb smaller. Note the differences aren’t fully attributable to the WebP format as the original Jpg appears to be uncompressed anyhow.
Wolves have a highest in the league Largest Contentful Paint time of 10s (Newcastle have LCP of 1.1s). This is the time the largest image or element is painted to the screen and according to Google this can be directly impacted by slow resource load times for items such as images especially those that are above the fold. Note Largest Contentful Paint is a Core Web Vital and will be used in part to rank websites on Google from sometime in 2021 so its important to know how to keep LCP low.
Some of their images from their shop sub site are served via HTTP/1.1 which means potential blocking unlike HTTP/2.
Site has very good First Contentful Paint of 0.7s (only bettered by Everton, Newcastle and Man City at 0.6s each) and a total blocking time of only 70ms which isn’t bad at all and beats most of the other teams in the Premier League.
Unlucky to be in the red (0-49 score), have seen them higher.
Moderate request payload and request count at just under 4mb and 98 respectively.
Low First Contentful Paint of 0.8s so when you open the page it appears to start loading very quickly which is quite pleasing from a user experience point of view. Best is Everton, Newcastle and Man City (0.6s each). Worst is Wolves (10s).
Loading of main CSS blocking first rendering. To fix this they could potentially put the critical CSS inline and defer the rest until the end.
Doesn’t use WebP which overs superior compression of JPG to reduce download size however image size seems quite low already so their existing images seem to have been compressed. Images take up roughly 1.3mb which is very good, compare this to Wolves who have over 21mb of images to download.
Doesn’t use WebP which would allow reduction in overall request payload. Looks like they are using some kind of CDN(s) so its possible these CDNs will already support conversion to WebP on the fly, which could be a quick win for Spurs.
If you want to see how much JS or CSS in your site is unused you can use the Coverage tab in Google Developers Tools. Here’s a snippet from the Spurs homepage, click the image for a larger view. The red is unused code BUT can still block rendering.
In this run Chelsea were 4th from bottom but I’ve actually seen them a bit higher closer to mid table on a number of occasions but that’s the variability of the web. They do a lot of things right on the site.
Very moderate request payload at around 2.9mb
Uses WebP image format which contributes to the above low payload. It looks like enabling this was very easy for them as they just had to include a particular parameter in the image request URL to have Cloudinary automatically serve the WebP version to those browsers that support it.
Although its only weighted at 5% of the overall score Chelsea have the second highest CLS score which is lower only to West Brom. CLS or Cumulative Layout Shift measures the movement of visible elements within the viewport.
Google considers anything under 0.1 to be good, Chelsea’s score is 0.691 which means the page moves about a lot and thus isn’t really finished loading or ready to be used in a user friendly way. Compare this to both Everton and Fulham who have CLS perfect 0 scores.
Huge amount of requests at around 370 which is the largest of any team. The next highest is Villa with about 230 requests while Everton have only 18. Even with HTTP/2 there is lots of request queuing.
Huge Time To Interactive of over 10 seconds. This is likely due to the sheer volume of requests. Contrast this with Everton who have TTI of only 0.9s.
HugeLargest Contentful Paint time of 9.2 seconds, second only to Wolves. This is the time when the largest or main content on the page is loaded.
Looks like they are using Drupal 8 which is a very powerful and customizable CMS but it looks like a lot of the components are blocking the rendering which will impact both First Contentful Paint and Largest Contentful Paint times.
There are a number of ways to eliminate render-blocking resources but most involve inlining critical JS and CSS code and deferring the loading of others until the end. Of course the downside with inlining JS/CSS code is that it won’t be cached.
Drupal is a well used CMS so there are likely some plugins available to try to boost performance perhaps by combining some of the JS and CSS files although they are using HTTP/2 so the impact of bundling is less than if they were not.
Not sure why they are only caching some of their font files for a day.
Unfortunately some fundamental platform related issues here which might not be easy to fix.
Never seen them outside the bottom three (along with West Ham and Man United). 24 (joint bottom with United) is a pretty bad score so lots of room to improve.
Huge amount of requests at around 230-240. Only West Ham have a higher amount from all Premier League teams.
Relatively large payload with around 7mb of data coming down.
Large amount of requests served over HTTP/1.1 meaning no multiplexing and almost certain request queuing. Below is from the Network tab in Chrome Developer Tools. The white bars indicate request queuing due to max TCP connections already having been reached (6 per host).
Lots of opportunities to improve though…
For example most of their images are served as jpgs, however Google WebP format can offer much smaller file sizes and when Safari 14 is released it will be almost universally supported. Looking at one image on the Villa site…
we can see large reduction can be achieved. Of course the downside of using WebP is that unless you use a CDN that can automatically convert and serve a WebP for you you’ll need to host both JPG and WebP in order to serve JPGs to users who don’t support WebP.
One other way Villa can reduce their request payload without much hassle is by enabling text compression on their CDN provider which seems to be AWS Cloudfront. Cloudfront supports this as of a few years ago. An example of the potential saving is…
This wouldn’t have happened under Fergie but the Utd site is always in the bottom three and nearly always last, although in this case they scored 24 which is tied with Villa.
Moderate request size of 4.3mb and around 130 requests which isn’t bad compared to some others including the two teams immediately above them (Villa with 234 and West Ham with 371)
Due to above United have a highest in the league Total Blocking Time of 1450ms, the next highest team was Chelsea with 550ms, while Everton and Newcastle both have TBT of 10ms. Given that TBT is responsible for 25% of the overall score the long running JS is dramatically pulling down Utds score.
Images look optimised and are served in PNG or JPG.
The Good Newcastle for consistently scoring above 90. Everton and Fulham for a perfect 0 Cumulative Shift Layout score. Brighton and HA for progressive image loading as your scroll down.
The Bad Villa serving a large amount of requests over HTTP/1.1 Villa not enabling text compression on their CDN. Man Utds large DOM and JS execution time.
The Ugly West Brom serving images over 3mb Wolves total request size of around 21-22mb West Ham serving around 370 requests
Brotli can compress HTML, CSS and JS files more than Gzip. If you can’t enable Brotli compression on the server level but want to use it in your ASP.NET Core app you can use the response compression middleware to enable it from your Startup.cs file. Setup is easy and looks like below..
Note the app.UseResponseCompression() in the Configure method needs to be before app.UseStaticFiles() as otherwise headers have already been sent. The default setup above will use Brotli if the client supports it else it will use Gzip if it’s supported. By default the Brotli compression provider will be set to a compression level of 1 (fastest).
The compression level corresponds to how aggressive an algorithm will compress a document. Brotli has 11 levels, 1 being the fastest but least compressed and 11 being the most compressed but also the slowest. Brotli at its highest level (11) is extremely slow compared to Gzip at its highest level (9). Slow compression is fine for static CSS/JS files which we can compress ahead of time. For on the fly compression (eg. dynamic web pages) slow speeds can negatively impact web app performance..
.. for Brotli compression to be advantageous over Gzip we need to find the compression level which gives us the best balance between compression amount and speed..
Larger request sizes than required.
Slower first rendering of our pages if the unused code is referenced in external files rather than inline as these files will block the main thread from rendering.
Maintenance issues as its not clear what code is used and what isn’t.
it’s a good idea to remove unused CSS/JS as you go and finding it is easy with the Google Developer Tools Coverage tab.
Note this tool shows unused code for the specific page its run for, it can’t tell if code is used on some other page from the same site. Often sites have a shared layout file which includes all CSS/JS required for all pages. From a performance point of view ideally each page would only load the exact CSS/JS it needs however implementing this can be a challenge depending on what platform or CMS is being used.
Opening Google Developer Tools Coverage Tab
Open the command menu using Cmd+Shift+P on Mac or Ctrl+Shift+P on Windows, start typing Coverage and then select Show Coverage:
or access it through the right hand side menu…
Note Microsoft Edge also has this functionality as its a chromium based browser.