|
1234567891011 |
- title: Polices et performances
-
- > By referencing our fonts using CSS `@font-face` and using font loading APIs to load and enable them when ready, we’ve found our fastest page load yet (complete in 600 milliseconds on wifi!) while retaining the progressive font rendering we desired.
- >
- > <cite>*[Font Loading Revisited with Font Events](http://www.filamentgroup.com/lab/font-events.html)* ([cache](/david/cache/1e31deb6dc3b4901dcb305145f336709/))</cite>
-
- À force de rajouter des polices dans ma feuille de style (5 à ce jour…) elle commençait à être énorme et leurs ajouts sous forme de [data URI](https://en.wikipedia.org/wiki/Data_URI_scheme) s’avérait être beaucoup moins pertinent. Même en gagnant sur la latence en n’ayant qu’un seul fichier, la page ne commençait à s’afficher qu’une fois la `CSS` complètement chargée. Soit après 4,5 secondes sur une connexion 3G pour un article !
-
- En explorant les [Font Load Events](https://dev.opera.com/articles/better-font-face/) ([cache](/david/cache/8486c4b84558a0b8cb418cfdccb66d6b/)) **j’ai pu réduire ce temps de moitié pour la même taille de téléchargement.** C’est un gain vraiment énorme en terme de ressenti qui ne change rien au poids ou au temps de chargement du document complet. Il n’y a que la police pour le code que je charge directement avec `@font-face` car ainsi le navigateur ne la charge que s’il y a ces éléments présents dans la page (et normalement le code arrive plus bas dans la lecture).
-
- L’inconvénient principal est au rafraichissement de la page car on s’aperçoit que le chargement des polices est fait en JavaScript mais l’usage [d’InstantClick](http://instantclick.io/) rend ce rafraichissement moins courant. L’autre problème est de dépendre de JavaScript pour afficher des polices qui pourraient être chargées nativement de manière optimisée…
|
