Les polices auto-hébergées : sous-ensembles, formats et préchargement

Charger ses polices depuis un service externe était le réflexe par défaut jusqu'à ce que trois arguments convergent contre cette pratique : le coût réseau d'une connexion supplémentaire, la fin du partage de cache entre sites qui en constituait le principal intérêt, et les questions posées par la transmission de données à un tiers dès l'affichage de la page. Héberger soi même ses polices est aujourd'hui la pratique recommandée, à condition de le faire correctement. Une police copiée telle quelle sur son serveur, sans découpage ni préchargement, peut coûter plus cher que la version distante qu'elle remplace.

Pourquoi héberger soi même

Le raisonnement mérite d'être posé, car la commodité du service distant reste réelle : une ligne à copier, aucune gestion de fichiers, des mises à jour automatiques. Les arguments en faveur de l'hébergement local sont pourtant décisifs sur un site professionnel, et ils rejoignent ceux exposés dans notre article sur le code tiers et l'impact des scripts externes.

Le coût réseau vient en premier. Charger une police depuis un domaine tiers impose une résolution de nom, une négociation de connexion sécurisée et un aller retour supplémentaire avant même que le fichier ne commence à arriver. Sur une connexion mobile de qualité moyenne, ces préliminaires consomment plusieurs centaines de millisecondes. Servir le fichier depuis le domaine du site réutilise la connexion déjà établie et supprime entièrement ce délai. Le gain est d'autant plus net que la police est appelée depuis une feuille de style, ce qui ajoute encore une étape avant la découverte du fichier.

L'argument du cache partagé, longtemps avancé, ne tient plus. Les navigateurs ont cloisonné leur cache par site pour des raisons de vie privée, ce qui signifie qu'une police déjà téléchargée sur un autre site sera retéléchargée sur le vôtre. Le principal bénéfice du service distant a donc disparu, sans que la pratique ne suive immédiatement. Beaucoup de projets continuent d'invoquer cet argument sans savoir qu'il est caduc depuis plusieurs années. Le vérifier soi même est immédiat : le fichier apparaît bien dans les requêtes réseau lors d'une première visite, quel que soit l'historique du navigateur.

Reste la question de la transmission de données. Une requête vers un domaine tiers transmet l'adresse réseau du visiteur et l'adresse de la page consultée, avant tout consentement. Cette transmission a fait l'objet de décisions dans plusieurs contextes européens. Nous ne sommes pas juristes et ce point mérite d'être vérifié auprès d'un conseil compétent, la conséquence pratique étant qu'un hébergement local supprime purement et simplement la question. C'est un argument commode dans une discussion de conformité, puisqu'il ferme le sujet au lieu de le déplacer vers un mécanisme de consentement.

L'hébergement local apporte enfin un contrôle que le service distant ne permet pas : choix des graisses réellement chargées, découpage des caractères, réglage des en têtes de cache, ajout de métriques de repli. Ce contrôle est précisément ce qui permet de descendre de plusieurs centaines de kilooctets à quelques dizaines. Aucun service distant ne propose ce niveau de réglage, ce qui rend la comparaison largement favorable à l'hébergement local dès que l'on accepte de faire le travail.

Choisir les formats

La question des formats se règle en une phrase sur un site moderne, et il vaut mieux comprendre pourquoi plutôt que d'appliquer une recette trouvée en ligne.

Le format compressé de deuxième génération est aujourd'hui supporté par l'ensemble des navigateurs en usage. Il compresse mieux que toutes les alternatives, souvent de trente pour cent par rapport à la génération précédente. Sur un site n'ayant pas à servir des navigateurs très anciens, c'est le seul format nécessaire. Vérifier la répartition des navigateurs dans les statistiques du site tranche la question en une minute, plutôt que de raisonner sur des hypothèses.

Les formats plus anciens, encore présents dans beaucoup de déclarations copiées d'un projet à l'autre, ne servent plus qu'à des navigateurs disparus de l'usage. Les conserver alourdit la déclaration sans bénéfice et complique la maintenance. Une déclaration à une seule source est plus lisible et plus rapide à traiter par le navigateur. Elle réduit aussi le nombre de fichiers à produire, à téléverser et à maintenir à chaque changement de police.

Les fichiers dans leur format de bureau, parfois copiés directement depuis un dossier de polices, n'ont pas leur place sur un site. Ils sont nettement plus lourds, ne bénéficient d'aucune compression spécifique et posent des questions de licence, une licence de bureau n'autorisant généralement pas la diffusion web. La conversion vers le format web est immédiate avec les outils disponibles. La question de la licence, en revanche, ne se règle pas techniquement et doit être vérifiée auprès du fondeur avant toute mise en ligne.

Les polices variables constituent le cas particulier le plus intéressant. Un fichier unique contient toutes les graisses et permet des valeurs intermédiaires, ce qui remplace avantageusement quatre ou cinq fichiers statiques. Le fichier variable pèse plus lourd qu'un fichier statique isolé et moins que la somme de ceux qu'il remplace. L'arbitrage se fait en comptant les graisses réellement employées : au delà de trois, la version variable gagne presque toujours. Elle offre en prime la possibilité d'ajuster finement la graisse selon la taille du texte, liberté typographique qu'aucun jeu de fichiers statiques ne permet.

Découper en sous-ensembles

C'est le levier le plus efficace et le plus négligé. Une police complète contient les caractères de dizaines d'alphabets, la ponctuation étendue, les symboles mathématiques et parfois des pictogrammes. Un site francophone en utilise une fraction infime. Le rapport entre ce qui est téléchargé et ce qui est affiché atteint couramment un facteur cinq, sans que personne ne s'en aperçoive.

Le découpage consiste à produire un fichier ne contenant que les caractères réellement nécessaires. Pour un site en français, l'ensemble latin de base augmenté des caractères accentués, des ligatures usuelles et de quelques signes de ponctuation suffit. Le fichier obtenu pèse couramment le tiers ou le quart de l'original. Sur quatre graisses, l'économie se compte en centaines de kilooctets pour un travail d'une demi heure.

Les outils disponibles permettent ce découpage en une commande, en indiquant soit une plage de caractères, soit la liste exacte des caractères à conserver. La seconde approche produit les fichiers les plus légers et elle est risquée : un caractère oublié s'affichera dans la police de repli, ce qui se voit immédiatement. La plage latine étendue constitue le compromis raisonnable pour un site dont le contenu évolue. Elle couvre l'ensemble des langues d'Europe occidentale, ce qui laisse de la marge pour les noms propres et les citations.

Le découpage par plages multiples, avec déclaration des intervalles de caractères couverts par chaque fichier, permet au navigateur de ne télécharger que ce dont il a besoin. Une page ne contenant aucun caractère cyrillique ne chargera pas le fichier correspondant. Cette technique est celle employée par les grands services de polices et elle se reproduit sans difficulté en local. Elle prend tout son sens sur un site multilingue, où chaque visiteur ne charge que l'alphabet qui le concerne.

Le cas des pictogrammes mérite une mention. Les polices d'icônes complètes, chargées pour afficher six symboles, représentent un gaspillage considérable. Remplacer ces icônes par des images vectorielles intégrées à la page supprime le fichier entier. C'est souvent le gain le plus important obtenu sur un site existant. Une bibliothèque d'icônes complète pèse fréquemment plus lourd que l'ensemble des polices de texte du site.

Le découpage doit enfin être refait après chaque mise à jour de la police. Consigner la commande employée dans le projet, avec ses paramètres, évite de la reconstituer un an plus tard. Cette note tient en trois lignes et elle fait gagner une demi journée. La placer à côté des fichiers produits, dans le dépôt du projet, garantit qu'elle sera trouvée par la personne qui en aura besoin.

Déclarer et précharger

La déclaration et le préchargement déterminent le moment où le texte devient lisible, ce qui compte davantage que le poids brut des fichiers.

La déclaration associe un nom de famille, une graisse, un style et une source. Elle doit être écrite une fois par variante réellement employée, en évitant de déclarer des graisses que le site n'utilise pas. Une déclaration inutilisée ne charge rien tant qu'aucun texte ne l'appelle, ce qui la rend inoffensive et inutile. Le risque réel vient d'une règle de style oubliée quelque part, qui déclenche le chargement d'une graisse dont personne n'avait conscience.

Le réglage de l'affichage pendant le chargement est le paramètre le plus important de toute la déclaration. Il détermine si le texte reste invisible en attendant la police, s'affiche immédiatement dans une police de repli puis change, ou reste dans la police de repli si le chargement tarde trop. Ce comportement est développé dans notre article sur l'affichage des polices web et le réglage du font-display.

Le préchargement indique au navigateur de télécharger un fichier en priorité, avant même qu'il n'ait analysé les feuilles de style. Il doit être réservé aux une ou deux polices utilisées dans la partie haute de la page, typiquement le corps de texte et le titre principal. Précharger cinq fichiers annule le bénéfice en saturant la bande passante initiale. Le préchargement est un mécanisme de priorité, et donner la priorité à tout revient à ne la donner à rien.

La déclaration de préchargement doit préciser le type de ressource et l'attribut d'origine croisée, faute de quoi le fichier est téléchargé deux fois. Cette erreur est fréquente et parfaitement invisible sans regarder l'onglet réseau du navigateur. Elle transforme une optimisation en régression, ce qui en fait un contrôle à mener systématiquement. Le symptôme est facile à reconnaître : le même fichier apparaît deux fois dans la liste des requêtes, avec deux origines de déclenchement différentes. Les mécanismes généraux de ces directives sont détaillés dans notre article sur le preload et preconnect pour optimiser le chargement.

Les en têtes de cache doivent enfin être généreuses. Un fichier de police ne change pratiquement jamais et peut être mis en cache pour un an, à condition que son nom comporte une empreinte permettant de forcer le rechargement en cas de modification. Ce réglage se pose une fois dans la configuration du serveur et il évite des téléchargements inutiles à chaque visite. Il fait partie des quelques lignes de configuration dont le rapport entre effort et bénéfice est le plus favorable.

Limiter le décalage visuel

Le changement de police en cours de chargement provoque un déplacement du texte, mesuré par les indicateurs d'expérience et perçu comme un défaut par les visiteurs. Il se réduit fortement par un réglage des métriques de la police de repli.

Le principe consiste à choisir une police système dont les proportions approchent celles de la police finale, puis à ajuster sa taille et son interlignage pour que les deux occupent la même place. Le remplacement devient alors presque invisible. Cette technique demande une police de repli déclarée explicitement plutôt qu'un repli générique. Le choix de cette police de repli compte autant que les réglages qui suivent, une famille aux proportions très différentes rendant l'ajustement impossible.

Les propriétés de réglage des métriques de repli, aujourd'hui supportées par les principaux navigateurs, permettent cet ajustement directement dans la déclaration : facteur de taille, hauteur au dessus et en dessous de la ligne de base, hauteur de ligne. Les valeurs se calculent à partir des métriques des deux polices ou s'obtiennent avec des outils dédiés. Ces outils produisent directement le bloc de déclaration à copier, ce qui ramène l'opération à quelques minutes.

Le résultat se mesure directement dans les outils de performance, l'indicateur de stabilité visuelle chutant nettement après ce réglage. C'est l'un des rares ajustements dont l'effet est à la fois immédiat, mesurable et sans contrepartie. Il demande une heure de mise au point la première fois et se reproduit ensuite rapidement. Les valeurs obtenues pour un couple de polices donné restent valables tant que ni l'une ni l'autre ne change, ce qui les rend réutilisables d'un projet à l'autre.

Une alternative radicale consiste à renoncer aux polices personnalisées pour le corps de texte et à ne les employer que pour les titres. Les polices système modernes sont de bonne qualité, se chargent instantanément et ne provoquent aucun décalage. Ce choix se défend particulièrement sur les sites où la performance prime sur l'identité graphique, documentation technique ou application métier. Il mérite au moins d'être proposé lors des arbitrages de maquette, plutôt que d'être écarté sans discussion.

Vérifier le résultat

Les contrôles sont rapides et ils évitent de croire à une optimisation qui n'a pas fonctionné, situation fréquente sur ce sujet.

Le premier contrôle porte sur les requêtes réellement effectuées. L'onglet réseau du navigateur, filtré sur les polices, montre quels fichiers sont téléchargés, depuis quel domaine et combien de fois. Il révèle immédiatement les doubles téléchargements, les fichiers oubliés et les appels résiduels vers un service distant. Ce contrôle prend deux minutes et il devrait être systématique. Un appel résiduel vers un service distant, oublié dans une extension ou dans un modèle de courriel, se repère uniquement de cette façon.

Le deuxième contrôle porte sur le poids total. Additionner le poids des fichiers de polices avant et après intervention donne le gain obtenu. Sur un site n'ayant jamais fait ce travail, une réduction de quatre cents à soixante kilooctets n'a rien d'exceptionnel. Ce chiffre est utile pour justifier le temps passé. Il parle nettement plus qu'une explication technique auprès d'un client qui juge le résultat sur ce qu'il perçoit.

Le troisième contrôle porte sur le rendu. Parcourir quelques pages en observant si un caractère s'affiche dans une police différente signale un découpage trop agressif. Les pages comportant des noms propres étrangers, des citations ou des symboles sont les plus révélatrices. Une relecture rapide suffit à repérer ces cas. En cas de doute, élargir le sous-ensemble à la plage latine étendue coûte quelques kilooctets et referme la question.

Le quatrième contrôle porte sur les indicateurs d'expérience, relevés avant et après. La stabilité visuelle et le délai d'affichage du contenu principal sont les deux mesures concernées. Elles bougent rarement de façon spectaculaire et leur amélioration se cumule avec les autres optimisations menées sur la page. Les relever sur données réelles plutôt qu'en laboratoire donne une image plus fidèle de ce que vivent les visiteurs.

Reste à documenter le travail : quelles polices, quelles graisses, quel découpage, quelle commande de génération, quels réglages de repli. Cette note évite qu'une refonte graphique ne réintroduise un appel distant par simplicité. Elle est particulièrement utile lorsque la personne qui choisit les polices n'est pas celle qui les intègre, ce qui est la situation habituelle.