Manger moins gras, salé, sucré, ça vaut aussi pour les CSS, et y intégrer des fonts directement en base64 les alourdit considérablement. Fasterize vous aide à optimiser vos temps de chargement en externalisant les fonts au lieu de les intégrer dans les CSS, une ressource critique que le navigateur doit pouvoir charger le plus vite possible. L’impact ? Des pages qui s’affichent plus rapidement grâce à un meilleur Start Render.
Une nouvelle fonctionnalité pour accélérer encore le temps de chargement de vos pages
Fasterize a pour vocation d’aider ses clients à accéder aux bonnes pratiques et aux standards webperf, et pour faire suite à nos optimisations dédiées aux fonts, notre moteur permet désormais l'extraction des fonts incluses dans la propriété @font-face du CSS.
L’inlining des fonts était une pratique répandue jusqu’à récemment, alors même que l’arrivée de HTTP/2 et de font-display l’avait rendue encore plus contre-productive. Dès 2015, Bram Stein rapportait déjà les limites de ce procédé sur son blog.
Pourquoi et comment activer la correction de l’inlining des fonts avec Fasterize
Si vous souhaitez activer la correction de l’inlining des fonts, il vous suffit simplement de vous rendre sur votre Dashboard :
L’inlining des fonts, une optimisation qui n’en est pas une
Un peu d’histoire pour mieux comprendre les origines de l’inlining des fonts : cette pratique était populaire à l’époque de HTTP/1, pour réduire le chemin critique du rendu de la page en diminuant le nombre de requêtes.
Pourquoi vouloir diminuer le nombre de requêtes ? Parce qu’en HTTP/1, un navigateur ne peut télécharger qu’un nombre limité de ressources en parallèle. Chaque nouvelle connexion TCP prenant un certain temps, cela entraîne un délai supplémentaire pour afficher les textes. Ainsi, lorsque toutes les polices sont combinées dans la même feuille de style, il n’y a qu’un seul établissement de connexion à prévoir. Le rendu des textes est plus lent mais l’avantage est que toutes les fonts sont disponibles en même temps lors de l’affichage de la page - et c’est bien l’un des seuls.
Premier inconvénient notable de l’inlining : certains navigateurs peuvent nécessiter d’attendre plusieurs secondes que les polices soient disponibles avant de rendre la page. De ce fait, en cas de fichiers en erreur ou en timeout, le SPOF (page blanche, l’angoisse) est inévitable.
Privés de rendu progressif et de lazyloading (et de dessert)
Sur son blog, Bram Stein illustre notamment par deux waterfalls, repris ci-après, l'inconvénient de l’inlining des fonts. Dans le cas où la bande passante n’est pas saturée, il y a une vraie différence de téléchargement.
Ce premier visuel montre la façon dont les fonts se chargent lorsqu’elles ne sont pas inlinées. On observe ici un téléchargement parallèle et un affichage dès que le chargement est terminé pour chacune des polices A, puis B, puis C :
Téléchargement de fonts externes en parallèle
Si ces 3 polices sont insérées dans la même feuille de style, voici ci-dessous l'aspect que prend le waterfall. Le navigateur ne télécharge qu'un seul fichier CSS qui est beaucoup plus volumineux. Il prend ainsi plus de temps à charger que 3 fichiers de polices distincts téléchargés en parallèle :
Téléchargement de fonts inlinées en séquence
Comme de nombreux navigateurs autorisent jusqu'à 8 téléchargements par domaine en HTTP/1, et pratiquement de façon illimitée en HTTP/2, réunir les fonts en un seul fichier alors qu’un navigateur peut télécharger plusieurs ressources simultanément n’a que peu d’intérêt.
Plus précisément, l’inlining des fonts empêche de profiter des avantages des téléchargements parallèles, du rendu progressif et du lazyloading. En effet, les fonts ne peuvent s’afficher qu’une fois qu’elles sont toutes disponibles… à la fin du chargement de la feuille de style.
Par ailleurs, toutes les polices sont téléchargées, mêmes si elles ne sont pas utiles sur la page, et charger des ressources inutiles n’a vraiment aucun intérêt.
Un seul format de police possible : WOFF
Désavantage supplémentaire de l’inlining des fonts : il limite à un seul format de police web. Comme le fichier de font entier est intégré au CSS, la prise en charge d'un autre format augmenterait encore sa taille (une même police est stockée une fois par format).
La seule possibilité est donc de servir le format de police avec la plus large prise en charge par les navigateurs : WOFF. Exit, donc, le format WOFF2 et son taux de compression bien supérieur.
L’encodage base64 inefficace
Encore un inconvénient de l’inlining : les fichiers inlinés en base64 sont en moyenne 30% plus gros que la version binaire, comme vous pouvez le voir sur ce graphique :
Taille moyenne d’un fichier WOFF d’après l’analyse d’un corpus de 20 000 fichiers.
L’encodage base64 pour un fichier WOFF augmente sa taille d’environ 30 %,
mais la compression Gzip la réduit presque à sa taille d’origine.
Heureusement le passage en Gzip permet de rattraper un peu le coup. L’autre inconvénient de base64 est qu’il nécessite beaucoup de temps de décodage sur les mobiles, particulièrement sur les mobiles de gamme moyenne ou inférieure dont les CPU sont maigrelets.
La mise en cache affectée
L’inlining a aussi un impact négatif sur la mise en cache. Si vous mettez à jour une ou plusieurs font(s) dans votre feuille de style, vous devrez alors invalider le cache du navigateur pour toute la feuille de style (par exemple, en modifiant son nom). Vos utilisateur.rice.s devront alors télécharger à nouveau le fichier CSS contenant toutes les fonts, même si la plupart d’entre elles n’ont pas changé.
Alors que si les fichiers de police étaient servis et mis en cache sous forme de fichiers individuels, seul le fichier de police mis à jour pourrait être téléchargé à nouveau, et les autres fichiers pourraient rester tranquillement en cache. Indéniablement, l’inlining n’est pas avantageux non plus pour les internautes (et on est gentil en disant ça ;-)).
La propriété font-display inexploitable
Pour finir la longue liste des inconvénients, l’inlining des fonts rend la propriété font-display caduque. C’est bien dommage car elle permet justement d’éviter les SPOF, puisque appliquée à la déclaration @font-face, elle définit la façon dont le navigateur se comporte avant et pendant le téléchargement des fonts.
Vous l’aurez compris, nous ne recommandons vraiment pas d’inliner les fonts, et pour conclure, voici un cas pratique que nous avons rencontré avec un de nos clients, un site e-commerce que nous accompagnons dans l’amélioration des temps de chargement.
Cas pratique : ce que nous avons mis en place
Sur le site de notre client les fonts étaient inlinées dans le fichier CSS, ce qui faisait que le navigateur les téléchargeait toutes, qu’elles soient utilisées ou non sur la page. On voit ici sur le Waterfall un fichier bien lourd (947 Ko) qui prend un temps considérable à se charger :
Grâce à la correction de l’inlining des fonts, le poids du fichier a été réduit par 10 pour passer à moins de 100k, permettant ainsi au navigateur de ne charger que les fonts utiles pour la page :
Tests réalisés avec WebPageTest sur Chrome sur mobile en 3G
L’impact est d’autant plus visible sur cette vidéo, avec à gauche la version “non-fasterizée” du site, au milieu la version optimisée par Fasterize sans correction de l’inlining des fonts, et à droite la version “fasterizée” avec correction de l’inlining des fonts :
A présent, vous vous demandez ce qui se passe sur le plan technique dans votre feuille de style ? Voici un aperçu :
Les propriétés src vont référencer un fichier construit par Fasterize à partir du fichier inliné ou d’une autre source non inlinée.
Enfin, si vous avez des questions sur cette nouvelle fonctionnalité, nos experts webperf seront bien entendu ravis de vous éclairer !
Vous souhaitez découvrir toutes nos fonctionnalités
pour automatiser intelligemment l'optimisation de vos temps de chargement ?
