Optimisations des Webperformances: nos recommandations

ℹ️ Les optimisations décrites dans cet article sont d'un niveau avancé et conseillées aux éditeurs pour qui le sujet des webperfs est une priorité. Il ne s'agit donc pas d'actions obligatoires pour une bonne intégration de Poool Access mais bien d'optimisations facultatives. Vous êtes toujours là ? Let’s go !

Preconnect

Lors du chargement d'une page par vos visiteurs, celle-ci fait appel au sous-domaine assets.poool.fr. Une fois cette première requête faite, un appel à notre serveur se fait alors.

Pour anticiper cet appel et ainsi établir la connexion le plus tôt possible, vous pouvez rajouter un preconnect et un dns-prefetch dans le <head> de votre page.

A noter que cette optimisation est surtout conseillée pour les walls s'affichant au-dessus de la ligne de flottaison ou juste en-dessous, de façon à garantir un affichage le plus rapide possible à vos lecteurs.

<head>

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

</head>

Preload et conditions au chargement

Là aussi, si votre wall apparait haut dans la page, c'est-à-dire au-dessus ou juste en dessous de la ligne de flottaison, il est intéressant de forcer le preload du script Poool Access, et ce afin d'optimiser le processus de chargement du wall :

<head>

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

</head>

A l’inverse, si le wall est situé bien en dessous de la ligne de flottaison, alors il est plutôt indiqué de retarder légèrement le chargement du JS Poool, en le conditionnant à une action de vos utilisateurs. Le fait de scroller est notamment un excellent déclencheur (plus d'infos un peu plus loin dans l'article).

Charger Poool de manière asynchrone

Dans le cas où la balise dans laquelle vous choisissez d'intégrer un wall ne s'affiche pas au-dessus de la ligne de flottaison, il n'est alors pas nécessaire de charger le JS de Poool immédiatement. Cela permet d'améliorer le temps de chargement des autres ressources visibles haut dans la page, et d'améliorer le LCP ainsi que les résultats d'audits (Lighthouse et, Webpagetest notamment).

Les attributs async ou defer sont alors conseillés (pour comprendre les différences entre les deux, vous pouvez consulter cet article) :

<script id="poool-access" src="https://assets.poool.fr/access.min.js" async></script>
<script id="poool-audit" src="https://assets.poool.fr/audit.min.js" async></script>

<script id="poool-access" src="https://assets.poool.fr/access.min.js" defer></script>
<script id="poool-audit" src="https://assets.poool.fr/audit.min.js" defer></script>

Ici l'exemple d'un éditeur dont les performances ont été significativement améliorées suite à une bonne priorisation des ressources externes grâce à l'attribut async (diagnostic Google Search Console) :

Amélioration des performances de chargement des pages chez un éditeur ayant différé le chargement de ses ressources non-prioritaires

Différer le chargement des scripts Poool au moment du scroll

Dans le cas où vous n'affichez pas de wall directement au chargement de la page, Poool peut être chargé de manière asynchrone via une promise basée sur une action de l'utilisateur : le scroll.

Pourquoi différer le chargement des scripts ?

Cela permet d'améliorer les performances d'une page web en ne chargeant les scripts que lorsqu'ils sont réellement nécessaires. C'est particulièrement utile lorsque vous avez des scripts volumineux ou de nombreux scripts sur une page, car leur chargement peut ralentir la page et créer une mauvaise expérience pour l'utilisateur, en particulier pour ceux qui ont une connexion Internet plus lente.

Dans le cas des scripts Audit et Access, il est intéressant de différer leur chargement jusqu'à ce que l'utilisateur ait réellement besoin de voir le wall présent sur la page. Cela permet de charger les autres éléments plus rapidement pour l'utilisateur et de ne charger Poool que lorsque c'est nécessaire.

Comment différer le chargement des scripts ?

Voici un exemple de code javascript dont vous pouvez vous inspirer :

window.addEventListener('scroll', function() {
    var scrollPosition = window.scrollY || document.documentElement.scrollTop;
    var offset = 1000; // Change this to the offset at which you want to load the script

    if (scrollPosition >= offset) {
        var script = document.createElement('script');
        script.src = 'https://assets.poool.fr/access.min.js'; // URL of your external script
        script.id = 'poool-access';
        script.async = true;
        document.body.appendChild(script);

        script.addEventListener('load', function () {
            Access
            .init('<your-app-id>')
            .config({cookies_enabled: true});
            .createPaywall({
                target: '#poool-widget',
                content: '[data-poool]',
                mode: 'excerpt',
                percent: 80,
                pageType: 'premium',
            });
        });
        
        // Remove the event listener to prevent loading the script multiple times
        window.removeEventListener('scroll', arguments.callee);
    }
});

Dans cet exemple, le script Access n'est pas chargé tant que l'utilisateur n'a pas défilé jusqu'à un certain point sur la page (défini par la variable offset). Une fois que l'utilisateur atteint ce point, le script est chargé et le wall est initialisé une fois le script complètement chargé.

Intégrer les ressources en local

Pour éviter le temps de connexion nécessaire pour accéder au serveur Poool, il peut être intéressant de télécharger les ressources du JS Poool sur votre propre serveur et de les servir en local. Dans ce cas, pensez à programmer des CRON jobs depuis votre serveur afin de récupérer chaque jour les ressources à jour et ainsi travailler avec la version la plus récente (nous recommandons de planifier une tâche quotidienne mais si vous souhaitez passer sur un mode plus espacé, cela est tout à fait possible).

En revanche, attention à ne pas concaténer le SDK Poool à l'intérieur d'un JS local. Cela risquerait de ralentir l'exécution du blocage de votre contenu. Voici un exemple d’intégration à ne pas reproduire :

Éviter le CLS en réservant des espaces

Le CLS (ou Cumulative Layout Shift pour les intimes) est une métrique faisant partie des consignes de Google pour garantir une expérience de navigation (et ainsi des positions sur la SERP) optimales.

Sans trop rentrer dans les détails (vous trouverez toutes les infos ici), le CLS mesure la stabilité visuelle des éléments lors du chargement d’une page web. Vous avez déjà remarqué lorsqu’une page commence à charger certains éléments, comment ceux-ci peuvent changer de place soudainement et disparaître de l’écran ? Désagréable, n’est-ce pas ? Le CLS sert précisément à mesurer cela.

Afin d’éviter de générer trop de CLS, vous pouvez réserver les espaces dédiés aux différents éléments de votre page (vos bannières Google Adsense, les images de vos articles, les composants Outbrain ou Taboola…). Ça s’appelle le lazy loading, et la technique utilisée est celle de façade (plus d’infos ici).

Le lazy loading permet de différer le chargement des ressources. Ici, avant/après le chargement d’une bannière publicitaire sur lepoint.fr.

Grâce à l’utilisation de cette technique, vous pouvez réserver la place du wall dans votre page, et ainsi éviter le décalage des éléments créé par des temps de chargements différents.

💡 Pour aller plus loin, consulter cette page d’aide.

Il est également fortement suggéré d’utiliser le lazy loading pour différer le chargement de vos images situées en-dessous de la ligne de flottaison. Cela permettrait d’améliorer votre FCP (une autre métrique prise en compte par Google, le First Contentful Paint).

Fonts

Lorsque vous avez un trop grand nombre de fichiers fonts à charger (comme sur l’exemple juste en dessous 👇), la page est inutilement alourdie. Pire encore, certains textes ne sont pas montrés à l’écran tant que leur font n’est pas entièrement chargée.

Nous vous conseillons de limiter le nombre de fonts chargées sur vos pages au strict nécessaire (en général 2 à 3 fichiers au maximum).

Également, vous pouvez ajouter l’attribut font-display: swap; aux fonts dans le CSS interne et &display: swap; aux fonts chargées depuis Google afin d’appeler une font en fallback et ainsi empêcher le non-affichage de vos textes.

Voici l’impact sur les métriques Core Vitals selon nos tests :

Source : www.webpagetest.org

Images : poids et format

C’est en général ici que ça bloque. En effet, les images pèsent (trop) souvent sur les temps de chargement.

Précédemment, nous avions l'habitude de vous conseiller de compresser vos images avant de les intégrer sur l'une de vos apparences de walls.

C'est désormais de l'histoire ancienne, toutes les images que vous intégrez étant automatiquement converties dans notre éditeur d'apparences au format Webp !

ℹ️ Le format Webp a été créé par Google dans le but de remplacer les différents formats d’images standard : jpeg, jpg, png, gif, tiff… et de permettre une compression sans perte visuelle.

Vous êtes maintenant pro dans l’optimisation des web performances ! A la lecture des différents éléments de cet article, certains peuvent s’appliquer plus facilement que d’autres, selon la disponibilité de vos ressources techniques et les particularités de votre environnement.

N’hésitez pas à mesurer l’impact de chacune de vos mises en place sur le temps de chargement de vos pages et sur les métriques Web Vitals (depuis votre interface Search Console notamment).

Si vous souhaitez être accompagné dans la mise en œuvre d’optimisations de manière plus personnalisée, vous pouvez contacter l’équipe Eskimoz.