Fast page loads result in higher user engagement, more pageviews, and improved conversion.
Resources are minified using gulp-clean-css and gulp-uglify.
Additionally, we can keep file sizes down by:
Making good use of single-purpose styling classes instead of using overly complicated BEM variations for things like background colour amends (etc); these small snippets of code reduce down lengthy and difficult-to-maintain variations of rows.
Where possible, avoid the use of larger-than-necessary third-party libraries to keep the overall page size down; opting instead for our own functionality or a slimline version of the library.
If we need to package up images with this design system, they should be compressed and minified like we do with other resources. There are gulp packages available to achieve this.
For the CMS project, we can pass the media through the Azure Function built to resize and optimise images.
You can improve your page load speed by inlining links and scripts that are required for first paint, and deferring those that aren't.
As a general rule, async should be used with imports as much as possible to defer loading scripts until resources are freed up and critical first paint has been served.
Not as common as loading scripts asynchronously, but still possible by changing the rel of the link element to preload from stylesheet and then changing back onload, for example:
<link rel="preload" as="style" onload="this.rel='stylesheet'" href="/css/essential.css" />
Additionally, the styling has been split into two parts; essential.css and non-essential.css.
For improved pagespeed performance, the essential stylesheet should be preloaded and rendered using the async methodology above, or if possible output into the header of the HTML file for no network latency at all.
The non essential styles should not be called until the end of the page, to reduce down render blocking.
Images that sit below the fold are not required until the user scrolls them into view (if the user scrolls them into view). By deferring the download of these images, this reduces down the amount of resources required on page load and speeds up first paint times.
Alternatively, a low-res image can be used in the first instance so that there is at least a placeholder in the images place; while they slowly get switched out for better quality alternatives - this also improves first paint times, with improved user journey (always something available to see).
The YouTube embed is quite large (around 700kb before any of the video content has even been loaded), so by deferring this until it's actually requested we save a lot of network traffic for the user; improving page size and response times.
A dummy player is put in the place of the YouTube embed; with the actual embedded iframe only loaded in when a user clicks to play the video.
It's recommended that we use Google Lighthouse scores to test the performance of the front-end, and amend where possible. Ideally we'd look to score green which can be impossible to predict with a CMS and third-party content.