Un site plus rapide : 4 idées originales

Un site plus rapide : 4 idées originales

Un site plus rapide : 4 idées originales

La plupart d’entre nous ont fait des audits de vitesse sur les sites, ou ont vu des audits effectués par d’autres. Ces audits peuvent être très utiles pour les entreprises, mais je trouve souvent qu’ils sont très ciblés. En général, nous utilisons des outils bien connus qui nous permettent d’examiner un certain nombre de choses, puis nous nous plongeons dans les choses à partir de là.

Cependant, si nous creusons plus profondément, il y a souvent d’autres idées sur la façon d’améliorer la vitesse du site. Je vois souvent de nombreuses opportunités qui ne sont jamais couvertes par les audits de vitesse de site. La plupart des améliorations de la vitesse du site sont le résultat d’un tas de petits changements, et donc dans ce post, je vais couvrir quelques idées que je n’ai jamais vues dans un audit de vitesse de site, qui peuvent toutes faire la différence.

Un angle différent sur l’optimisation des images
Envisager des SVG optimisés plutôt que des PNG

Je cherchais récemment à réserver des billets pour voir Frozen 2 (à cause de, euh, mes enfants…) et j’ai donc atterri sur cette page. Elle utilise trois images SVG pour les icônes de transport :

Les images SVG sont des images vectorielles, donc elles conviennent bien pour des choses comme les icônes ; si vous avez des images affichées en PNG, vous pouvez demander à vos concepteurs les SVG originaux, car il peut y avoir des économies considérables. Bien que ce ne soit pas toujours mieux, l’utilisation d’un SVG permet d’économiser 60 % de la taille des fichiers.

Dans ce cas, ces icônes ont une taille d’environ 1,2k chacune, donc elles sont assez petites. Elles passeraient probablement inaperçues lors des audits de vitesse des sites (et ni Page Speed Insights ni GTMetrix ne mentionnent ces images pour cette page).

Vous vous dites peut-être qu’elles font moins de 5 000 en tout et qu’il faut chercher des problèmes plus importants, mais jetons un coup d’œil. Tout d’abord, nous pouvons les passer toutes dans l’outil de compression SVG de Jake Archibald ; c’est un excellent outil gratuit et sur des SVG plus grands, il peut faire une grande différence.

Dans ce cas, les fichiers sont petits, et vous vous dites peut-être encore : « Pourquoi s’embêter ? L’outil les compresse sans perte de qualité de ~1240 octets à ~630 octets – un bon rapport mais pas une grande économie globale.

Cependant… maintenant que nous les avons compressés, nous pouvons penser différemment à les livrer…

Images en ligne

GTMetrix fait des recommandations sur l’inlining de petits morceaux de CSS ou de JS, mais ne mentionne pas l’inlining d’images. Les images peuvent également être inlined, et c’est parfois la bonne approche.

Si l’on considère que même un très petit fichier image nécessite un aller-retour complet (ce qui peut avoir un impact très réel sur la vitesse), même pour les petits fichiers, cela peut prendre beaucoup de temps. Dans le cas des images de transport Cineworld ci-dessus, j’ai simulé une connexion « Fast 3G » et j’ai vu :

Le site n’utilise pas HTTP2, donc il y a une longue période d’attente, et ensuite l’image (qui fait 1,2 ko) met presque 600 ms à se charger (l’absence de HTTP2 signifie aussi que cela bloque les autres requêtes). Il y a trois de ces images, donc entre elles, elles peuvent avoir un impact réel sur la vitesse de la page.

Cependant, nous les avons maintenant compressées à seulement quelques centaines d’octets chacune, et les images SVG sont en fait composées de balises de la même manière que le HTML :

Vous pouvez en fait mettre le balisage SVG directement dans un document HTML !

Si nous faisons cela avec les trois images de transport, le HTML compressé pour cette page qui est envoyé du serveur à notre navigateur passe de 31 182 octets à 31 532 octets – une augmentation de seulement 350 octets pour les trois images !

Donc, pour résumer :

Notre requête HTML a augmenté de 350 octets, ce qui est à peine
Nous pouvons écarter trois allers-retours au serveur, dont nous pouvons constater qu’ils prenaient un temps considérable

Certains d’entre vous ont peut-être réalisé que si les images n’étaient pas en ligne, elles pouvaient être mises en cache séparément, de sorte qu’il ne serait pas nécessaire de les récupérer à l’avenir. Mais si l’on considère :

Chaque image était à l’origine d’environ 1,5 ko sur le réseau (ils ne gzippent pas les SVG), avec environ 350 octets d’en-têtes HTTP en plus, pour un total d’environ 5,5 ko transférés. Nous avons donc globalement réduit la quantité de contenu sur le réseau.
Cela signifie également qu’il faudrait plus de 20 pages vues pour bénéficier de leur mise en cache.

À emporter : Examinez les possibilités d’utiliser des SVG au lieu de PNG.

À emporter : Assurez-vous d’optimiser les images SVG, utilisez l’outil gratuit auquel j’ai fait référence.

À emporter : L’alignement de petites images peut avoir du sens et apporter des gains de performance hors normes.

Note : Vous pouvez également inligner des PNG – voir ce guide.

Note : Pour des images PNG/JPG optimisées, essayez Kraken.

Reculez, JavaScript ! HTML peut gérer cela…

De nos jours, grâce à la prédominance des bibliothèques JavaScript qui offrent une solution prête à l’emploi, je constate souvent que JavaScript est utilisé pour des fonctionnalités qui pourraient être réalisées sans lui. Plus de bibliothèques JS signifie plus de téléchargements, peut-être plus d’allers-retours pour des fichiers supplémentaires depuis le serveur, et ensuite le temps et les coûts d’exécution de JavaScript eux-mêmes.

J’ai beaucoup de sympathie pour la façon dont vous êtes arrivé à ce point. Les développeurs reçoivent souvent des briefs/specs médiocres qui ne précisent rien sur les performances, seulement sur la fonction. Ils manquent souvent de temps et il est donc facile de se contenter d’ajouter quelque chose.

Cependant, beaucoup de progrès ont été réalisés en termes de fonctionnalités qui peuvent être obtenues avec HTML et/ou CSS. Voyons quelques exemples.

Boîte combinée avec recherche

Les menus déroulants avec option de recherche textuelle sont un élément d’interface assez courant de nos jours. Un article récent que j’ai trouvé décrit comment utiliser la bibliothèque Javascript Select2 pour faire une telle liste :

C’est un élément d’interface utile, qui peut aider vos utilisateurs. Cependant, la bibliothèque Select2 contient une bibliothèque JavaScript, qui repose elle-même sur des CSS et la bibliothèque JQuery. Cela signifie trois allers-retours pour collecter un tas de fichiers de tailles différentes :

JQuery – 101kb
Sélectionnez2 JavaScript – 24kb
Select2 CSS – 3kb

Ce n’est pas idéal pour la vitesse du site, mais nous pourrions certainement faire valoir qu’il vaut la peine d’avoir une interface simplifiée pour les utilisateurs.

Cependant, il est en fait possible de sortir cette fonctionnalité de la boîte avec l’élément de liste de données HTML :

Cela permet à l’utilisateur de faire des recherches dans la liste ou de taper librement sa propre réponse, ce qui offre la même fonctionnalité. De plus, il dispose d’une interface native sur les smartphones !

Vous pouvez le voir en action dans ce codepen.

Détails/Résumé

LonelyPlanet a un beau site web, et je regardais cette page sur l’Espagne, qui a un lien « Lire la suite » que la plupart des internautes connaissent :

Comme pour presque toutes les implémentations que je vois, ils ont utilisé une bibliothèque JavaScript pour mettre en œuvre ce lien, et une fois de plus, cela s’accompagne d’un tas de frais généraux.

Cependant, le HTML possède une paire de balises intégrées appelées détails et résumé, qui sont conçues pour mettre en œuvre cette fonctionnalité avec précision. Gratuit et nativement en HTML. Pas de surcharge, et plus accessible pour les utilisateurs qui ont besoin d’un lecteur d’écran, tout en transmettant un sens sémantique à Google.

Ces balises peuvent être stylisées de diverses manières flexibles avec le CSS et recréent la plupart des versions JS que j’ai vues sur le marché.

Regardez une simple démo ici : https://codepen.io/TomAnthony/pen/GRRLrmm

…et plus encore

Pour d’autres exemples de fonctionnalités que vous pouvez réaliser avec du HTML au lieu de JS, consultez ces liens :

http://youmightnotneedjs.com/
https://dev.to/ananyaneogi/html-can-do-that-c0n

A emporter : Examinez la fonctionnalité de vos sites et voyez où il est possible de réduire votre dépendance à l’égard de grandes bibliothèques Javascript où il existe des options HTML/CSS natives.

À emporter : N’oubliez pas que ce n’est pas seulement la taille des fichiers JS qui pose problème, mais aussi le nombre d’allers-retours nécessaires.

Note : Il y a des cas où vous devriez utiliser la solution JS, mais il est important de peser le pour et le contre.

Mise au point du réseau

Chaque fois que le navigateur doit collecter des ressources sur un serveur, il doit envoyer un message sur Internet et inversement ; la vitesse de ce message est limitée par la vitesse de la lumière. Cela peut sembler ridicule, mais cela signifie que même les petites requêtes ajoutent du temps au chargement de la page. Si vous n’avez pas compris le lien ci-dessus, mon billet expliquant le HTTP2 aborde cette question plus en détail.

Il y a certaines choses que nous pouvons faire pour aider à réduire la distance de ces demandes ou pour réduire le nombre de trajets aller-retour nécessaires. Ces mesures sont un peu plus techniques, mais peuvent permettre de réaliser de véritables gains.

TLS 1.3

TLS (ou SSL) est la technologie de cryptage utilisée pour sécuriser les connexions HTTPS. Historiquement, il fallait deux allers-retours entre le navigateur et le serveur pour mettre en place ce cryptage – si l’utilisateur se trouve à 50 ms du serveur, cela signifie 200 ms par connexion. Gardez à l’esprit que Google recommande traditionnellement de viser les 200 ms pour fournir le HTML (cela semble un peu plus souple dans les mises à jour plus récentes) ; vous perdez beaucoup de ce temps ici.

La norme TLS 1.3 récemment définie réduit ce délai de deux allers-retours à un seul, ce qui peut faire gagner un temps précieux à l’utilisateur lors de sa connexion initiale à votre site web.

Parlez à votre équipe technique de la migration vers TLS 1.3 ; les navigateurs qui ne la prennent pas en charge se replieront sur TLS 1.2 sans problème. Tout cela se passe en coulisses et ne constitue pas une migration de quelque nature que ce soit. Il n’y a aucune raison de ne pas le faire.

Si vous utilisez un CDN, il suffit simplement de l’activer.

Vous pouvez utiliser cet outil pour vérifier quelles versions de TLS vous avez activées.

QUIC / HTTP 3

Au cours des 2 ou 3 dernières années, nous avons vu un certain nombre de sites passer de HTTP 1.1 à HTTP 2, ce qui constitue une mise à niveau en coulisse qui peut apporter une réelle amélioration de la vitesse (voir mon lien ci-dessus si vous voulez en savoir plus).

Dans le même temps, il existe une paire de normes émergentes connue sous le nom de QUIC + HTTP/3, qui optimisent encore la connexion entre le navigateur et le serveur, réduisant encore les allers-retours nécessaires.

La prise en charge de ces normes commence à peine à être viable, mais si vous êtes un client CloudFlare, vous pouvez l’activer dès aujourd’hui et au cours des six prochains mois, à mesure que Chrome et Firefox mettront en place une prise en charge, vos utilisateurs bénéficieront d’un gain de vitesse.

Pour en savoir plus : https://blog.cloudflare.com/http3-the-past-present-and-future/

Super routage

Lorsque les utilisateurs se connectent à votre site web, ils doivent ouvrir des connexions réseau de n’importe où vers vos serveurs (ou votre CDN). Si vous imaginez l’internet comme une série de routes, vous pouvez imaginer qu’ils doivent « conduire » jusqu’à votre serveur en empruntant ces routes. Cependant, cela signifie des embouteillages et des bouchons.

Il s’avère que certaines des grandes sociétés de cloud computing ont leurs propres routes privées qui ont moins de nids de poule, moins de trafic et des limitations de vitesse améliorées. Si seulement les visiteurs de votre site web pouvaient avoir accès à ces routes, ils pourraient vous rejoindre plus rapidement !

Et bien, devinez quoi ? Ils le peuvent !

Pour CloudFlare, ils fournissent cet accès via leur produit Argo, alors que si vous êtes sur AWS, vous pouvez utiliser leur Global Accelerator. Cela permet aux demandes adressées à votre site web d’utiliser leurs réseaux privés et de bénéficier d’un gain de vitesse potentiel. Ces deux solutions sont très bon marché si vous êtes déjà client.

À emporter : Beaucoup de ces avantages sont beaucoup plus faciles à obtenir si vous utilisez un CDN. Si vous n’utilisez pas encore de CDN, vous devriez probablement le faire. CloudFlare est un excellent choix, tout comme CloudFront si vous utilisez un AWS. Fastly est le plus configurable d’entre eux si vous êtes plutôt un pro.

À emporter : TLS 1.3 est maintenant très largement pris en charge et offre une amélioration significative de la vitesse pour les nouvelles connexions.

À emporter : QUIC / HTTP3 commencent à peine à être pris en charge, mais au cours des prochains mois, cette solution sera déployée plus largement. QUIC inclut les avantages de TLS 1.3 ainsi que d’autres avantages. Une connexion HTTP2 typique nécessite aujourd’hui 3 allers-retours pour être ouverte ; QUIC n’en a besoin que d’un seul !

À emporter : Si vous êtes sur CloudFlare ou AWS, il est possible d’obtenir des accélérations simplement en basculant un interrupteur pour activer les fonctions de routage intelligent.

Laissez le CSS en faire plus

J’ai parlé plus haut des fonctionnalités intégrées du HTML que vous pouvez exploiter pour éviter de vous fier à des solutions « maison » qui nécessitent plus de code (et de traitement du côté des navigateurs) pour être mises en œuvre. Je vais vous donner quelques exemples de cas où le CSS peut faire la même chose pour vous.

Réutiliser les images

Souvent, on trouve des pages qui utilisent des images similaires à plusieurs endroits de la page. Par exemple, des variations d’un logo de différentes couleurs ou des flèches qui pointent dans les deux sens. En tant qu’éléments uniques (aussi similaires soient-ils), chacun d’entre eux doit être téléchargé séparément.

En revenant à ma chasse aux billets de cinéma ci-dessus, où je regardais cette page, on peut voir un carrousel qui a des flèches gauche et droite :

Comme dans la logique utilisée ci-dessus, bien que ces fichiers d’images soient petits, il faut quand même faire un aller-retour pour les récupérer sur le serveur.

Cependant, les flèches sont identiques – elles pointent simplement dans des directions opposées ! Il est facile pour nous d’utiliser la fonction de transformation du CSS pour utiliser une image dans les deux sens :

Vous pouvez consulter ce codepen pour un exemple.

Un autre exemple est lorsque le même logo apparaît dans des styles différents sur différentes parties de la page ; souvent, ils chargeront de multiples variations, ce qui n’est pas nécessaire. Le CSS peut recolorer les logos pour vous de différentes manières :

Vous trouverez ici un codepen montrant cette technique en action. Si vous voulez calculer la valeur du filtre CSS nécessaire pour obtenir une couleur arbitraire, alors jetez un coup d’œil à cet étonnant calculateur de couleurs.

Interactions (par exemple, menus et onglets)

Souvent, les éléments de navigation tels que les menus et les onglets sont implémentés en JavaScript, mais ceux-ci peuvent également être réalisés en CSS pur. Consultez ce codepen pour un exemple :

Animations

Le CSS3 a introduit de puissantes capacités d’animation dans le CSS. Souvent, celles-ci sont non seulement plus rapides que les versions JavaScript, mais peuvent également être plus fluides car elles peuvent s’exécuter dans le code natif du système d’exploitation plutôt que de devoir exécuter un Javascript relativement plus lent.

Consultez l’exemple de Dozing Bird :

Vous en trouverez bien d’autres dans cet article. Les animations CSS peuvent ajouter beaucoup de caractère aux pages pour un coût de performance relativement faible.

…et plus encore

Pour d’autres exemples de fonctionnalités que vous pouvez réaliser à l’aide de solutions CSS pures, jetez un coup d’œil :

http://youmightnotneedjs.com/
https://dev.to/ananyaneogi/css-can-do-that-18g7m

A emporter : Utilisez le CSS pour optimiser le nombre de fichiers que vous devez charger en utilisant des rotations ou des filtres.

À emporter : Les animations CSS peuvent ajouter du caractère aux pages, et nécessitent souvent moins de ressources que le JavaScript.

À emporter : Le CSS est parfaitement capable de mettre en œuvre de nombreux éléments interactifs de l’interface utilisateur.

Conclusion

J’espère que vous avez trouvé ces exemples utiles en eux-mêmes, mais je tiens à souligner que nous devrions tous essayer de penser un peu plus différemment en ce qui concerne la vitesse du site. Il est particulièrement important de réduire le nombre d’allers-retours au serveur ; même les petits actifs prennent un certain temps à aller chercher et peuvent avoir un impact appréciable sur les performances (surtout mobiles).

Il y a beaucoup plus d’idées que celles que nous avons couvertes ici, alors n’hésitez pas à sauter dans les commentaires si vous avez d’autres choses que vous avez rencontrées.

À propos de Tom-Anthony –

Tom est vice-président des produits chez Distilled, il passe son temps à étudier les tendances technologiques et à diriger l’équipe chargée de la mise en place de la plate-forme de test de la division SEO de DistilledODN. Suivez le sur Twitter : @TomAnthonySEO.

42
41