Performances frontales 2021 : optimisations des actifs

Ce guide a été aimablement soutenu par nos amis de LogRocket, un service qui combine la surveillance des performances frontales, la relecture de session et l'analyse des produits pour vous aider à créer de meilleures expériences client. LogRocket suit les mesures clés, y compris. DOM complet, temps jusqu'au premier octet, premier délai d'entrée, CPU client et utilisation de la mémoire. Obtenez un essai gratuit de LogRocket dès aujourd'hui.

Table des matières

1. Se préparer : planification et métriques
2. Fixer des objectifs réalistes
3. Définir l'environnement
4. Optimisations des actifs
5. Construire des optimisations
6. Optimisations de livraison
7. Mise en réseau, HTTP/2, HTTP/3
8. Test et surveillance
9. Victoires rapides
10. Tout sur une seule page
11. Télécharger la liste de contrôle (PDF, pages Apple, MS Word)
12. Abonnez-vous à notre newsletter par e-mail pour ne pas manquer les prochains guides.

Optimisations des actifs

1. Utilisez Brotli pour la compression de texte brut.
   En 2015, Google a introduit Brotli, un nouveau format de données open source sans perte, désormais pris en charge par tous les navigateurs modernes. La bibliothèque Brotli open source, qui implémente un encodeur et un décodeur pour Brotli, a 11 niveaux de qualité prédéfinis pour l'encodeur, avec un niveau de qualité supérieur exigeant plus de CPU en échange d'un meilleur taux de compression. Une compression plus lente conduira finalement à des taux de compression plus élevés, mais Brotli décompresse rapidement. Il convient de noter cependant que Brotli avec le niveau de compression 4 est à la fois plus petit et se comprime plus rapidement que Gzip.

   En pratique, Brotli semble être beaucoup plus efficace que Gzip. Les opinions et les expériences diffèrent, mais si votre site est déjà optimisé avec Gzip, vous pouvez vous attendre à des améliorations au moins à un chiffre et au mieux à deux chiffres en matière de réduction de taille et de délais FCP. Vous pouvez également estimer les économies de compression Brotli pour votre site.

   Les navigateurs n'accepteront Brotli que si l'utilisateur visite un site Web via HTTPS. Brotli est largement pris en charge et de nombreux CDN le prennent en charge (Akamai, Netlify Edge, AWS, KeyCDN, Fastly (actuellement uniquement en tant que pass-through), Cloudflare, CDN77) et vous pouvez activer Brotli même sur les CDN qui ne le prennent pas encore en charge. (avec un agent de service).

   Le hic, c'est que la compression de tous les actifs avec Brotli à un niveau de compression élevé coûte cher, de nombreux fournisseurs d'hébergement ne peuvent pas l'utiliser à pleine échelle simplement à cause des frais généraux énormes qu'il génère. En fait, au niveau de compression le plus élevé, Brotli est si lent que tout gain potentiel de taille de fichier pourrait être annulé par le temps nécessaire au serveur pour commencer à envoyer la réponse en attendant de compresser dynamiquement l'actif. (Mais si vous avez le temps pendant le temps de construction avec la compression statique, bien sûr, des paramètres de compression plus élevés sont préférés.)

   

   Cela pourrait changer cependant. Le format de fichier Brotli comprend un dictionnaire statique intégré et, en plus de contenir diverses chaînes dans plusieurs langues, il prend également en charge la possibilité d'appliquer plusieurs transformations à ces mots, ce qui augmente sa polyvalence. Dans ses recherches, Felix Hanau a découvert un moyen d'améliorer la compression aux niveaux 5 à 9 en utilisant "un sous-ensemble plus spécialisé du dictionnaire que celui par défaut" et en s'appuyant sur l'en-tête Content-Type pour dire au compresseur s'il doit utiliser un dictionnaire pour HTML, JavaScript ou CSS. Le résultat a été un "impact négligeable sur les performances (1% à 3% de CPU en plus contre 12% normalement) lors de la compression de contenu Web à des niveaux de compression élevés, en utilisant une approche d'utilisation limitée du dictionnaire".

   

   De plus, grâce aux recherches d'Elena Kirilenko, nous pouvons obtenir une recompression Brotli rapide et efficace en utilisant les artefacts de compression précédents. Selon Elena, "une fois que nous avons un actif compressé via Brotli, et que nous essayons de compresser le contenu dynamique à la volée, où le contenu ressemble au contenu disponible à l'avance, nous pouvons obtenir des améliorations significatives des temps de compression. "

   Combien de fois est-ce le cas? Par exemple, avec la livraison de sous- ensembles de bundles JavaScript (par exemple, lorsque des parties du code sont déjà mises en cache sur le client ou avec un bundle dynamique servant avec WebBundles). Ou avec du HTML dynamique basé sur des modèles connus à l'avance ou des polices WOFF2 dynamiquement sous-ensembles . Selon Elena, nous pouvons obtenir une amélioration de 5,3 % de la compression et de 39 % de la vitesse de compression en supprimant 10 % du contenu, et des taux de compression 3,2 % meilleurs et une compression 26 % plus rapide en supprimant 50 % du contenu.

   La compression Brotli s'améliore, donc si vous pouvez contourner le coût de la compression dynamique des actifs statiques, cela en vaut vraiment la peine. Il va sans dire que Brotli peut être utilisé pour n'importe quelle charge utile en texte brut - HTML, CSS, SVG, JavaScript, JSON, etc.

   Remarque : début 2021, environ 60 % des réponses HTTP sont livrées sans compression textuelle, dont 30,82 % avec Gzip et 9,1 % avec Brotli (à la fois sur mobile et sur ordinateur). Par exemple, 23,4% des pages Angular ne sont pas compressées (via gzip ou Brotli). Pourtant, l'activation de la compression est souvent l'une des victoires les plus faciles pour améliorer les performances en appuyant simplement sur un interrupteur.

   La stratégie? Pré-compressez les ressources statiques avec Brotli+Gzip au niveau le plus élevé et compressez le HTML (dynamique) à la volée avec Brotli au niveau 4-6. Assurez-vous que le serveur gère correctement la négociation de contenu pour Brotli ou Gzip.

1. Utilisons-nous le chargement multimédia adaptatif et les conseils client ?
   Cela vient du pays des vieilles nouvelles, mais c'est toujours un bon rappel d'utiliser des images réactives avec srcset , sizes et l'élément <picture> . En particulier pour les sites à forte empreinte multimédia, nous pouvons aller plus loin avec le chargement multimédia adaptatif (dans cet exemple, React + Next.js), offrant une expérience légère aux réseaux lents et aux appareils à faible mémoire et une expérience complète au réseau rapide et haute -dispositifs de mémoire. Dans le contexte de React, nous pouvons y parvenir avec des conseils client sur le serveur et des crochets réactifs adaptatifs sur le client.

   L'avenir des images réactives pourrait changer radicalement avec l'adoption plus large des conseils aux clients. Les indications client sont des champs d'en-tête de requête HTTP, par exemple DPR , Viewport-Width , Width , Save-Data , Accept (pour spécifier les préférences de format d'image) et autres. Ils sont censés informer le serveur des spécificités du navigateur, de l'écran, de la connexion, etc. de l'utilisateur.

   En conséquence, le serveur peut décider comment remplir la mise en page avec des images de taille appropriée et ne servir que ces images dans les formats souhaités. Avec les conseils client, nous déplaçons la sélection des ressources du balisage HTML vers la négociation requête-réponse entre le client et le serveur.

   

   Comme Ilya Grigorik l'a noté il y a quelque temps, les conseils du client complètent le tableau - ils ne sont pas une alternative aux images réactives. "L'élément <picture> fournit le contrôle de direction artistique nécessaire dans le balisage HTML. Les conseils du client fournissent des annotations sur les demandes d'image résultantes qui permettent l'automatisation de la sélection des ressources. Service Worker fournit des fonctionnalités complètes de gestion des demandes et des réponses sur le client."

   Un travailleur de service pourrait, par exemple, ajouter de nouvelles valeurs d'en-têtes d'indications client à la demande, réécrire l'URL et faire pointer la demande d'image vers un CDN, adapter la réponse en fonction de la connectivité et des préférences de l'utilisateur, etc. pour presque toutes les autres demandes également.

   Pour les clients qui prennent en charge les conseils client, on peut mesurer 42 % d'économies d'octets sur les images et 1 Mo+ d'octets en moins pour le 70e centile+. Sur Smashing Magazine, nous avons également pu mesurer une amélioration de 19 à 32 %. Les conseils client sont pris en charge dans les navigateurs basés sur Chromium, mais ils sont toujours à l'étude dans Firefox.

   Toutefois, si vous fournissez à la fois le balisage des images réactives normales et la <meta> pour les conseils client, un navigateur prenant en charge évaluera le balisage des images réactives et demandera la source d'image appropriée à l'aide des en-têtes HTTP Client Hints.

2. Utilisons-nous des images réactives pour les images d'arrière-plan ?
   Nous devrions sûrement ! Avec image-set , désormais pris en charge dans Safari 14 et dans la plupart des navigateurs modernes à l'exception de Firefox, nous pouvons également proposer des images d'arrière-plan réactives :

   background-image: url("fallback.jpg"); background-image: image-set( "photo-small.jpg" 1x, "photo-large.jpg" 2x, "photo-print.jpg" 600dpi);

   Fondamentalement, nous pouvons conditionnellement servir des images d'arrière-plan basse résolution avec un descripteur 1x , et des images haute résolution avec un descripteur 2x , et même une image de qualité d'impression avec un descripteur 600dpi . Attention cependant : les navigateurs ne fournissent aucune information spéciale sur les images d'arrière-plan aux technologies d'assistance, donc idéalement, ces photos ne seraient qu'une décoration.

3. Utilisons-nous WebP ?
   La compression d'image est souvent considérée comme un gain rapide, mais elle est encore largement sous-utilisée dans la pratique. Bien sûr, les images ne bloquent pas le rendu, mais elles contribuent fortement aux mauvais scores LCP, et très souvent, elles sont tout simplement trop lourdes et trop volumineuses pour l'appareil sur lequel elles sont consommées.

   Donc, à tout le moins, nous pourrions explorer l'utilisation du format WebP pour nos images. En fait, la saga WebP touche à sa fin l'année dernière avec Apple ajoutant la prise en charge de WebP dans Safari 14. Ainsi, après de nombreuses années de discussions et de débats, à partir d'aujourd'hui, WebP est pris en charge dans tous les navigateurs modernes. Nous pouvons donc servir des images WebP avec l'élément <picture> et un repli JPEG si nécessaire (voir l'extrait de code d'Andreas Bovens) ou en utilisant la négociation de contenu (en utilisant les en-têtes Accept ).

   WebP n'est cependant pas sans inconvénients . Bien que la taille des fichiers d'image WebP soit comparée à Guetzli et Zopfli équivalents, le format ne prend pas en charge le rendu progressif comme JPEG, c'est pourquoi les utilisateurs peuvent voir l'image finale plus rapidement avec un bon vieux JPEG, bien que les images WebP puissent devenir plus rapides via le réseau. Avec JPEG, nous pouvons servir une expérience utilisateur "décente" avec la moitié ou même le quart des données et charger le reste plus tard, plutôt que d'avoir une image à moitié vide comme c'est le cas avec WebP.

   Votre décision dépendra de ce que vous recherchez : avec WebP, vous réduirez la charge utile, et avec JPEG, vous améliorerez les performances perçues. Vous pouvez en savoir plus sur WebP dans la conférence WebP Rewind de Pascal Massimino de Google.

   Pour la conversion en WebP, vous pouvez utiliser WebP Converter, cwebp ou libwebp. Ire Aderinokun propose également un didacticiel très détaillé sur la conversion d'images en WebP, tout comme Josh Comeau dans son article sur l'adoption des formats d'image modernes.

   

   Sketch prend nativement en charge WebP et les images WebP peuvent être exportées depuis Photoshop à l'aide d'un plug-in WebP pour Photoshop. Mais d'autres options sont également disponibles.

   Si vous utilisez WordPress ou Joomla, il existe des extensions pour vous aider à implémenter facilement la prise en charge de WebP, comme Optimus et Cache Enabler pour WordPress et la propre extension prise en charge par Joomla (via Cody Arsenault). Vous pouvez également faire abstraction de l'élément <picture> avec React, des composants stylés ou gatsby-image.

   Ah - prise éhontée ! - Jeremy Wagner a même publié un livre Smashing sur WebP que vous voudrez peut-être consulter si vous êtes intéressé par tout ce qui concerne WebP.

4. Utilisons-nous AVIF ?
   Vous avez peut-être entendu la grande nouvelle : AVIF est arrivé. C'est un nouveau format d'image dérivé des images clés de la vidéo AV1. Il s'agit d'un format ouvert et libre de droits qui prend en charge la compression avec et sans perte, l'animation, le canal alpha avec perte et peut gérer des lignes nettes et des couleurs unies (ce qui était un problème avec JPEG), tout en offrant de meilleurs résultats dans les deux cas.

   En fait, par rapport à WebP et JPEG, AVIF est nettement plus performant , permettant d'économiser jusqu'à 50 % de la taille médiane des fichiers pour le même DSSIM ((dis)similarité entre deux images ou plus à l'aide d'un algorithme se rapprochant de la vision humaine). En fait, dans son article approfondi sur l'optimisation du chargement des images, Malte Ubl note qu'AVIF "surclasse très régulièrement JPEG de manière très significative. Ceci est différent de WebP qui ne produit pas toujours des images plus petites que JPEG et peut en fait être un net- perte due au manque de support pour le chargement progressif."

   

   Ironiquement, AVIF peut être encore plus performant que les grands SVG, même s'il ne doit bien sûr pas être considéré comme un substitut aux SVG. C'est également l'un des premiers formats d'image à prendre en charge la prise en charge des couleurs HDR ; offrant une luminosité, une profondeur de couleur et des gammes de couleurs plus élevées. Le seul inconvénient est qu'actuellement, AVIF ne prend pas en charge le décodage progressif des images (encore ?) et, comme Brotli, un encodage à taux de compression élevé est actuellement assez lent, bien que le décodage soit rapide.

   AVIF est actuellement pris en charge dans Chrome, Firefox et Opera, et le support dans Safari devrait arriver bientôt (car Apple est membre du groupe qui a créé AV1).

   Quelle est la meilleure façon de diffuser des images de nos jours ? Pour les illustrations et les images vectorielles, le SVG (compressé) est sans aucun doute le meilleur choix. Pour les photos, nous utilisons des méthodes de négociation de contenu avec l'élément picture . Si AVIF est pris en charge, nous envoyons une image AVIF ; si ce n'est pas le cas, nous revenons d'abord à WebP, et si WebP n'est pas pris en charge non plus, nous passons à JPEG ou PNG comme solution de secours (en appliquant les conditions @media si nécessaire) :

   <picture> <source type="image/avif"> <source type="image/webp"> <img src="image.jpg" alt="Photo" width="450" height="350"> </picture>

   Franchement, il est plus probable que nous utilisions certaines conditions dans l'élément picture :

   <picture> <source type="image/avif" /> <source type="image/webp" /> <source type="image/jpeg" /> <img src="fallback-image.jpg" alt="Photo" width="450" height="350"> </picture>
   <picture> <source type="image/avif" /> <source type="image/webp" /> <source type="image/jpeg" /> <img src="fallback-image.jpg" alt="Photo" width="450" height="350"> </picture>

   Vous pouvez aller encore plus loin en échangeant des images animées avec des images statiques pour les clients qui optent pour moins de mouvement avec prefers-reduced-motion :

   <picture> <source media="(prefers-reduced-motion: reduce)" type="image/avif"></source> <source media="(prefers-reduced-motion: reduce)" type="image/jpeg"></source> <source type="image/avif"></source> <img src="motion.jpg" alt="Animated AVIF"> </picture>
   <picture> <source media="(prefers-reduced-motion: reduce)" type="image/avif"></source> <source media="(prefers-reduced-motion: reduce)" type="image/jpeg"></source> <source type="image/avif"></source> <img src="motion.jpg" alt="Animated AVIF"> </picture>

   Au cours des quelques mois, AVIF a gagné en popularité :

   • Nous pouvons tester les solutions de repli WebP/AVIF dans le panneau Rendu de DevTools.
   • Nous pouvons utiliser Squoosh, AVIF.io et libavif pour encoder, décoder, compresser et convertir des fichiers AVIF.
   • Nous pouvons utiliser le composant AVIF Preact de Jake Archibald qui décode un fichier AVIF dans un worker et affiche le résultat sur un canevas,
   • Pour fournir AVIF uniquement aux navigateurs compatibles, nous pouvons utiliser un plugin PostCSS avec un script 315B pour utiliser AVIF dans vos déclarations CSS.
   • Nous pouvons progressivement fournir de nouveaux formats d'image avec CSS et Cloudlare Workers pour modifier dynamiquement le document HTML renvoyé, en déduisant les informations de l'en-tête d' accept , puis ajouter les webp/avif , etc., le cas échéant.
   • AVIF est déjà disponible dans Cloudinary (avec des limites d'utilisation), Cloudflare prend en charge AVIF dans le redimensionnement d'image et vous pouvez activer AVIF avec des en-têtes AVIF personnalisés dans Netlify.
   • En ce qui concerne l'animation, AVIF fonctionne aussi bien que <img src=mp4> de Safari, surpassant GIF et WebP dans son ensemble, mais MP4 fonctionne toujours mieux.
   • En général, pour les animations, AVC1 (h264) > HVC1 > WebP > AVIF > GIF, en supposant que les navigateurs basés sur Chromium prendront toujours en charge <img src=mp4> .
   • Vous pouvez trouver plus de détails sur AVIF dans AVIF for Next Generation Image Coding talk par Aditya Mavlankar de Netflix, et The AVIF Image Format talk par Kornel Lesinski de Cloudflare.
   • Une excellente référence pour tout AVIF : le post complet de Jake Archibald sur AVIF est arrivé.

   Alors, le futur AVIF, alors ? Jon Sneyers n'est pas d'accord : AVIF est 60 % moins performant que JPEG XL, un autre format libre et ouvert développé par Google et Cloudinary. En fait, JPEG XL semble bien mieux fonctionner dans tous les domaines. Cependant, JPEG XL n'est encore qu'au stade final de la normalisation et ne fonctionne pas encore dans aucun navigateur. (À ne pas confondre avec le JPEG-XR de Microsoft provenant du bon vieux Internet Explorer 9 fois).

1. Les JPEG/PNG/SVG sont-ils correctement optimisés ?
   Lorsque vous travaillez sur une page de destination sur laquelle il est essentiel qu'une image de héros se charge à une vitesse fulgurante, assurez-vous que les fichiers JPEG sont progressifs et compressés avec mozJPEG (qui améliore le temps de rendu de démarrage en manipulant les niveaux de numérisation) ou Guetzli, l'open-source de Google encodeur se concentrant sur les performances perceptuelles et utilisant les enseignements de Zopfli et WebP. Seul bémol : des temps de traitement lents (une minute de CPU par mégapixel).

   Pour PNG, nous pouvons utiliser Pingo, et pour SVG, nous pouvons utiliser SVGO ou SVGOMG. Et si vous avez besoin de prévisualiser et de copier ou de télécharger rapidement tous les éléments SVG d'un site Web, svg-grabber peut également le faire pour vous.

   Chaque article d'optimisation d'image l'indiquerait, mais garder les actifs vectoriels propres et serrés vaut toujours la peine d'être mentionné. Assurez-vous de nettoyer les ressources inutilisées, de supprimer les métadonnées inutiles et de réduire le nombre de points de chemin dans l'illustration (et donc le code SVG). ( Merci, Jérémie ! )

   Il existe également des outils en ligne utiles :

   • Utilisez Squoosh pour compresser, redimensionner et manipuler les images aux niveaux de compression optimaux (avec ou sans perte),
   • Utilisez Guetzli.it pour compresser et optimiser les images JPEG avec Guetzli, qui fonctionne bien pour les images avec des bords nets et des couleurs unies (mais peut être un peu plus lent)).
   • Utilisez le Responsive Image Breakpoints Generator ou un service tel que Cloudinary ou Imgix pour automatiser l'optimisation des images. De plus, dans de nombreux cas, l'utilisation srcset et de sizes seules apportera des avantages significatifs.
   • Pour vérifier l'efficacité de votre balisage réactif, vous pouvez utiliser Imaging-heap, un outil de ligne de commande qui mesure l'efficacité des tailles de fenêtres et des ratios de pixels de l'appareil.
   • Vous pouvez ajouter une compression d'image automatique à vos flux de travail GitHub, afin qu'aucune image ne puisse atteindre la production sans être compressée. L'action utilise mozjpeg et libvips qui fonctionnent avec les PNG et les JPG.
   • Pour optimiser le stockage en interne, vous pouvez utiliser le nouveau format Lepton de Dropbox pour compresser sans perte les fichiers JPEG de 22 % en moyenne.
   • Utilisez BlurHash si vous souhaitez afficher une image d'espace réservé plus tôt. BlurHash prend une image et vous donne une courte chaîne (seulement 20-30 caractères !) qui représente l'espace réservé pour cette image. La chaîne est suffisamment courte pour pouvoir être facilement ajoutée en tant que champ dans un objet JSON.

   

   Parfois, l'optimisation des images seule ne suffira pas. Pour améliorer le temps nécessaire pour démarrer le rendu d'une image critique, chargez paresseusement les images moins importantes et différez le chargement des scripts une fois que les images critiques ont déjà été rendues. Le moyen le plus à l'épreuve des balles est le chargement paresseux hybride, lorsque nous utilisons le chargement paresseux natif et le chargement paresseux, une bibliothèque qui détecte tout changement de visibilité déclenché par l'interaction de l'utilisateur (avec IntersectionObserver que nous explorerons plus tard). Aditionellement:

   • Envisagez de précharger les images critiques, afin qu'un navigateur ne les découvre pas trop tard. Pour les images d'arrière-plan, si vous voulez être encore plus agressif que cela, vous pouvez ajouter l'image en tant qu'image normale avec <img src> , puis la masquer hors de l'écran.
   • Envisagez d'échanger des images avec l'attribut Sizes en spécifiant différentes dimensions d'affichage d'image en fonction des requêtes multimédias, par exemple pour manipuler les sizes pour échanger les sources dans un composant de loupe.
   • Examinez les incohérences de téléchargement d'images pour éviter les téléchargements inattendus d'images de premier plan et d'arrière-plan. Méfiez-vous des images chargées par défaut, mais susceptibles de ne jamais être affichées, par exemple dans les carrousels, les accordéons et les galeries d'images.
   • Assurez-vous de toujours définir la width et la height des images. Faites attention à la propriété aspect-ratio dans CSS et à l'attribut intrinsicsize qui nous permettra de définir les proportions et les dimensions des images, afin que le navigateur puisse réserver tôt un emplacement de mise en page prédéfini pour éviter les sauts de mise en page lors du chargement de la page.

   

   Si vous vous sentez aventureux, vous pouvez couper et réorganiser les flux HTTP/2 à l'aide des travailleurs Edge, essentiellement un filtre en temps réel vivant sur le CDN, pour envoyer des images plus rapidement via le réseau. Les travailleurs Edge utilisent des flux JavaScript qui utilisent des blocs que vous pouvez contrôler (essentiellement, il s'agit de JavaScript qui s'exécute sur la périphérie CDN qui peut modifier les réponses en streaming), afin que vous puissiez contrôler la livraison des images.

   Avec un travailleur de service, il est trop tard car vous ne pouvez pas contrôler ce qui se passe sur le fil, mais cela fonctionne avec les travailleurs Edge. Vous pouvez donc les utiliser en plus des fichiers JPEG statiques enregistrés progressivement pour une page de destination particulière.

   

   Pas assez bon? Eh bien, vous pouvez également améliorer les performances perçues pour les images avec la technique des images d'arrière-plan multiples. Gardez à l'esprit que jouer avec le contraste et brouiller les détails inutiles (ou supprimer les couleurs) peut également réduire la taille du fichier. Ah, vous avez besoin d' agrandir une petite photo sans perdre en qualité ? Pensez à utiliser Letsenhance.io.

   

   Jusqu'à présent, ces optimisations ne couvrent que les bases. Addy Osmani a publié un guide très détaillé sur Essential Image Optimization qui va très loin dans les détails de la compression d'image et de la gestion des couleurs. Par exemple, vous pouvez flouter des parties inutiles de l'image (en leur appliquant un filtre de flou gaussien) pour réduire la taille du fichier, et éventuellement vous pouvez même commencer à supprimer des couleurs ou transformer l'image en noir et blanc pour réduire encore plus la taille. . Pour les images d'arrière-plan, l'exportation de photos depuis Photoshop avec une qualité de 0 à 10 % peut également être tout à fait acceptable.

   Sur Smashing Magazine, nous utilisons le suffixe -opt pour les noms d'images — par exemple, brotli-compression-opt.png ; chaque fois qu'une image contient ce suffixe, tout le monde dans l'équipe sait que l'image a déjà été optimisée.

   Ah, et n'utilisez pas JPEG-XR sur le Web - "le traitement du décodage côté logiciel des JPEG-XR sur le processeur annule et même compense l'impact potentiellement positif des économies de taille d'octet, en particulier dans le contexte des SPA" (pas à confondre avec le JPEG XL de Cloudinary/Google).

1. Les vidéos sont-elles correctement optimisées ?
   Nous avons couvert les images jusqu'à présent, mais nous avons évité une conversation sur les bons vieux GIF. Malgré notre amour pour les GIF, c'est vraiment le moment de les abandonner pour de bon (au moins dans nos sites Web et nos applications). Au lieu de charger des GIF animés lourds qui ont un impact à la fois sur les performances de rendu et sur la bande passante, c'est une bonne idée de passer soit au WebP animé (le GIF étant une solution de repli), soit de les remplacer par des vidéos HTML5 en boucle.

   Contrairement aux images, les navigateurs ne préchargent pas le contenu <video> , mais les vidéos HTML5 ont tendance à être beaucoup plus légères et plus petites que les GIF. Pas une option? Eh bien, au moins, nous pouvons ajouter une compression avec perte aux GIF avec Lossy GIF, gifsicle ou giflossy.

   Les tests de Colin Bendell montrent que les vidéos intégrées dans les balises img de Safari Technology Preview s'affichent au moins 20 fois plus vite et décodent 7 fois plus vite que l'équivalent GIF, en plus d'être une fraction de la taille du fichier. Cependant, il n'est pas pris en charge dans d'autres navigateurs.

   Au pays des bonnes nouvelles, les formats vidéo ont énormément progressé au fil des ans. Pendant longtemps, nous avions espéré que WebM deviendrait le format pour les gouverner tous, et WebP (qui est essentiellement une image fixe à l'intérieur du conteneur vidéo WebM) remplacerait les formats d'image obsolètes. En effet, Safari prend désormais en charge WebP, mais malgré le soutien de WebP et WebM ces jours-ci, la percée ne s'est pas vraiment produite.

   Pourtant, nous pourrions utiliser WebM pour la plupart des navigateurs modernes :

   <!-- By Houssein Djirdeh. https://web.dev/replace-gifs-with-videos/ --> <!-- A common scenartio: MP4 with a WEBM fallback. --> <video autoplay loop muted playsinline> <source src="my-animation.webm" type="video/webm"> <source src="my-animation.mp4" type="video/mp4"> </video>

   Mais peut-être pourrions-nous le revoir complètement. En 2018, l'Alliance of Open Media a publié un nouveau format vidéo prometteur appelé AV1 . AV1 a une compression similaire au codec H.265 (l'évolution de H.264) mais contrairement à ce dernier, AV1 est gratuit. Le prix de la licence H.265 a poussé les fournisseurs de navigateurs à adopter à la place un AV1 aux performances comparables : AV1 (tout comme H.265) se comprime deux fois mieux que WebM .

   

   En fait, Apple utilise actuellement le format HEIF et HEVC (H.265), et toutes les photos et vidéos du dernier iOS sont enregistrées dans ces formats, et non en JPEG. Alors que HEIF et HEVC (H.265) ne sont pas correctement exposés au Web (encore ?), AV1 l'est - et il est de plus en plus pris en charge par les navigateurs. Il est donc raisonnable d'ajouter la source AV1 dans votre <video> , car tous les fournisseurs de navigateurs semblent être de la partie.

   Pour l'instant, l'encodage le plus largement utilisé et pris en charge est H.264, servi par les fichiers MP4, donc avant de servir le fichier, assurez-vous que vos MP4 sont traités avec un encodage multipasse, flouté avec l'effet frei0r iirblur (le cas échéant) et Les métadonnées moov atom sont déplacées vers l'en-tête du fichier, tandis que votre serveur accepte le service d'octets. Boris Schapira fournit des instructions précises à FFmpeg pour optimiser les vidéos au maximum. Bien sûr, fournir le format WebM comme alternative serait également utile.

   Besoin de commencer à rendre les vidéos plus rapidement mais les fichiers vidéo sont encore trop volumineux ? Par exemple, chaque fois que vous avez une grande vidéo d'arrière-plan sur une page de destination ? Une technique courante à utiliser consiste à afficher d'abord la toute première image sous forme d'image fixe, ou à afficher un court segment en boucle fortement optimisé qui pourrait être interprété comme faisant partie de la vidéo, puis, chaque fois que la vidéo est suffisamment mise en mémoire tampon, commencer à jouer la vidéo réelle. Doug Sillars a écrit un guide détaillé sur les performances vidéo en arrière-plan qui pourrait être utile dans ce cas. ( Merci Guy Podjarny ! ).

   Pour le scénario ci-dessus, vous souhaiterez peut-être fournir des images d'affiches réactives . Par défaut, les éléments video n'autorisent qu'une seule image comme affiche, ce qui n'est pas nécessairement optimal. Nous pouvons utiliser Responsive Video Poster, une bibliothèque JavaScript qui vous permet d'utiliser différentes images d'affiches pour différents écrans, tout en ajoutant une superposition de transition et un contrôle complet du style des espaces réservés vidéo.

   La recherche montre que la qualité du flux vidéo a un impact sur le comportement des spectateurs. En fait, les téléspectateurs commencent à abandonner la vidéo si le délai de démarrage dépasse environ 2 secondes. Au-delà de ce point, une augmentation d'une seconde du délai entraîne une augmentation d'environ 5,8 % du taux d'abandon. Il n'est donc pas surprenant que le temps de démarrage vidéo médian soit de 12,8 s, avec 40 % des vidéos ayant au moins 1 blocage et 20 % au moins 2 s de lecture vidéo bloquée. En fait, les décrochages vidéo sont inévitables sur la 3G car les vidéos sont lues plus rapidement que le réseau ne peut fournir de contenu.

   Alors, quelle est la solution ? Habituellement, les appareils à petit écran ne peuvent pas gérer les 720p et 1080p que nous desservons sur le bureau. Selon Doug Sillars, nous pouvons soit créer des versions plus petites de nos vidéos, et utiliser Javascript pour détecter la source des écrans plus petits afin d'assurer une lecture rapide et fluide sur ces appareils. Alternativement, nous pouvons utiliser la vidéo en streaming. Les flux vidéo HLS fourniront une vidéo de taille appropriée à l'appareil, évitant ainsi la nécessité de créer différentes vidéos pour différents écrans. Il négociera également la vitesse du réseau et adaptera le débit vidéo à la vitesse du réseau que vous utilisez.

   Pour éviter le gaspillage de bande passante, nous ne pouvions ajouter la source vidéo que pour les appareils capables de lire correctement la vidéo. Alternativement, nous pouvons supprimer complètement l'attribut de autoplay de la balise video et utiliser JavaScript pour insérer la autoplay pour les écrans plus grands. De plus, nous devons ajouter preload="none" sur video pour dire au navigateur de ne télécharger aucun des fichiers vidéo jusqu'à ce qu'il ait réellement besoin du fichier :

   <!-- Based on Doug Sillars's post. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ --> <video preload="none" playsinline muted loop width="1920" height="1080" poster="poster.jpg"> <source src="video.webm" type="video/webm"> <source src="video.mp4" type="video/mp4"> </video>

   Ensuite, nous pouvons cibler spécifiquement les navigateurs qui prennent réellement en charge AV1 :

   <!-- Based on Doug Sillars's post. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ --> <video preload="none" playsinline muted loop width="1920" height="1080" poster="poster.jpg"> <source src="video.av1.mp4" type="video/mp4; codecs=av01.0.05M.08"> <source src="video.hevc.mp4" type="video/mp4; codecs=hevc"> <source src="video.webm" type="video/webm"> <source src="video.mp4" type="video/mp4"> </video>

   On pourrait alors rajouter l' autoplay au dessus d'un certain seuil (par exemple 1000px) :

   /* By Doug Sillars. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ */ <script> window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 1000){ videoLocation.setAttribute("autoplay",""); }; } </script>

   

   Les performances de lecture vidéo sont une histoire en soi, et si vous souhaitez vous plonger dans les détails, jetez un œil à une autre série de Doug Sillars sur l'état actuel des meilleures pratiques de diffusion vidéo et vidéo qui inclut des détails sur les mesures de diffusion vidéo. , préchargement vidéo, compression et streaming. Enfin, vous pouvez vérifier la lenteur ou la rapidité de votre streaming vidéo avec Stream or Not.

1. La livraison des polices Web est-elle optimisée ?
   La première question qui mérite d'être posée est de savoir si nous pouvons nous en tirer en utilisant les polices du système d'interface utilisateur en premier lieu - nous devons simplement nous assurer de vérifier qu'elles apparaissent correctement sur différentes plates-formes. Si ce n'est pas le cas, il y a de fortes chances que les polices Web que nous servons incluent des glyphes et des fonctionnalités et poids supplémentaires qui ne sont pas utilisés. Nous pouvons demander à notre fonderie de créer des sous- ensembles de polices Web ou, si nous utilisons des polices open source, de les créer nous-mêmes avec Glyphhanger ou Fontsquirrel. Nous pouvons même automatiser l'ensemble de notre flux de travail avec la sous-fonte de Peter Muller, un outil de ligne de commande qui analyse statiquement votre page afin de générer les sous-ensembles de polices Web les plus optimaux, puis de les injecter dans nos pages.

   La prise en charge de WOFF2 est excellente et nous pouvons utiliser WOFF comme solution de rechange pour les navigateurs qui ne la prennent pas en charge - ou peut-être que les anciens navigateurs pourraient recevoir des polices système. Il existe de très nombreuses options de chargement de polices Web, et nous pouvons choisir l'une des stratégies du "Guide complet des stratégies de chargement de polices" de Zach Leatherman (des extraits de code sont également disponibles sous forme de recettes de chargement de polices Web).

   Les meilleures options à considérer aujourd'hui sont probablement le Critical FOFT avec preload et la méthode "The Compromise". Les deux utilisent un rendu en deux étapes pour fournir des polices Web par étapes - d'abord un petit sous-ensemble requis pour rendre la page rapidement et avec précision avec la police Web, puis chargez le reste de la famille de manière asynchrone. La différence est que la technique "The Compromise" charge le polyfill de manière asynchrone uniquement si les événements de chargement de police ne sont pas pris en charge, vous n'avez donc pas besoin de charger le polyfill par défaut. Besoin d'un gain rapide ? Zach Leatherman propose un didacticiel rapide de 23 minutes et une étude de cas pour mettre vos polices en ordre.

   En général, il peut être judicieux d'utiliser l'indicateur de ressource de preload pour précharger les polices, mais dans votre balisage, incluez les conseils après le lien vers les CSS et JavaScript critiques. Avec preload , il y a un casse-tête de priorités, pensez donc à injecter des éléments rel="preload" dans le DOM juste avant les scripts de blocage externes. Selon Andy Davies, "les ressources injectées à l'aide d'un script sont masquées du navigateur jusqu'à ce que le script s'exécute, et nous pouvons utiliser ce comportement pour retarder le moment où le navigateur découvre l'indice de preload ". Sinon, le chargement des polices vous coûtera le premier temps de rendu.

   

   C'est une bonne idée d'être sélectif et de choisir les fichiers les plus importants, par exemple ceux qui sont critiques pour le rendu ou qui vous aideraient à éviter les refusions de texte visibles et perturbatrices. En général, Zach conseille de précharger une ou deux polices de chaque famille - il est également logique de retarder le chargement de certaines polices si elles sont moins critiques.

   Il est devenu assez courant d'utiliser la valeur local() (qui fait référence à une police locale par son nom) lors de la définition d'une font-family dans la règle @font-face :

    /* Warning! Not a good idea! */ @font-face { font-family: Open Sans; src: local('Open Sans Regular'), local('OpenSans-Regular'), url('opensans.woff2') format ('woff2'), url('opensans.woff') format('woff'); }

   L'idée est raisonnable : certaines polices open source populaires telles que Open Sans sont préinstallées avec certains pilotes ou applications, donc si la police est disponible localement, le navigateur n'a pas besoin de télécharger la police Web et peut afficher la police locale. police immédiatement. Comme l'a noté Bram Stein, "bien qu'une police locale corresponde au nom d'une police Web, ce n'est probablement pas la même police . De nombreuses polices Web diffèrent de leur version" de bureau ". Le texte peut être rendu différemment, certains caractères peuvent tomber vers d'autres polices, les fonctionnalités OpenType peuvent être totalement absentes ou la hauteur de ligne peut être différente."

   De plus, à mesure que les polices évoluent avec le temps, la version installée localement peut être très différente de la police Web, avec des caractères très différents. Ainsi, selon Bram, il est préférable de ne jamais mélanger les polices installées localement et les polices Web dans les règles @font-face . Google Fonts a emboîté le pas en désactivant local() sur les résultats CSS pour tous les utilisateurs, autres que les requêtes Android pour Roboto.

   Personne n'aime attendre que le contenu soit affiché. Avec le descripteur CSS font-display , nous pouvons contrôler le comportement de chargement des polices et permettre au contenu d'être lisible immédiatement (avec font-display: optional ) ou presque immédiatement (avec un délai d'attente de 3 secondes, tant que la police est téléchargée avec succès — avec font-display: swap ). (Eh bien, c'est un peu plus compliqué que ça.)

   Cependant, si vous souhaitez minimiser l'impact des redistributions de texte, nous pouvons utiliser l' API Font Loading (prise en charge par tous les navigateurs modernes). Plus précisément, cela signifie que pour chaque police, nous créons un objet FontFace , puis essayons de tous les récupérer, puis de les appliquer à la page. De cette façon, nous regroupons tous les repaints en chargeant toutes les polices de manière asynchrone, puis nous passons des polices de secours à la police Web exactement une fois. Jetez un œil à l'explication de Zach, à partir de 32:15, et à l'extrait de code) :

   /* Load two web fonts using JavaScript */ /* Zach Leatherman: https://noti.st/zachleat/KNaZEg/the-five-whys-of-web-font-loading-performance#sWkN4u4 */ // Remove existing @font-face blocks // Create two let font = new FontFace("Noto Serif", /* ... */); let fontBold = new FontFace("Noto Serif, /* ... */); // Load two fonts let fonts = await Promise.all([ font.load(), fontBold.load() ]) // Group repaints and render both fonts at the same time! fonts.forEach(font => documents.fonts.add(font));
   /* Load two web fonts using JavaScript */ /* Zach Leatherman: https://noti.st/zachleat/KNaZEg/the-five-whys-of-web-font-loading-performance#sWkN4u4 */ // Remove existing @font-face blocks // Create two let font = new FontFace("Noto Serif", /* ... */); let fontBold = new FontFace("Noto Serif, /* ... */); // Load two fonts let fonts = await Promise.all([ font.load(), fontBold.load() ]) // Group repaints and render both fonts at the same time! fonts.forEach(font => documents.fonts.add(font));

   Pour lancer une récupération très précoce des polices avec l'API Font Loading utilisée, Adrian Bece suggère d'ajouter un espace insécable nbsp; en haut du body , et cachez-le visuellement avec aria-visibility: hidden et une classe .hidden :

   <body class="no-js"> <!-- ... Website content ... --> <div aria-visibility="hidden" class="hidden"> <!-- There is a non-breaking space here --> </div> <script> document.getElementsByTagName("body")[0].classList.remove("no-js"); </script> </body>
   <body class="no-js"> <!-- ... Website content ... --> <div aria-visibility="hidden" class="hidden"> <!-- There is a non-breaking space here --> </div> <script> document.getElementsByTagName("body")[0].classList.remove("no-js"); </script> </body>

   Cela va de pair avec CSS qui a différentes familles de polices déclarées pour différents états de chargement, avec le changement déclenché par l'API Font Loading une fois que les polices ont été chargées avec succès :

   body:not(.wf-merriweather--loaded):not(.no-js) { font-family: [fallback-system-font]; /* Fallback font styles */ } .wf-merriweather--loaded, .no-js { font-family: "[web-font-name]"; /* Webfont styles */ } /* Accessible hiding */ .hidden { position: absolute; overflow: hidden; clip: rect(0 0 0 0); height: 1px; width: 1px; margin: -1px; padding: 0; border: 0; }
   body:not(.wf-merriweather--loaded):not(.no-js) { font-family: [fallback-system-font]; /* Fallback font styles */ } .wf-merriweather--loaded, .no-js { font-family: "[web-font-name]"; /* Webfont styles */ } /* Accessible hiding */ .hidden { position: absolute; overflow: hidden; clip: rect(0 0 0 0); height: 1px; width: 1px; margin: -1px; padding: 0; border: 0; }

   Si vous vous êtes déjà demandé pourquoi malgré toutes vos optimisations, Lighthouse suggère toujours d'éliminer les ressources bloquant le rendu (polices), dans le même article Adrian Bece fournit quelques techniques pour rendre Lighthouse heureux, ainsi qu'un Gatsby Omni Font Loader, une police asynchrone performante plugin de chargement et de gestion de Flash Of Unstyled Text (FOUT) pour Gatsby.

   Maintenant, beaucoup d'entre nous utilisent peut-être un CDN ou un hôte tiers pour charger des polices Web. En général, il est toujours préférable d'auto-héberger toutes vos ressources statiques si vous le pouvez, alors pensez à utiliser google-webfonts-helper, un moyen simple d'auto-héberger Google Fonts. Et si ce n'est pas possible, vous pouvez peut-être proxy les fichiers Google Font via l'origine de la page.

   Il convient de noter cependant que Google fait pas mal de travail hors de la boîte, donc un serveur peut avoir besoin d'un peu de peaufinage pour éviter les retards ( merci, Barry ! )

   Ceci est assez important, d'autant plus que depuis Chrome v86 (publié en octobre 2020), les ressources intersites telles que les polices ne peuvent plus être partagées sur le même CDN - en raison du cache du navigateur partitionné. Ce comportement était un défaut dans Safari pendant des années.

   Mais si ce n'est pas possible du tout, il existe un moyen d'accéder aux polices Google les plus rapides possibles avec l'extrait de Harry Roberts :

   <!-- By Harry Roberts. https://csswizardry.com/2020/05/the-fastest-google-fonts/ - 1. Preemptively warm up the fonts' origin. - 2. Initiate a high-priority, asynchronous fetch for the CSS file. Works in - most modern browsers. - 3. Initiate a low-priority, asynchronous fetch that gets applied to the page - only after it's arrived. Works in all browsers with JavaScript enabled. - 4. In the unlikely event that a visitor has intentionally disabled - JavaScript, fall back to the original method. The good news is that, - although this is a render-blocking request, it can still make use of the - preconnect which makes it marginally faster than the default. --> <!-- [1] --> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin /> <!-- [2] --> <link rel="preload" as="style" href="$CSS&display=swap" /> <!-- [3] --> <link rel="stylesheet" href="$CSS&display=swap" media="print" onload="this.media='all'" /> <!-- [4] --> <noscript> <link rel="stylesheet" href="$CSS&display=swap" /> </noscript>

   La stratégie de Harry consiste à réchauffer d'abord l'origine des polices de manière préventive. Ensuite, nous lançons une récupération asynchrone hautement prioritaire pour le fichier CSS. Ensuite, nous lançons une récupération asynchrone de faible priorité qui n'est appliquée à la page qu'après son arrivée (avec une astuce de feuille de style d'impression). Enfin, si JavaScript n'est pas pris en charge, nous revenons à la méthode d'origine.

   Ah, parlons de Google Fonts : vous pouvez réduire jusqu'à 90 % la taille des requêtes Google Fonts en déclarant uniquement les caractères dont vous avez besoin avec &text . De plus, la prise en charge de l'affichage des polices a également été ajoutée récemment à Google Fonts, nous pouvons donc l'utiliser immédiatement.

   Un petit avertissement cependant. Si vous utilisez font-display: optional , il peut être sous-optimal d'utiliser également le preload car il déclenchera cette demande de police Web plus tôt (provoquant une congestion du réseau si vous avez d'autres ressources de chemin critique qui doivent être récupérées). Utilisez la preconnect pour des requêtes de polices d'origines différentes plus rapides, mais soyez prudent avec le preload car le préchargement de polices d'une origine différente entraînera des conflits de réseau. Toutes ces techniques sont couvertes dans les recettes de chargement de polices Web de Zach.

   D'un autre côté, il peut être judicieux de désactiver les polices Web (ou au moins le rendu de deuxième étape) si l'utilisateur a activé Réduire le mouvement dans les préférences d'accessibilité ou a opté pour le mode Économiseur de données (voir l'en-tête Save-Data ) , ou lorsque l'utilisateur a une connexion lente (via l'API Network Information).

   Nous pouvons également utiliser la requête multimédia CSS prefers-reduced-data pour ne pas définir de déclaration de police si l'utilisateur a opté pour le mode d'économie de données (il existe également d'autres cas d'utilisation). La requête multimédia exposerait essentiellement si l'en-tête de requête Save-Data de l'extension HTTP Client Hint est activé/désactivé pour permettre une utilisation avec CSS. Actuellement pris en charge uniquement dans Chrome et Edge derrière un drapeau.

   Métrique? Pour mesurer les performances de chargement des polices Web, considérez la métrique Tout le texte visible (le moment où toutes les polices sont chargées et tout le contenu est affiché dans les polices Web), le temps de mise en italique réel ainsi que le nombre de refusions des polices Web après le premier rendu. Évidemment, plus les deux mesures sont basses, meilleures sont les performances.

   Qu'en est-il des polices variables , me demanderez-vous ? Il est important de noter que les polices variables peuvent nécessiter une prise en compte significative des performances. Ils nous donnent un espace de conception beaucoup plus large pour les choix typographiques, mais cela se fait au prix d'une seule demande en série par opposition à un certain nombre de demandes de fichiers individuels.

   Alors que les polices variables réduisent considérablement la taille de fichier globale combinée des fichiers de polices, cette requête unique peut être lente, bloquant le rendu de tout le contenu d'une page. Donc, le sous-ensemble et la division de la police en jeux de caractères sont toujours importants. Du bon côté cependant, avec une police variable en place, nous aurons exactement un reflow par défaut, donc aucun JavaScript ne sera nécessaire pour regrouper les repaints.

   Maintenant, qu'est-ce qui constituerait alors une stratégie de chargement de polices Web à l'épreuve des balles ? Créez des sous-ensembles de polices et préparez-les pour le rendu en deux étapes, déclarez-les avec un descripteur font-display , utilisez l'API de chargement de police pour regrouper les repeints et stocker les polices dans le cache d'un service worker persistant. Lors de la première visite, injectez le préchargement des scripts juste avant le blocage des scripts externes. Vous pouvez vous rabattre sur Font Face Observer de Bram Stein si nécessaire. Et si vous souhaitez mesurer les performances de chargement des polices, Andreas Marschke explore le suivi des performances avec l'API Font et l'API UserTiming.

   Enfin, n'oubliez pas d'inclure unicode-range pour décomposer une grande police en polices plus petites spécifiques à la langue, et utilisez le font-style-matcher de Monica Dinculescu pour minimiser un changement de mise en page discordant, en raison des écarts de taille entre le repli et le polices Web.

   Alternativement, pour émuler une police Web pour une police de secours, nous pouvons utiliser des descripteurs @font-face pour remplacer les métriques de police (démo, activé dans Chrome 87). (Notez que les ajustements sont compliqués avec des piles de polices compliquées.)

   L'avenir s'annonce-t-il radieux ? Avec l'enrichissement progressif des polices, nous pourrons éventuellement "télécharger uniquement la partie requise de la police sur une page donnée, et pour les demandes ultérieures de cette police, "corriger" dynamiquement le téléchargement d'origine avec des ensembles supplémentaires de glyphes selon les besoins sur la page suivante vues", comme l'explique Jason Pamental. La démo de transfert incrémentiel est déjà disponible, et c'est en cours.

Table des matières

1. Se préparer : planification et métriques
2. Fixer des objectifs réalistes
3. Définir l'environnement
4. Optimisations des actifs
5. Construire des optimisations
6. Optimisations de livraison
7. Mise en réseau, HTTP/2, HTTP/3
8. Test et surveillance
9. Victoires rapides
10. Tout sur une seule page
11. Télécharger la liste de contrôle (PDF, pages Apple, MS Word)
12. Abonnez-vous à notre newsletter par e-mail pour ne pas manquer les prochains guides.