Audit rapide à 4 vitesses

0
88


Nous savons tous que la vitesse, c’est de l’argent.

Un site plus rapide se convertit mieux, ce qui améliore les revenus.

Malgré l’impact direct de la vitesse sur les résultats, la mise en œuvre de recommandations d’amélioration des performances peut parfois être difficile car elle implique souvent la modification de code hérité qui pourrait affecter l’intégrité structurelle du site.

Cela est particulièrement vrai lorsqu’il s’agit d’améliorer les performances de JavaScript.

Alors que la flexibilité de JavaScript le rend facile à utiliser lors du codage des fonctions, cette même flexibilité (étant un langage dynamique et faiblement typé) le rend plus difficile à maintenir.

L’une des demandes souvent faites par les clients et les développeurs est de prioriser les améliorations de performances en fonction de la facilité et des ressources requises (en raison des contraintes de temps de développement).

Cela peut être assez difficile à déterminer, surtout si vous n’êtes pas un développeur et que vous n’avez pas une vue complète du code back-end du site.

Je contourne ce problème en classant ma liste en fonction des activités qui, selon moi, nécessiteront des modifications minimes du code du site.

Publicité

Continuer la lecture ci-dessous

Dans cet article, je présente quatre de mes correctifs rapides les plus récurrents.

1. Suppression des outils, widgets et technologies Web tiers

La plupart des sites Web s’appuient sur une technologie tierce pour le suivi, la surveillance, le support client (fonctions de chat) et bien plus encore.

Le défi avec la technologie tierce est qu’elle est généralement exécutée sur votre site à l’aide d’un code sur lequel vous n’avez aucun contrôle et ne peut donc pas améliorer ses performances.

Le nombre de scripts tiers chargés sur une page peut ralentir les performances de la page car les scripts proviennent de domaines différents.

Pour comprendre cela, vous devez d’abord comprendre ce qui se passe lors de l’accès à une page Web.

Lors de l’accès à une page Web, le navigateur trouve toutes les ressources qui nécessitent une recherche DNS (Domain Name System).

Le navigateur doit ensuite attendre la fin de la recherche avant de commencer à télécharger la page.

Cet événement repose sur la réponse rapide du serveur d’origine.

Lorsque le serveur répond, le code doit être lu et compris par le navigateur, puis vous être servi.

Publicité

Continuer la lecture ci-dessous

Bien que cet événement puisse prendre des millisecondes, multipliez cela par les recherches que le navigateur doit effectuer, puis incluez un temps de réponse lent du serveur à partir de l’un des domaines recherchés, ces millisecondes passent à quelques secondes.

La question ici est de savoir pourquoi porter un poids mort alors que vous n’en avez pas besoin?

Dans le cadre de mes audits, j’examine toujours la quantité de technologie tierce utilisée sur un site.

Le moyen le plus simple de le faire est d’utiliser des outils de recherche technologique tels que BuiltWith et Wappalyzer (plusieurs autres outils, payants et gratuits, peuvent être utilisés pour ce faire).

Ces outils sont utiles lorsque vous devez prendre une décision simple de conserver ou de supprimer.

Cependant, si la technologie est toujours utilisée et que vous devez évaluer l’avantage de la conserver par rapport à l’impact qu’elle a sur la charge du site, il vaut mieux utiliser des outils de diagnostic tels que Page Speed ​​Insight Tool et Lighthouse pour mettre en évidence l’impact sur les performances. .

Si vous êtes plus techniquement enclin, vous pouvez utiliser la fonctionnalité de blocage des demandes de réseau des outils de développement Chrome pour voir à quelle vitesse la page se charge lorsqu’un script ou une ressource particulier n’est pas chargé.

RequestMap de webpagetest.org est un autre bon outil pour visualiser l’activité de chargement.

Ce rapport vous donne une représentation visuelle de la taille des éléments transmis par octets à l’aide des données de requête Chrome.

J’utilise cela pour présenter l’impact de la technologie externe aux C-suites qui ne connaissent rien au codage.

Plus le site est ancien, plus les chances de trouver du code externe qui n’est plus utilisé sont élevées.

J’ai trouvé:

  • Scripts pour les boîtes de discussion qui ne sont plus utilisées.
  • Différentes versions de widgets de consentement aux cookies.
  • Pixels de suivi des annonces provenant d’un logiciel qui n’est plus utilisé.
  • Et – le pire de tous – utiliser un widget externe pour les boutons de partage social alors qu’un bouton CSS ferait l’affaire.

Ces scripts sont faciles à éliminer car ils n’affectent pas l’intégrité globale du reste du code sur le site.

Sinon, si vous devez conserver ces scripts, déplacez autant de scripts pris en charge vers Google Tag Manager (GTM) ou tout autre gestionnaire de balises que vous utilisez pour réduire le nombre de recherches DNS effectuées par le navigateur.

Publicité

Continuer la lecture ci-dessous

Consultez régulièrement les scripts du gestionnaire de balises pour vous débarrasser des scripts inutiles.

Vous pouvez également utiliser le déclencheur de chargement de fenêtre dans GTM pour retarder le chargement des scripts qui ne sont pas nécessaires dès que le visiteur arrive sur la page jusqu’à ce que la page soit complètement chargée.

2. Implémentez la prélecture DNS et la préconnexion

La prélecture et la préconnexion DNS sont des indications de ressources du navigateur qui peuvent être utilisées pour accélérer les recherches DNS.

Les navigateurs attendent généralement d’avoir besoin d’une ressource avant d’essayer de demander l’origine de cette ressource.

Pendant que cette ressource est demandée, le chargement de la page entière est suspendu jusqu’à ce qu’il soit résolu.

La prélecture DNS est un moyen d’appeler l’origine des ressources non critiques avant qu’elle ne soit nécessaire, ce qui accélère le temps de recherche en donnant au navigateur une longueur d’avance.

Vous pouvez pré-extraire des widgets tiers qui seront affichés au bas de la page comme des boîtes de discussion, des boutons de partage social, des widgets d’enquête, etc.

Fenêtre de la console JavaScript des outils de développement Chrome

La préconnexion est également utilisée pour établir une connexion précoce, mais doit être utilisée pour les ressources critiques pour le chargement de la page, telles que les actifs hébergés sur des réseaux de diffusion de contenu, les polices Web, etc.

Publicité

Continuer la lecture ci-dessous

3. Utilisez une seule bibliothèque JQuery lorsque cela est possible

Certains scripts tiers sont livrés avec une bibliothèque jQuery.

En termes simples, jQuery est une bibliothèque JavaScript qui simplifie l’utilisation des fonctionnalités JavaScript.

La plupart des sites Web modernes ont une forme de JavaScript, donc une version de jQuery est déjà chargée sur le site.

C’est un gaspillage de ressources d’extraire deux versions de cette bibliothèque sur votre site alors que vous n’en avez besoin que d’une seule.

Lors du chargement d’un script externe, demandez toujours une version qui ne charge pas sa version de jQuery.

Votre développeur peut ensuite définir le script pour utiliser la version globale en cours de chargement sur votre site.

N’oubliez pas de tester que le script que vous chargez est compatible avec la version de jQuery de votre site.

Utilisez la fenêtre de la console JavaScript des outils de développement Chrome pour voir la ou les versions de jQuery en cours de chargement sur votre site.

Tapez Ctrl + Maj + J pour ouvrir la console, puis tapez console.log (jQuery (). jquery); dans la ligne de commande.

Fenêtre de la console JavaScript des outils de développement Chrome

Yellow Lab Tools a une interface simple pour vérifier les versions de jQuery.

Résultat jQuery Yellow Lab Tools

D’autres moyens de réduire l’impact du chargement de fichiers jQuery incluent l’utilisation de la dernière version et la diffusion de jQuery via les bibliothèques hébergées de Google.

Publicité

Continuer la lecture ci-dessous

4. Supprimez les instructions CSS redondantes pour la prise en charge des anciens navigateurs

Plus le site est ancien, plus le nombre d’infractions est élevé.

La suppression des instructions CSS redondantes telles que la prise en charge des anciens navigateurs (correctifs IE) et des anciens préfixes est facile car il s’agit généralement d’un bloc de code distinct.

De nombreux outils mettent en évidence les CSS inutilisés sur un site.

Cependant, plutôt que d’avoir à parcourir le code ligne par ligne pour les anciens préfixes et la prise en charge du navigateur, Yellow Lab Tools vous offre une liste facile à comprendre que vous pouvez faire travailler votre développeur.

Yellow Lab Tools - Résultat des anciens préfixes

Assurez-vous de consulter votre outil de suivi pour voir le nombre de visiteurs qui utilisent encore ces anciens navigateurs et si les chiffres le justifient, vous maintenez le support en place.

Publicité

Continuer la lecture ci-dessous

En conclusion

Il existe de nombreuses technologies étonnantes qui améliorent la façon dont nous ciblons et suivons les visiteurs de notre site.

Bien que la vitesse soit toujours une préoccupation majeure, offrir la meilleure expérience aux utilisateurs sera toujours une priorité absolue.

Auditer régulièrement vos scripts externes vous aidera à offrir la meilleure expérience à vos visiteurs de la manière la plus efficace.

Plus de ressources:


Crédits d’image

Toutes les captures d’écran prises par l’auteur, octobre 2020



tout savoir sur la crypto