Premier League club websites ranked by Google PageSpeed performance score

PageSpeed Insights is Googles web page performance optimisation tool. It uses six audits to derive separate performance scores for mobile and desktop clients for a particular URL. Typically mobile scores are a lot lower as here Google simulates lower CPU and connection speed so images take longer to download, JavaScript takes longer to execute etc.

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.

PageSpeed Audits

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.

Desktop PageSpeed Scores for all Premier League teams

Newcastle-striker-Alan-Shearer

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.

so now lets look at each site…

Newcastle United – 96

Nufc.co.uk | Google PageSpeed Manual Run

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.

The Newcastle site achieves this low FCP by moving critical JS and CSS code inline while deferring other JavaScript and CSS until the end of the page meaning there is little to block the main thread from rendering. From looking at the page source it looks like only a single CSS (82kb) and a very small JS file (5kb) appear to be blocking the rendering of the first paint.

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.

Cache TTL

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.

Unused CSS and JS on homepage

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.

Great performance, very little to improve.

Everton – 89

Evertonfc.com | Google PageSpeed Manual Run

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.

CNN Longest Contentful Paint

BUT the second example shows that the largest image or text block doesn’t have to load last.

Google LCP

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.

PageSpeed audit weightings

If Everton really wanted to beat Newcastle.. and who doesn’t they can aim to lower their LCP time. According to Google..

LCP scores affected by

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 **

Why inline CSS and JavaScript

 

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.

Everton unused CSS

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.

Brighton & Hove Albion – 80

Brightonandhovealbion.com | Google PageSpeed Manual Run

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.

BHA no TTL

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.

Great site, not much to improve on.

Fulham – 75

Fulhamfc.com | Google PageSpeed Manual Run

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.

Fulham Network

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..

Leicester City – 70

Lcfc.com | Google PageSpeed Manual Run

Relatively low request count and total request transfer size.

Serves some resources over HTTP/1.1 which could slow things down.

Doesn’t minify CSS.

Cache TTL not set or set to 5 seconds for a lot of resources. Not sure why.

First Contentful Paint of 1.4s which is one of the highest in the league.

Leeds United – 68

Leedsunited.comGoogle PageSpeed Manual Run

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.

Leeds images

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.

Leeds http1 queueing requests

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).

Leeds Http2

The funny thing is both sets of images seem to be served from CloudFront CDN

dc6vmiz8c91pk.cloudfront.net – HTTP/1.1
d3k29occ4ttmt2.cloudfront.net – HTTP/2

so perhaps some configuration setting just needs to be turned on.

Sheffield United – 65

Sufc.co.ukGoogle PageSpeed Manual Run

About 4mb and 100 requests – pretty moderate.

Serves lots of requests over HTTP/1.1 and can see queuing as a request.

Image sizes are moderate. Mostly JPGs and PNGs but does use WebP for a couple of images. If they switch to all WebP they could reduce their request payload somewhat.

Score is pulled down by high Largest Contentful Paint time of 3.9s. 3.9s is higher than all teams above and seven teams below.

Crystal Palace – 61

Cpfc.co.ukGoogle PageSpeed Manual Run

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).

High LCP

Arsenal – 59

Arsenal.comGoogle PageSpeed Manual Run

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.

Large DOM of over 2.5 elements, only Man United have more with around 4k elements. Large DOMS can be problematic particularly when combined with inefficient JavaScript selectors which search through the whole document.

Burnley – 59

Burnleyfootballclub.comGoogle PageSpeed Manual Run

4.5mb request size and around 110 requests.

Uses WebP for a lot of images, but many larger ones are in PNG or JPG.

Time To Interactive of 5.2s is higher than most. One improvement that can have a particularly big effect on TTI is deferring or removing unnecessary JavaScript work.

Manchester City – 58

Mancity.comGoogle PageSpeed Manual Run

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

With the exception of three teams (Chelsea, Villa and Man Utd) City have the highest Total Blocking Time with 510ms. The bulk of this comes from JavaScript related overhead – mostly execution time.

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.

Man City JS execution time


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.

City are doing a good enough job but they might just need to reduce their JS footprint. Approx. 1.3mb and around 40 requests are related to JavaScript. To see which JS code is taking the most time you can use the JavaScript profiler in Chrome Developer Tools.

West Brom – 58

Wba.co.ukGoogle PageSpeed Manual Run

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.

Chris KamaraI 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…

WBA using large gifs

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.

WBH large images network tab

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 highest Cumulative 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.

CLS score breakdown

According to Google…

What affects CLS

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.

Large Page Shifts

And we can see what CLS on West Broms page looks like in practice below. Please click on the image for a larger view.

WBA homepage layout shift

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.

Liverpool – 54

Liverpoolfc.comGoogle PageSpeed Manual Run

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.

Liverpool jpg images

Moderate First Contentful Paint (1.1s), Largest Contentful Paint (2.9s) and Cumulative Layout Shift (0.215).

High Total Blocking Time of 270ms, only two teams above them have higher and at 25% weighting this is would be one of the reasons they are being pushed down the table. The main culprit for high TBT is usually long running and/or inefficient JavaScript. Liverpool have around 50 requests for JS files and execution time from a manual run is showing up at 2.4s which is large. Compare this to Everton who had around 0.1 JS execution time.

Liverpool long running JavaScript

Another metric which is dramatically affected by JavaScript related overhead is Time To Interactive which is the time the page is actually ready to use (rather than just looking ready). Liverpool’s TTI of 5.8s is significantly higher than anyone above them and higher than a few below them too.

Wolves – 52

Wolves.co.ukGoogle PageSpeed Manual Run

Chris KamaraLoading 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.

Site also has a very good Cumulative Layout Shift score of 0.005 which is amongst the lowest of all teams.

so… actually they do a lot of things well,  its just the massive images that is bringing their score down… so if they could reduce these I’d expect them to move right up close to the top.

Southampton – 48

Southamptonfc.comGoogle PageSpeed Manual Run

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).

Potentially lots of unused JavaScript and CSS which add to the request payload and unused JS is still parsed so if JS is genuinely not used (even on other pages) it should be removed.

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.

Spurs – 39

Tottenhamhotspur.comGoogle PageSpeed Manual Run

Almost 6mb of request payload and over 200 requests (including 38 JavaScript files), contrast this with Everton who have 1.5mb request size and only 18 requests.

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.

Relatively high JavaScript execution time (1.6 seconds in manual PageSpeed run)

Render blocking JS and CSS files contributing to a higher First Contentful Paint time of 1.4 seconds.

Google PageSpeed reporting a lot of unused JavaScript. If JavaScript isn’t used it still has a cost in terms of download time but also parse time.

Google PageSpeed only looks at the current page so its possible some of the JavaScript flagged as unused on the homepage is used on other pages and the site is just using a shared layout file which is common. Optimising for such a scenario can be difficult depending on what platform your on.

One other problem many sites face is that they depend on JavaScript (or CSS) files from external vendors which they can’t control. In this case they need to check if the loading of the JS can be deferred, made inline and run from the site itself or if the vendor has a more focused JS file specific to their needs.

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.

Unused JavaScript

Chelsea – 36

Chelseafc.comGoogle PageSpeed Manual Run

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.

I think the main reason they score low is the relatively high JavaScript processing time (2.4 seconds in the manual run of PageSpeed I did) which means both Total Blocking Time (25%) and Time To Interactive (15%) are increased.

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.

CLS grades

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.

Looks like they are using webpack which helps with optimisation of JavaScript and CSS. Good move Chelsea.

West Ham – 29

Whufc.comGoogle PageSpeed Manual Run

Large request payload of close to 9mb

Chris KamaraHuge 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.

Huge Largest 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.

Well over 100 JavaScript files

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.

West Ham Components

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.

Aston Villa – 24

Avfc.co.ukGoogle PageSpeed Manual Run

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).

Villa HTTP/1.1 queuing

Lots of opportunities to improve though…

Aston Villa ways to improve

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…

  1. Original image on the Villa site – 385kb (copied here for reference)
  2. Image converted to WebP Lossless – 300kb
  3. Image converted to WebP Lossy with quality set at 60% – 61kb

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…

Potential savings with compression turned on

Man Utd – 24

Manutd.comGoogle PageSpeed Manual Run

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)

Poor score mainly due to a huge DOM size of over 4K elements combined with a huge JavaScript profile. Looks like around 1.8mb worth of JavaScript requests which is even more than their image requests. The site has 5.3s JS execution time which is huge while Everton for example have 0.1 JS execution time.

United large DOM and large JS execution time

Large DOMs are particularly problematic when there is some JavaScript code that needs to search (eg. document.querySelectorAll) through it and manipulate it dynamically as this requires the browser to constantly compute and repaint new styles which can take a lot of time.

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.

Summary

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

Most Premier League sites could improve if they..
Reduce total request size/count.
Compress images aggressively (fans won’t notice/care).
Use Gzip/Brotli compression for HTML/CSS/JS files.
Use CDNs as teams have global fanbase.
Reduce render blocking JS/CSS from external files in the head section.
Limit JavaScript execution time. Keep an eye on third party libs.
Use HTTP/2 to limit queuing time.

Links

Jpg to Webp convertor

Gzip & Brotli compression tester
Check what compression a URL has enabled.

Gzip and Brotli Compression Level Estimator
Put a URL in and see how many byes could be saved using Brotli.

Extract Critical CSS

Optimize Largest Contentful Paint
Great article from Google on how to render your main content faster.

JavaScript Start-up Optimization
Great article from Google on the costs of JavaScript. Goes through parsing time on mobiles in particular.

Why does speed matter?

Feedback/Comments

Let me know if this was worth your time by commenting below. Thanks.

Setting a specific Brotli compression level when using response compression in ASP.NET Core

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..

Setting up MVC response compression

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..

SO

.. 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..

BUT

the problem with the Brotli compression provider in ASP.NET Core is that it only has three options in its enum for setting the level…

ResponseCompression Options

There is no enum option for the best balance between compression and speed. In this case we can just set the level with a number directly…

Setting Brotli Level

You need to experiment with different levels but a number of resources seem to be agreeing on level 4 or 5 as being the sweet spot…

https://blogs.akamai.com/2016/02/understanding-brotlis-potential.html

https://paulcalvano.com/2018-07-25-brotli-compression-how-much-will-it-reduce-your-content

https://quixdb.github.io/squash-benchmark/#results-table

Of course for your static content such as CS, JS, Fonts etc. compress to the max with 11. This will give you significant byte savings over Gzip.

 

Finding unused CSS and JavaScript with the Coverage tab in Google Developer Tools

Often over the course of time we add CSS and JavaScript to our pages without removing redundant styles and functions. This means…

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.

so

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.

The screen shot below (click on the image for a larger view) is taken from www.rte.ie and shows a lot of unused CSS and JavaScript as indicated by the red bars. The actual code that’s used in any particular CSS or JavaScript file is shown in the top half of the image.

RTE.ie unused CSS and JavaScript

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:

Opening the coverage tab

or access it through the right hand side menu…

Opening the coverage tab

Note Microsoft Edge also has this functionality as its a chromium based browser.

Extracting Google PageSpeed performance score in .NET

Most webmasters are aware that Google uses performance as a ranking signal for both desktop and mobile searches so its important your site is as fast as it can be. You can check your performance score according to Google in Chrome developer tools or online but since they provide a HTTP API you can get also get performance scores programmatically.

Calling the PageSpeed HTTP API and Serializing the JSON response into a DTO

Calling the API is easy as its a simple GET request as can be seen below…

How to call the PageSpeed API

You just need to make sure you set your key (you can get one from here but a key is not needed if your just testing) and the URL which you want to run the performance check for as query params. You can see above I’ve also set strategy which will default to ‘DESKTOP’ if not set.

After the response comes back (not very fast as the performance check takes a few seconds) I use the new System.Text.Json serializer released in .NET Core 3.0 to convert it into a simple DTO which matches the structure of the JSON. The performance score itself is located in lighthouseResult -> categories -> performance -> score.

As you can see to adhere with VS naming conventions I’ve made the properties start with uppercase and therefore needed to set the PropertyNameCasesInsentive flag above as otherwise the DTO would be empty after serialization.

Simple DTO for storing PageSpeed results

Calling the PageSpeed HTTP API and querying the JSON directly using JsonDocument

The above is nice and neat as we now have a strongly typed object which we could pass to our views etc. In this case however we only care about one property, the performance score itself so having to create a nested class or DTO just for this seems like a lot of effort.

Rather than serializing we can alternatively use JsonDocument and query the JSON string directly by chaining a couple of GetProperty calls together.

Use GetProperty to read JSON properties

Of course to use GetProperty you need to be sure the property will always exist in your JSON as otherwise an exception will be thrown. If your not sure about this use TryGetProperty instead and check if you’ve successfully got an element before moving on…

Use TryGetProperty to read JSON properties

Google PageSpeed Insights API Client Library for .NET

Google also has a PageSpeed API Client Library for .NET however I’ve not really looked into it much yet. Using this library over simple HTTP requests should allow you to have a more strongly typed approach where you don’t have to worry about matching JSON property names etc.

Googles WebP image format is approaching universal browser support but what is WebP and why should you care?

When Safari 14 drops around September or October 2020 (expected based on previous releases), support for the WebP image format will be pretty much universal as can be seen from the screenshot from caniuse.com below. But what is WebP and why should you care about it?

Browser support for Webp

What is WebP and why you should care?

WebP is Googles image format which they launched in 2010 and which is now part of their ‘Make the Web Faster’ initiative. Its claims to use a superior and more aggressive form of compression which results in smaller file sizes compared to JPG and PNG formats with only minimal, often imperceptible or negligible quality loss.

In terms of how much smaller WebP format files can be well Google claims that WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable (quality wise) JPEG images.

These figures are impressive, however by reducing the quality level when creating WebP lossy mode images even larger size file reductions can be achieved. When these images are viewed in isolation no obvious quality issues appear particularly at higher quality figures such as 80 or 90%. If you compare a JPG with a lossy WebP at 80% quality side by side and you know what to look for (perhaps your a photographer or graphic designer) you’ll spot small differences. For the vast majority of users on the web however the two images will essentially look exactly the same but one will have a significantly smaller file size. Apart from using less of the users mobile data monthly cap (if capped) smaller file sizes matter because…

Web pages load faster

Smaller images mean faster loading pages. Faster loading pages mean a better user experience and thus an increased likelihood of site engagement and conversion. For example the BCC previously reported that for every additional second in load time 10% of users left, whereas when looking at mobile only data a recent Deloitte Ireland report showed even a 0.1 second speed increase can make real differences to how much users engage.

Deloitte Report

Faster loading pages also mean potentially higher SEO rankings on Google as they have confirmed speed is a ranking signal (albeit a minor one) for both desktop and mobile searches. This means that not only do faster pages result in users converting more once they are on a site but it may mean more users visit in the first place.

Less bandwidth and CDN costs

Smaller images means less cost to you in bandwidth terms. Most hosting providers allow a certain amount of bandwidth per month and most CDNs charge per GB worth of data transfers. Below are the current costs for Azure CDN.

Azure CDN costs

It doesn’t take too much to reach a GB these days especially if your a popular site with lots of images, perhaps an ecommerce or news site or a site which has user generated content. In this case using WebP can result in significant savings by shaving at least around 20-30% off your image file sizes.

Manually creating and rendering WebP images with graceful fallback using HTML5 Picture tag

There are lots of online convertors which will allow you to convert JPGs and PNGs to WebP format images. These will require you to upload your images one by one, although some support bulk upload. Plenty of desktop software options exist too including Photoshop (with a plugin) and if you use Visual Studio there is a new extension called WebP Toolkit which will enable you to create WebPs from within VS itself.

After you’ve got your .webp images you can render them using the HTML5 picture tag. The below snippet will show image.webp for supported browsers and image.jpg for those that support the picture tag but not WebP. Finally for Internet Explorer and Opera Mini a legacy img tag is provided as fallback as they don’t support the picture tag.

WebP render with graceful fallback

Providing the .jpg fallback obviously increases (more than doubling) your storage needs so keep an eye on your websites analytics to see what browsers are actually being used to hit your site. With the release of Safari 14 in the next couple of months, the need to provide a jpg (or PNG) fallback with diminish quickly.

Generating WebP dynamically on the fly using CDNs or CMS plugins

Converting images manually and including them in your pages like above is fine for many websites but you may have user generated content or may not want or be able to explicitly convert your images each time your content changes. In this case you could look into using a CDN such as Akamai or Cloudfare which will automatically convert and serve a WebP version of your image based on the users browsers capabilities.

If your using a publishing platform like WordPress there a many extensions which can automatically serve WebP versions of images such as EWWW Image Optimizer.