Améliorez la vitesse du site grâce aux audits des annonces des éditeurs pour Lighthouse

Publié: 2020-06-05
Améliorez la vitesse du site grâce aux audits des annonces des éditeurs pour Lighthouse

Ce message a été mis à jour pour la dernière fois le 6 septembre 2021

Il y a eu une augmentation des demandes des éditeurs concernant la vitesse de chargement de leurs pages et le comportement général de leurs sites. Dans l'article d'aujourd'hui, nous examinerons certaines des questions que les éditeurs ont soulevées, et plus tard, nous vous montrerons comment créer vos propres rapports et mieux évaluer la situation de chargement de votre page.

#1 – Le site se charge lentement et a un faible score sur les outils de création de rapports

Il est important de comprendre que le comportement final d'un site est le résultat deplusieurs facteurs : la technologie utilisée pour construire la page, le nombre d'éléments affichés sur le site, la manière dont ces éléments sont stockés, les calculs effectués à l'exécution, etc. Outils de reporting ( tels que LightHouse, dont nous parlerons plus tard) identifieront ces problèmes.Notez que ces problèmes ne sont pas liés à notre code puisqu'ils sont une conséquence de la façon dont le site est construit.

#2 – Le code de MonetizeMore a rendu le site lent

Plus le nombre de blocs d'annonces sur une page est élevé, plus il y a d'éléments à charger. Il y a donc toujours uncompromis entre la vitesse de la page et les revenus à prendre en compte.Les éditeurs doivent en être conscients à tout moment. Notre code n'a pas d'impact significatif sur les performances du site.Le script publicitaire MonetizeMore s'exécute de manière asynchrone , ce qui signifie que, pendant que le processus d'enchères d'en-tête est en cours d'exécution, le reste du site continue de se charger comme il le ferait sans notre code.Lors de l'exécution d'enchères d'en-tête, il est inévitable que le script de chargement de l'annonce retarde le rendu de l'annonce jusqu'à ce que le délai d'expiration de l'enchère soit atteint, un autre compromis qui doit être pris en compte. Le délai d'attente recommandé par défaut est de 2000 ms pour trouver un équilibre sain entre la vitesse de chargement de la page et de bons taux de remplissage Header Bidding. La réduction de ce délai peut aider à réduire le temps de chargement, uniquement si la page se charge plus rapidement que le délai défini. L'abaissement de votre délai d'attente d'enchères d'en-tête augmente les chances que l'enchère d'enchères d'en-tête se termine avant que tous les enchérisseurs configurés ne renvoient leurs offres finales.

Phare

Nous utiliserons les audits des annonces des éditeurs pour Lighthouse à l'avenir, et vous pouvez les trouver ici : https://developers.google.com/publisher-ads-audits

Même si notre script n'est peut-être pas le principal responsable des performances de la page, les performances de la page ont un impact sur le trafic, et cela devient donc un problème important pour nous. Faites votre propre évaluation du site et essayez de répondre aux suggestions/avertissements.

Avec Chrome :

1.- Ouvrez la page Web cible

2.- Faites un clic droit et sélectionnez Inspecter

Faites un clic droit et sélectionnez Inspecter

3.- Parmi les outils de développement, recherchez le dernier, appelé Audits

Audits des annonces pour Lighthouse

4.- Sélectionnez les catégories pertinentes et cliquez sur "Générer un rapport". Après plusieurs actualisations du site, un rapport sera généré et affiché.

capture d'écran du phare

Vous verrez plusieurs catégories dans lesquelles la page a été évaluée :

  • Performance : exécution technique de la page, qui comprend l'interactivité, la vitesse et le codage.
  • Accessibilité : éléments de conception qui permettent aux personnes ayant des handicaps spécifiques d'interagir plus confortablement avec le contenu
  • Best Practices : recommandations générales, principalement pour améliorer la navigation et la sécurité
  • SEO : optimisations pour les moteurs de recherche pour interagir avec le site
  • Application Web progressive : PWA est un type spécifique de site qui ressemble fortement à une application mobile, dans la présentation et sous le capot. Voici des suggestions d'optimisation pour ce type de site Web.

La plupart de ces informations sont assez simples. Nous devons porter une attention particulière aux performances -> Diagnostics, où nous pouvons voir les performances des codes js, et en particulier les nôtres.

Diagnostique

Dans l'image ci-dessus (Diagnostic -> Réduire l'impact du code tiers), on voit que notre code bloque moins d'un tiers de seconde dans le thread principal (le thread qui se charge de charger la page). Aucun de ces codes ne bloque beaucoup le thread principal, mais l'ensemble du groupe de codes tiers utilise une seconde entière du thread principal, ce qui est finalement ce que les utilisateurs expérimentent.

temps d'exécution javascript

Dans l'image ci-dessus (Diagnostic -> Réduire le temps d'exécution de JavaScript), nous voyons que notre code s'aligne sur le reste des codes en temps d'exécution. Même si le temps d'exécution était plus élevé, cela se fait dans un autre thread de manière asynchrone, donc cela n'affecte pas les performances.

Considérations

  • Vous pouvez effectuer un test simple en exécutant ce rapport sans nos balises, puis ajouter nos balises et réexécuter le rapport. Comme mentionné, les compromis feront baisser le score total, mais cela est attendu.
  • La plupart des tests/scores de vitesse de page ne tiennent pas compte du délai requis lors de l'exécution des enchères d'en-tête et sont conçus pour évaluer les balises d'annonce codées en dur. Ainsi, lors de l'exécution sur une page avec une enchère d'en-tête active, ils ne prendront pas en compte la fonctionnalité personnalisée et en réduiront le score.
  • Vos propres plugins Chrome peuvent fortement modifier les performances du rapport lui-même. Vous pouvez essayer de tester la page dans un environnement plus propre :
    • Rendez-vous sur la page suivante : https://developers.google.com/publisher-ads-audits.
    • Coller l'adresse du site
    • Dans Paramètres avancés, activez Exécuter des audits Lighthouse supplémentaires.
    • Cliquez sur Générer un rapport
    • *Ce rapport vous donnera également le rapport sur les annonces de l'éditeur. Si le site est correctement configuré, le score doit être élevé, ce qui peut être un bon moyen de montrer aux éditeurs que tout problème de performances se situe probablement ailleurs.
  • Si l'amélioration des performances est indispensable, vous pouvez envisager :
    • Réduire le nombre de blocs d'annonces sur une page
    • Déplacer l'appel de script MonetizeMore vers la fin de la page ou plus haut, en fonction de l'implémentation d'autres appels JS/ressource lourds
    • Réduisez le délai d'expiration de l'enchère d'en-tête à une valeur où il n'y a pas de perte significative d'offres entrantes (peut être testé via PGAI : sous l'onglet des enchérisseurs, codage couleur des offres reçues)
    • Chargement paresseux de toutes les positions d'annonces sur toutes les pages. (Activez SPA dans dbAdmin et passez les DIV au format paresseux)

D'autres suggestions plus techniques peuvent être :

  • Améliorer la charge JavaScript : un seul appel à un script lourd ou de nombreux appels à de petits scripts auront un impact négatif sur les performances. Trouvez un équilibre entre les tâches et les appels dans JS. Cela ne peut être fait qu'avec des fichiers JS que le pub peut manipuler (pas notre script wrapper, GA ou facebook par exemple)
  • Assurez-vous que tout script pouvant s'exécuter de manière asynchrone le fait. Notre script le fait déjà
  • Assurez-vous que les ressources (images, vidéos) sont encodées avec les dernières technologies. Cela permet aux éléments d'être compressés pendant leur déplacement et de se décompresser lorsqu'ils se chargent sur la page.

Besoin d'aide? Créez un compte professionnel sur MonetizeMore dès aujourd'hui !