Impressions sur Typekit

Vincent Bernat

En des temps im­mé­mo­riaux, avant l’in­tro­duc­tion de CSS 3, les na­vi­ga­teurs ne pou­vaient ex­ploi­ter que les po­lices pré­sentes sur le sys­tème de l’uti­li­sa­teur. Tout ceci a pris fin avec l’in­tro­duc­tion de @font-face et le sup­port de cette di­rec­tive dans tous les na­vi­ga­teurs ac­tuels. Les concep­teurs web peuvent dé­sor­mais choi­sir parmi une large pa­lette de polices.

Ty­pe­kit four­nit sous forme d’abon­ne­ment une bi­blio­thèque de po­lices de grande qua­lité uti­li­sables sur des sites web. J’ex­pose ici mon point de vue quasi-no­vice1 sur ce service.

Rudiments d’intégration des fontes#

Il existe plu­sieurs mé­thodes pour ex­ploi­ter les fontes de son choix dans des do­cu­ments Web. Exa­mi­nons les prin­ci­pales d’entre elles.

Auto-hébergement et @font-face#

Une pre­mière pos­si­bi­lité est d’hé­ber­ger soi-même les fonts et d’in­clure les di­rec­tives CSS @font-face ap­pro­priées. Il y a alors cinq choses im­por­tantes à savoir :

  1. Au­cun for­mat com­mun à tous les na­vi­ga­teurs n’existe. Il est alors né­ces­saire de four­nir chaque fonte sous dif­fé­rents for­mats pour sup­por­ter le plus de na­vi­ga­teurs possibles.
  2. Bien en­tendu, le cas d’In­ter­net Ex­plo­rer né­ces­si­tera quelques bi­douilles.
  3. La plu­part des na­vi­ga­teurs im­pose la « same ori­gin po­licy » : une fonte ne peut être té­lé­char­gée que de­puis le même do­maine que la page qui l’uti­lise. Il est pos­sible de contour­ner une telle po­li­tique en au­to­ri­sant ex­pli­ci­te­ment l’ac­cès à ces res­sources de­puis un do­maine tiers. On parle alors de « cross-ori­gin re­source sha­ring ». Il faut ajou­ter l’en­tête Access-Control-Allow-Origin pour ser­vir les fontes en question.
  4. Les fontes chan­geant peu sou­vent, pour amé­lio­rer le mé­ca­nisme de cache, il est pré­fé­rable de confi­gu­rer une date d’ex­pi­ra­tion as­sez loin­taine dans le fu­tur. Par exemple, en­vi­ron 30 jours.
  5. Il n’y a pas de type MIME prévu pour les fontes. Il est donc par­fai­te­ment in­utile d’en confi­gu­rer un, même si Google Chrome s’en plaint dans la console.

Font Squir­rel est un ou­til par­ti­cu­liè­re­ment utile à ce ni­veau. Il four­nit des kits prêts à l’em­ploi. Il suf­fit de choi­sir la fonte que l’on dé­sire uti­li­ser (ou té­lé­char­ger sa propre fonte) et les for­mats à prendre en compte (mieux vaut les co­cher tous) pour ob­te­nir une ar­chive ZIP conte­nant les fontes et les dé­cla­ra­tions CSS à uti­li­ser. Il est pré­fé­rable de mo­di­fier lé­gè­re­ment ces der­nières pour uti­li­ser au­to­ma­ti­que­ment les va­riantes d’une fonte de base ou la co­pie lo­cale de l’uti­li­sa­teur si dis­po­nible. Par exemple, pour la po­lice de ca­rac­tères Crim­son en gras, la dé­cla­ra­tion sui­vante me semble pré­fé­rable à celle four­nie dans le kit :

@font-face {
    font-family: 'Crimson';
    src: url('Crimson-Bold-webfont.eot');
    src: local('Crimson Bold'), local('Crimson Text Bold'),
         url('Crimson-Bold-webfont.eot?#iefix') format('embedded-opentype'),
         url('Crimson-Bold-webfont.woff') format('woff'),
         url('Crimson-Bold-webfont.ttf') format('truetype'),
         url('Crimson-Bold-webfont.svg#CrimsonBold') format('svg');
    font-weight: bold;
    font-style: normal;
}

Google Web Fonts#

Plu­tôt que d’hé­ber­ger soi-même les fontes, il est pos­sible d’op­ter pour un hé­ber­ge­ment ex­terne. Dans le cadre des po­lices de ca­rac­tères libres, Google Web Fonts consti­tue une so­lu­tion en­vi­sa­geable. Le prin­cipe de fonc­tion­ne­ment est fort simple : on construit une col­lec­tion de fontes, on choi­sit pour cha­cune d’elles les va­riantes que l’on sou­haite uti­li­ser et on ob­tient en re­tour une ligne à col­ler dans l’éle­ment <head> de sa page. Par exemple, pour Crimson :

<link href='http://fonts.googleapis.com/css?family=Crimson+Text:400,700,400italic'
      rel='stylesheet' type='text/css'>

Pour­quoi choi­sir cette so­lu­tion plu­tôt que l’auto-hé­bergement ?

  1. Il n’y a pas à uti­li­ser (et par­fois payer) sa propre bande pas­sante pour ser­vir les fontes.
  2. Google dis­pose de son propre CDN. Cela re­pré­sente un gain im­por­tant au ni­veau des per­formances.
  3. La mise en cache est plus ef­fi­cace car plu­sieurs sites par­tagent la même fonte.
  4. La mise en place est plus simple.

À moins de se mé­fier de Google, no­tam­ment en ce qui concerne la traque des vi­si­teurs2, je pense qu’il s’agit là d’une meilleure so­lu­tion que d’hé­ber­ger soi-même les fontes. Dans ce do­maine, les per­for­mances sont par­ti­cu­liè­re­ment im­por­tantes étant donné que les fontes sont né­ces­saires au rendu du document.

Services payants#

Pour uti­li­ser des po­lices de ca­rac­tères com­mer­ciales telles que Adobe Mi­nion Pro ou Pa­ra­type Fu­tura PT, une al­ter­na­tive in­té­res­sante est de les louer. Ty­pe­kit pro­pose un tel ser­vice. Les ta­rifs dé­pendent du vo­lume et du nombre de fontes au­quel on dé­sire avoir ac­cès. Il existe une op­tion gra­tuite et l’abon­ne­ment le moins cher est à 24,99 $ par an. Il existe de nom­breux ser­vices si­milaires.

Une fois ins­crit, l’uti­li­sa­tion est sem­blable à Google Web Fonts : on sé­lec­tionne les fontes que l’on sou­haite uti­li­ser et on les as­semble dans un kit que l’on pu­blie. Plu­tôt que de four­nir di­rec­te­ment un fi­chier CSS, Ty­pe­kit four­nit un bout de Java­Script qui va en­suite té­lé­char­ger un CSS conte­nant toutes les fontes dans un for­mat ap­pro­prié pour le na­vi­ga­teur (avec la plu­part d’entre eux, les fontes sont conte­nues di­rec­te­ment dans le CSS).

<script type="text/javascript"
        src="//use.typekit.com/tyt0atd.js"></script>
<script type="text/javascript">
  try{Typekit.load();}catch(e){}
</script>

Typekit: les points positifs…#

Pour­quoi op­ter pour Ty­pe­kit ? Tout d’abord, il y a un très large choix de fontes. L’abon­ne­ment payant le moins cher donne ac­cès à plus de 500 po­lices de ca­rac­tères is­sues de plus de 80 fon­de­ries. Il y a une cen­taine de po­lices à em­pat­te­ment et en­vi­ron le double sans em­pattement.

Ty­pe­kit pro­pose une in­ter­face ef­fi­cace pour na­vi­guer à tra­vers les fontes. Il est pos­sible d’ef­fec­tuer des re­cherches par nom ou de fil­trer se­lon les ca­rac­té­ris­tiques de la po­lice re­cher­chée (avec ou sans em­pat­te­ment, graisse, lar­geur, hau­teur, contraste, uti­li­sa­tion re­com­man­dée, langues sup­por­tées, etc.).

Pour toute ques­tion ou pro­blème, le sup­port est di­li­gent et ra­pide. J’ai ob­tenu des ré­ponses claires à mes ques­tions en quelques heures du­rant un week-end.

…et les points négatifs#

Mal­heu­reu­se­ment, Ty­pe­kit a aussi quelques dé­fauts. L’un des prin­ci­paux est l’uti­li­sa­tion de Java­Script qui em­pêche aux per­sonnes le désac­ti­vant l’ac­cès aux fontes. Si c’est un point im­por­tant pour vous, res­tez éloi­gnés de Typekit.

Ni libre, ni gratuit#

Bien que Ty­pe­kit pro­pose quelques fontes libres, la plu­part d’entre elles ne le sont pas. De plus, l’abon­ne­ment gra­tuit contient beau­coup moins de fontes que les abon­ne­ments payants. Bien que je pré­fé­re­rais uti­li­ser des fontes libres, ce n’est pas un point dé­ter­mi­nant pour moi : il est fa­cile d’op­ter pour une autre fonte ou un autre service.

J’aime beau­coup les po­lices avec em­pat­te­ment et le monde libre s’at­tarde ra­re­ment sur celles-ci ; il est alors dif­fi­cile d’en trou­ver des at­trayantes dont le rendu à l’écran est ex­cellent. Droid Se­rif est trop co­lo­rée à mon goût. Peut-être que Cardo me conviendrait.

Choix et tests des fontes#

Alors que na­vi­guer dans les dif­fé­rentes fontes est simple et agréable, les com­pa­rer et les tes­ter est une autre af­faire. On ap­pré­cie­rait en ef­fet de pou­voir com­pa­rer le rendu d’un pa­ra­graphe à l’aide de plu­sieurs fontes sur une même page, ou alors de pou­voir as­sem­bler un titre et un pa­ra­graphe afin de ju­ger si deux po­lices s’ap­pa­rient cor­rec­te­ment. Sur ce point, Google Web Fonts pro­pose des in­ter­faces plus abouties.

Les choses se com­pliquent sin­gu­liè­re­ment quand il s’agit de tes­ter les fontes choi­sies sur son propre site. En ef­fet, chaque mo­di­fi­ca­tion du kit doit être sui­vie d’une pu­bli­ca­tion de ce­lui-ci. Cette der­nière peut né­ces­si­ter d’at­tendre cinq à dix mi­nutes avant d’être ef­fec­tive. De plus, il est né­ces­saire de jon­gler entre les kits (dont le nombre est aussi li­mité) pour ne pas af­fec­ter le site pu­blié quand on dé­sire tes­ter quelques mo­di­fi­cations.

Il au­rait été pré­fé­rable de pro­po­ser un kit conte­nant toutes les fontes dis­po­nibles. Ce kit pour­rait par exemple être li­mité à cer­taines IP pour évi­ter les abus. C’est quelque chose que pro­pose Font­deck, un concur­rent de Typekit.

Peu de sous-ensembles disponibles#

Parce qu’il est sou­vent né­ces­saire de main­te­nir la taille des fontes sous une cer­taine li­mite (par exemple, 30 Ko par fonte), Ty­pe­kit pro­pose pour la plu­part des fontes deux en­sembles de ca­rac­tères : l’en­semble par dé­faut ne contient que cer­tains ca­rac­tères la­tins et l’en­semble com­plet contient tous les ca­rac­tères dis­po­nibles dans la fonte. Si un ca­rac­tère est ab­sent de l’en­semble par dé­faut, il faut alors uti­li­ser l’en­semble com­plet qui est sou­vent deux à quatre fois plus gros. Ce qui est dom­mage pour un seul ca­ractère.

Il se­rait pré­fé­rable de pro­po­ser des sous-en­sembles pour chaque langue. J’op­te­rais alors pour un sous-en­semble fran­co­phone qui contien­drait, en plus des ca­rac­tères de l’en­semble par dé­faut, le ca­rac­tère « œ » que l’on trouve dans « cœur » et dans « œil ». C’est le seul ca­rac­tère man­quant de l’en­semble par défaut !

Quand un ca­rac­tère est ab­sent, le na­vi­ga­teur uti­lise le ca­rac­tère de la fonte sui­vante dans la pile CSS. Par exemple, si la fonte sou­hai­tée est FF Tisa Web Pro et que la fonte sui­vante est Droid Se­rif, voici ce que donne le mot «cœur». Sur la pre­mière ligne, FF Tisa Web Pro contient tous les ca­rac­tères adé­quats tan­dis que sur la se­conde, le ca­rac­tère « œ » est pris dans la fonte Droid Se­rif. Étant donné que ces deux fontes dif­fèrent par leur hau­teur et leur contraste, on re­marque des dif­fé­rences, par­ti­cu­liè­re­ment pour les pe­tites tailles où l’er­reur at­teint les 10 %.

Divers rendu pour le mot « cœur »
Rendu quand le caractère est présent, substitué par celui d’une autre fonte ou émulé. Rendu à 72 pixels et 16 pixels (agrandi).

J’ai éga­le­ment ajouté une troi­sième ligne où la li­ga­ture est construite en ac­co­lant « o » et « e ». Le style sui­vant est ap­pli­qué sur « e » :

.lf-ligature {
    margin-left: -0.172em;
    zoom: 1; /* Here to trigger hasLayout on IE7 */
}

Le ré­sul­tat est tout à fait res­pec­table. J’uti­lise un peu de Java­Script pour trans­for­mer la li­ga­ture. Il se­rait pos­sible de prendre en charge des li­ga­tures sup­plé­men­taires mais éga­le­ment d’ajou­ter des ca­rac­tères com­po­sés (comme on en trouve dans des mots comme « An­tonín Dvořák »).

Mise en cache peu satisfaisante#

Mise à jour (08.2012)

Ty­pe­kit a mo­di­fié la fa­çon dont les fontes sont ser­vies. Il est pro­bable que ce pa­ra­graphe soit dé­sor­mais caduc.

Comme un do­cu­ment ne peut être af­fi­ché qu’une fois que les fontes ont été char­gées3, il est par­ti­cu­liè­re­ment im­por­tant que le té­lé­char­ge­ment des fontes soit le plus ra­pide pos­sible. Ty­pe­kit fait ap­pel à Ed­ge­cast comme CDN et DynECT pour le DNS.

Deux fi­chiers sont té­lé­char­gés, tous deux hé­ber­gés sur use.​typekit.​com. Le pre­mier est un script qui fait of­fice de char­geur. Se­lon les ca­rac­té­ris­tiques du na­vi­ga­teur, il dé­ter­mine quelle est la meilleure fa­çon de char­ger les fontes. Le se­cond fi­chier est gé­né­ra­le­ment un gros fi­chier CSS.

Voici les en­têtes re­tour­nées par le pre­mier fichier :

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=300
Content-Encoding: gzip
Content-Type: text/javascript
Date: Tue, 08 Nov 2011 18:34:16 GMT
ETag: "388467610+gzip"
Expires: Tue, 08 Nov 2011 18:39:16 GMT
Last-Modified: Sat, 05 Nov 2011 09:31:57 GMT
Server: ECS (cdg/D624)
Vary: Accept-Encoding
X-Cache: HIT
Content-Length: 7440

Tout d’abord, no­tons que le contenu du fi­chier est com­pressé. Bon point. Les en­têtes à exa­mi­ner en­suite sont Cache-Control, Date, ETag et Expires : le ser­veur de­mande au na­vi­ga­teur d’in­va­li­der le cache au bout de 5 mi­nutes. Quand le na­vi­ga­teur re­marque que sa co­pie n’est plus à jour, il va de­man­der au ser­veur une co­pie plus ré­cente, si dis­po­nible, en in­cluant l’en­tête If-None-Match: 388467610+gzip. À moins que le kit ait été mo­di­fié, le ser­veur va alors ré­pondre qu’il n’y a pas eu de mo­di­fi­ca­tions (304 Not Modified) et ne ren­verra pas le fi­chier. La co­pie sera alors va­lable 5 autres mi­nutes. Cela si­gni­fie qu’après 5 mi­nutes, il est né­ces­saire d’ef­fec­tuer trois al­ler-re­tour entre le client et le ser­veur juste pour sa­voir s’il existe une nou­velle version.

Pire, par­fois, les ser­veurs de Ty­pe­kit mettent du temps à ré­pondre, jusqu’à une mi­nute dans cer­tains cas. Comme le pre­mier fi­chier est un script que l’on in­dique dans <head>, la to­ta­lité de la page est blo­quée en at­ten­dant ce­lui-ci. Voici un exemple de ce qui ar­rive par­fois (mais ra­re­ment) quand on charge une page uti­li­sant Ty­pe­kit alors que tous les élé­ments sta­tiques sont en cache :

Capture d'écran de Chromium Inspector
Frise du déroulement du chargement d’une page utilisant Typekit

On re­marque que le rendu de la page a été mis en pause pen­dant 3,5 se­condes en at­tente des res­sources is­sues de Ty­pe­kit. En re­gar­dant plus at­ten­ti­ve­ment, on re­marque d’autres pro­blèmes, no­tam­ment la pré­sence d’un code re­tour 200 au lieu de 304. Voici la re­quête (par­tielle) qu’a en­voyé le na­vigateur :

GET /tyt0atd.js HTTP/1.1
Host: use.typekit.com
Connection: keep-alive
Accept-Encoding: gzip,deflate,sdch
If-None-Match: "2200251225+gzip"
If-Modified-Since: Thu, 10 Nov 2011 11:38:11 GMT

Et voici un ex­trait de la réponse :

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=300
Content-Type: text/javascript
Date: Fri, 11 Nov 2011 17:10:03 GMT
ETag: "2200251225"
Expires: Fri, 11 Nov 2011 17:15:03 GMT
Last-Modified: Thu, 10 Nov 2011 11:38:11 GMT
Server: EOS (lax001/54E5)
Content-Length: 25755

Que s’est-il passé ? Pour une rai­son in­con­nue, le ser­veur n’a pas jugé sou­hai­table de don­ner ac­cès à la ver­sion com­pres­sée de la res­source : il n’y a pas d’en­tête Content-Encoding: gzip dans la ré­ponse alors que le na­vi­ga­teur a uti­lisé l’en­tête Accept-Encoding: gzip. L’éti­quette ETag four­nie par le na­vi­ga­teur (2200251225+gzip) pro­vient ma­ni­fes­te­ment de la ver­sion com­pres­sée. Celle-ci étant in­dis­po­nible et la RFC 2616 in­di­quant d’igno­rer l’en­tête If-Modified-Since dans ce cas, le ser­veur ré­pond avec 200 OK et ren­voie l’in­té­gra­lité du fi­chier. Non seule­ment la mise en cache n’a pas fonc­tionné mais on doit en plus té­lé­char­ger la ver­sion non com­pressée !

Sup­po­sons main­te­nant que ce pro­blème ne soit pas ap­paru et que le ser­veur ait ré­pondu, comme at­tendu, avec 304 Not Modified. Le ré­sul­tat n’est tou­jours pas sa­tis­fai­sant. Nous au­rions at­tendu 1,3 se­condes pour sa­voir que notre ver­sion était tou­jours à jour. No­tez ce­pen­dant que, la plu­part du temps, Ty­pe­kit est très rapide.

Il au­rait été pré­fé­rable que Ty­pe­kit four­nisse une nou­velle URL à uti­li­ser lors de chaque mo­di­fi­ca­tion du kit (avec le nu­méro de ver­sion, par exemple). La po­li­tique de mise en cache de cette URL se­rait de plu­sieurs jours. Cette ap­proche per­met­trait aussi de pou­voir mo­di­fier le kit lors du dé­ve­lop­pe­ment sans af­fec­ter le site en pro­duction.

Je sus­pecte Ty­pe­kit d’avoir dé­li­bé­ré­ment choisi une mise en cache dé­fi­ciente pour pou­voir suivre l’uti­li­sa­tion de chaque kit et vé­ri­fier ainsi que le nombre de vi­si­teurs cor­res­pond bien à l’abon­ne­ment choisi.

Mise à jour (11.2011)

L’équipe de sup­port de Ty­pe­kit a iden­ti­fié le pro­blème et tra­vaille ac­tuel­le­ment dessus :

Vous avez iden­ti­fié un bug de notre four­nis­seur de CDN et nous tra­vaillons avec eux pour le cor­ri­ger. Heu­reu­se­ment, je peux vous ex­pli­quer ce qui se produit.

Les nœuds du CDN main­tiennent en cache les kits les plus ré­cem­ment de­man­dés. Les re­quêtes ser­vies de­puis le cache sont com­pres­sées cor­rec­te­ment. Mal­heu­reu­se­ment, si le kit n’est pas pré­sent dans le cache, il doit être ré­cu­péré de­puis les ser­veurs d’ori­gine et la com­pres­sion n’est pas réa­li­sée ce qui a pour ef­fet de bord de cas­ser le mé­ca­nisme ETag.

[…]

Nous tra­vaillons à cor­ri­ger ce bug mais un tel chan­ge­ment dans un CDN pren­dra un peu de temps. Nous tra­vaillons aussi à per­mettre une mise en cache de plus de 5 mi­nutes tout en per­met­tant aux uti­li­sa­teurs de mettre à jour ra­pi­de­ment leur site.

Mise à jour (03.2012)

Pour évi­ter un re­tard dans l’af­fi­chage de la page, no­tam­ment si Ty­pe­kit est lent, il est pos­sible de le char­ger de ma­nière asyn­chrone avec yepnope.js. En contre­par­tie, une autre po­lice sera uti­li­sée pen­dant quelques instants.

Conclusion#

Mon sen­ti­ment vis-à-vis de Ty­pe­kit est as­sez mi­tigé. Le pro­blème de mise en cache me semble plu­tôt ma­jeur et je ré­flé­chis à re­tour­ner vers Google Web Fonts pour cette unique rai­son. En de­hors de cet as­pect, les dé­fauts ci­tés me semblent re­la­ti­ve­ment mi­neurs par rap­port aux avan­tages apportés.