Performance: No critical CSS loaded in <head>

Since no critical CSS is defined in <head>, the browser must download all assets before it can render the page.

Best practice is to optimize the critical rendering path by inlining critical CSS in the <head>, which allows above-the-fold content to render in the browser without waiting for the rest of the CSS to load.

See: ​https://web.dev/extract-critical-css/

Performance: JavaScript loaded before Style sheets in <head>

<script>-tags are loaded before style sheet <link> elements in the <head>.

If scripts are found and loaded before the stylesheet, a delay is added and causes the page to render more slowly.

See:

https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render -blocking-css

Performance: Several synchronous JavaScript requests

For every JavaScript file that the browser needs to load, it will send a separate HTTP request.

If these are synchronous requests then the browser will need to allow each one to finish before moving on to the next.

Reduce the number of synchronous javascript by merging scripts and then load asynchronously when possible.

See: ​https://web.dev/efficiently-load-third-party-javascript/

Performance: Oversized images and suboptimal formats

The CMS delivers oversized images which are then scaled by the browser. This is bad for performance as it takes extra CPU time and the user ends up downloading data they don’t use.

The CMS should scale the images, convert them to web-friendly formats, and use modern techniques to deliver images in the correct resolutions according to the device type.

See: ​https://web.dev/uses-responsive-images/

Performance: No lazy-loading of images

Images that are offscreen (below-the-fold) and not visible to the user are loaded during the initial request.

Lazy load the images to reduce time to interactive. See: ​https://web.dev/lazy-loading/

Performance: Poor server response

The web host has a high ​Time To First Byte: for some URLs, it takes two seconds to load the first byte of data when a connection is established. Apply modern caching techniques.

See: ​https://web.dev/time-to-first-byte/

Performance: Total page size too big for 3G connections

Pages have a total byte size (of the page and all the resources) greater than 1600KB.

This is too big for a time-to-interactive of 10 seconds on a 3G connection and means that the page is very slow loading on mobile, which negatively affects user experience.

See: ​https://web.dev/total-byte-weight/