Maintenir les performances – daverupert.com


Ou … Comment je me suis rasé ~ 33 secondes sur le chargement de ma page en corrigeant les polices

20 mars 2020

Il y a quelque temps, j’ai pu raser environ 33 secondes après le temps de chargement de ma page en fixant la façon dont je charge les polices.

Surprenant, je sais! Dans mes tentatives précédentes de suivre les meilleures pratiques de pointe, j’ai fait une erreur honnête:





Ça a l’air rapide, non? Je suis précharger mes fichiers de polices donc ils apparaissent le plus vite possible puis font un petit switcheroo asynchrone pour empêcher mon @font-face règle de feuille de style de blocage. Eh bien… je suis tombé dans un piège. Le préchargement de trois polices signifiait que d’autres choses ne se chargeraient pas aussi rapidement et cela est devenu un goulot d’étranglement que je n’ai pas remarqué en raison des techniciens de maintenance ou de ma connexion rapide. J’ai donc tout brûlé et je suis retourné à la police CSS font-display: swap.

@font-face {
	font-family: "Rubik";
	font-display: swap;
  src: url("/fonts/rubik.woff2") format("woff2"),
       url("/fonts/rubik.woff") format("woff");
}

...

le font-display La propriété est un nouvel outil incroyable qui n’existait pas la dernière fois que j’ai travaillé sur mon site. font-display permettez-moi de préciser Comment et quand J’aimerais que mes polices soient appliquées. le swap valeur signifie que mes polices seront «échangées» chaque fois qu’elles seront prêtes sans bloquer le chargement de la page, ce que j’essayais de faire avec cela astuce CSS paresseux. Maintenant que mes polices sont appliquées paresseusement, je n’avais même plus besoin de la feuille de style séparée.

C’est un peu contre-intuitif, mais en m’éloignant des astuces de préchargement, mon site est devenu beaucoup plus rapide, avec moins de demandes et est devenu plus facile à maintenir. Il est totalement possible de superposer preload encore une fois produirait un avantage tangible, mais j’ai appris une leçon pour adopter une approche plus itérative avec un meilleur suivi.

C’est tout pour dire…

Cette histoire concerne moins les performances des polices Web et sert en fait de cadre à un autre point que j’essaie de faire valoir. Moi, Dave Rupert, une personne qui se soucie des performances Web, une personne qui lit les blogs de performances Web, une personne qui passe de nombreuses heures à essayer de suivre les meilleures pratiques, une personne qui co-organise un podcast hebdomadaire sur la création de sites Web et la parole avec des professionnels de la performance Web… en quelque sorte gaffé et ajouté 33 SECONDES à leur chargement de page.

Je trouve que les performances Web ne sont pas particulièrement difficiles une fois que vous comprenez les leviers que vous pouvez tirer; réduire les kilo-octets, réduire les demandes, débloquer le rendu, différer les scripts. Mais maintenir les performances c’est une toute autre histoire…

Au fil du temps sur n’importe quel projet sur lequel j’ai travaillé, des facteurs incontrôlables commencent à s’introduire; Le TTFB ralentit à partir de votre hébergeur, le marketing poursuit une série de scripts de suivi dans Google Tag Manager, ceux-ci montrent que les tiers ont des tiers lents, les processeurs ont des vulnérabilités majeures, la compensation de la dette technique est repoussée dans le carnet de commandes et les navigateurs apportent des modifications mineures à algorithmes de chargement.

Les «meilleures pratiques», j’ai tendance à me sentir, changent tous les 6 à 12 mois:

  • « Utilisation preload« De toute évidence, je n’ai pas évolué.
  • «Utiliser des images floues» pourrait probablement être «Utiliser loading="lazy" avec height et width« Maintenant, mais certaines personnes pensent que loading="lazy" est trop impatient! 🤷
  • «Faire {X, Y, Z} pour les polices» est une entreprise sans fin.
  • «Bundle your JavaScript» se transforme actuellement en «Only bundle for IE11»…
  • Oh, et vous devriez maintenant écrire tout votre code non-UI chez les travailleurs…

La liste continue. Il convient également de noter que les correctifs de performances Web relèvent généralement de l’architecture. La mise à jour d’une meilleure pratique a tendance à être un correctif profond et implique la mise à jour d’un processus de génération, d’un modèle global ou d’un composant de bas niveau / très dépendant. Effectuer et annuler ces types de modifications de performances nécessite des efforts.

D’après mon expérience, 99% du temps, les performances Web se résument à deux problèmes:

  1. « Vous avez écrit trop de JavaScript. »
  2. « Vous avez des images non optimisées. »

Lequel, d’accord. Bien. Le JavaScript est assez difficile à trouver et la plupart des entreprises ne le feront tout simplement pas. C’est malheureux pour leurs utilisateurs et l’auto-justification des développeurs n’est qu’un bruit blanc pour moi à ce stade. Le problème des images, cependant, est assez omniprésent et il y a trois façons de sortir de cette confiture:

  1. Payez un service pour toujours.
  2. Concoctez un processus de construction ginormous.
  3. Une vigilance constante et un travail manuel pour assurer la meilleure qualité au kilo-octet.

Et cela ne résume-t-il pas presque tous les problèmes de développement Web? Utilisez un tiers, construisez vous-même quelque chose de cruel ou dépensez d’énormes quantités d’énergie pour établir une faible culture basée sur les processus. Parfois, je me demande à quoi ressemblerait la vie si je choisissais toujours l’option n ° 1.

Automatiser certains problèmes

J’aime faire les performances Web manuellement, afin d’avoir des mains en cuir qui comprennent le problème. Mais étant donné que les performances Web sont un problème changeant et un jardin que vous devez avoir tendance, automatiser peut-être ce que je peux est un choix intelligent.

J’ai une courte liste de tâches à faire des processus automatisés que je voudrais essayer de configurer et d’évaluer avant de transmettre ces recommandations à un client. Je peux peut-être me tailler un peu de temps en ces temps mornes pour expérimenter et jouer, mais cela demande beaucoup.

Je cherche à ajouter Lighthouse CI en tant qu’action Github. De cette façon, je pourrais résoudre le problème de la «vigilance constante» et déplacer l’aiguille de la surveillance manuelle pour être informé de manière proactive de toute régression de performance. Ce serait aussi cool à utiliser Lighthouse en tant que plugin de construction Netlify car j’utilise généralement Netlify comme CI, mais je ne pense pas qu’il collecte des données historiques à ce stade.

Une autre voie serait d’utiliser quelque chose comme SpeedCurve ou Calibre introduire la surveillance. Bien que ces services soient excellents, ils sont plus chers pour les grandes entreprises (plus compétitives) que mon site personnel. 20 $ ~ 60 $ par mois pour mon blog serait une augmentation de 2,5x ~ 5x des coûts d’exploitation.

Je regarde aussi Utilisation de Thumbor comme CDN d’image pour résoudre le problème d’image non optimisée. J’ai longtemps rêvé de pouvoir auto-héberger mon propre serveur multimédia qui fait pour moi toute l’optimisation sans perte et le service adaptatif (comme WebP lorsqu’il est pris en charge). Cela ajoute environ 5 $ / mois sur les coûts de maintenance de Digital Ocean juste pour affiner les images. Je viens aussi d’apprendre que Netlify Large Media a une transformation d’image mais nécessite de passer à GitLFS et ne semble pas faire de diffusion adaptative.

Je pense que si je pouvais régler ces deux automatisations, j’aurais plus de facilité maintenir performances à un coût minime. Si vous avez réussi, j’aimerais en savoir plus sur votre configuration.



Auteur de l’article : manuboss