All Collections
Technical questions
Web Performance Optimizations: our recommendations
Web Performance Optimizations: our recommendations
Anthony Ribeiro avatar
Written by Anthony Ribeiro
Updated over a week ago

ℹ️ The optimizations described in this article are of an advanced level and advised to editors for whom the webperfs topic is a priority. Therefore, they are not mandatory actions for a good Poool Access integration but optional optimizations. Are you still here? Let's go!

Preconnect

When your visitors load a page, it calls the sub-domain assets.poool.com. Once this first request is made, a call to our server is made.

To anticipate this call and establish the connection as soon as possible, you can add a preconnect and a dns-prefetch in the <head> of your page.

<head>

<link rel="preconnect" href="https://assets.poool.fr">
<link rel="dns-prefetch" href="https://assets.poool.fr">

</head>

Preload and loading conditions

If your wall appears high in the page, i.e. above or just below the fold, we recommend forcing the preload of the Poool Access script, in order to optimize the wall loading process:

<head>

<link rel="preload" as="script" href="https://assets.poool.fr/access/min.js">

</head>

On the other hand, if the wall is located way below the fold, then it is better to slightly delay the loading of the JS Poool, by conditioning it to an action of your users. Scrolling is an excellent trigger.

Integrate resources locally

To avoid the connection time needed to access the Poool server, we recommend to download the JS Poool resources on your own server and serve them locally. In this case, think about scheduling CRON jobs from your server in order to retrieve the latest resources every day and work with the most recent version (we recommend scheduling a daily job but if you want to switch to a more occasional mode, this is perfectly possible).

On the other hand, be careful not to concatenate the Poool SDK inside a local JS. This could slow down the execution of your content blocking. Here is an example of integration not to be reproduced:

Prevent CLS by reserving spaces

The CLS (or Cumulative Layout Shift) is a metric that is part of Google's guidelines to ensure an optimal browsing experience (and thus positions on the SERP).

Without going into too much detail (you'll find all the info here), the CLS measures the visual stability of elements when loading a web page. Have you ever noticed how, when a page starts loading, certain elements can suddenly change place and disappear from the screen? Unpleasant, isn't it? The CLS is used to measure exactly that.

In order to avoid generating too much CLS, you can reserve the spaces dedicated to the different elements of your page (your Google Adsense banners, the images of your articles, the Outbrain or Taboola components...). It's called lazy loading, and the technique used is the front-end one (more info here).

Lazy loading allows you to differ the elements loading. Here, before/after the loading of an advertising banner on lepoint.fr.

Thanks to this technique, you can reserve the place of the wall in your page, and thus avoid the shift of elements created by different loading times.

💡 To go further, check this help page.

It is also strongly suggested to use lazy loading to load all images on your pages (especially those below the fold). This would improve your FCP (another metric taken into account by Google, the First Contentful Paint).

Fonts

When you have too many font files to load (as in the example below 👇), the page is unnecessarily weighed down. Even worse, some texts are not shown on the screen until their font is fully loaded.

We advise you to limit the number of fonts loaded on your pages to what is strictly necessary (generally 2 to 3 files maximum).

Also, you can add the attribute font-display: swap; to the fonts in the internal CSS and &display: swap; to the fonts loaded from Google in order to call a fallback font and prevent the non-display of your texts.

Here is the impact on Core Vitals metrics according to our tests:

Images: weight and format

This is usually where things get stuck. Yes, images often weigh (too) heavily on loading times, even though this is probably the easiest optimization to achieve.

In the example below, we uploaded an image in the appearance editor with a size of 762 kb and dimensions of 5760x3840 px, while the space reserved for the image in the wall is much smaller (138x448 px in this case). The uncompressed image is therefore loaded unnecessarily and generates a huge weight, which will in turn impact the overall loading time of the page.

The dimensions of the images embedded in the walls are mostly smaller than the basic dimensions of the imported file.

We don't advise you to resize your images to the exact height x width format for each image you want to integrate in a wall. This would be time-consuming and there are other techniques that are much easier to implement:

First, identify the weight of the image(s) you want to embed. No image should be larger than 100 to 200 kb inside your wall. Good news, there is a very simple tool, Squoosh (developed by Google), which allows you to easily reduce the weight of your images by playing on its visual quality. You can usually reduce the weight of your images by +90% without the visual impact being noticed by your visitors.

Example of an image whose weight has been reduced by 91% without significant visual loss between the left (original image) and right (the compressed version) parts. Squoosh.app

You can also go further by serving your images in WEBP or AVIF formats. These formats are compatible with all recent browsers and their advantage is to go much further in terms of compression than what is possible with the JPG or PNG formats.

Here is an example of the impact on an image if it was converted to WEBP (-51.3% reduction) and AVIF (-72.4% 🎉 ).

You are now a pro in web performance optimization! Some elements of this article can be applied more easily than others, depending on the availability of your technical resources and the particularities of your environment.

Do not hesitate to measure the impact of each of your implementations on the loading time of your pages and on the Web Vitals metrics (from your Search Console interface in particular).

If you wish to be accompanied in the implementation of optimizations in a more personalized way, you can contact the Eskimoz team.

Did this answer your question?