web-dev-qa-db-fra.com

Webfonts ou polices chargées localement?

Depuis les problèmes causés par l’utilisation de Cufon , j’ai décidé de ne pas utiliser de ressources de police de caractères externes, mais je me suis récemment mis à la recherche de méthodes de chargement alternatives. des polices pour voir s’il existe un meilleur moyen; les meilleures méthodes ont le moyen d'apparaître à l'improviste.

Il semble y avoir beaucoup de nouvelles méthodes et des variations pour chaque méthode; Devrais-je utiliser typekit ? ou google webfonts (avec js ou css)? dois-je continuer à utiliser les polices à chargement local (par exemple, la méthode générée par fontsquirrel.com)?

Je vais énumérer ci-dessous les méthodes qui semblent les plus bien reçues, avec quelques tests, mais vaut-il vraiment la peine de passer à un webfont? Il semble que cela entraînerait une charge de ressources plus importante (requêtes http) et moins de types de format de fichier (moins de compatibilité), etc. Mais on dirait que les fichiers sont chargés de manière asynchrone et efficacement dans la plupart des cas.

  1. Est-ce juste une question de situation et de besoin? Si c'est vrai, que sont-ils?
  2. Existe-t-il des différences drastiques entre ces méthodes?
  3. Existe-t-il une meilleure méthode que je n'ai pas énumérée?
  4. Quels sont les avantages/inconvénients de la performance? Regardez? dépendances? compatibilités?

Je suis vraiment à la recherche des meilleures pratiques, la performance est un facteur important, de même que l'évolutivité et la facilité d'utilisation. Sans parler, regarder et sentir.

Google CSS

  • utilise uniquement une feuille de style externe
  • utilise uniquement le plus petit type de fichier compatible
  • peut utiliser @import ou <link> ou prenez le contenu de la styleshee (@font-face) et mettez-le directement dans votre propre feuille de style.

résultats du test

  78ms load of html
  36ms load of css

enter image description here

méthode Google JS

  • les usages webfont.js pour charger styleshet
  • utilise uniquement le plus petit type de fichier compatible
  • ajoute :root élément avec classe
  • ajoute un script à la tête.

résultats du test

    171ms load of html
    176ms load of js
    32ms load of css

enter image description here

méthode Typekit

  • ajoute :root élément avec classe.
  • peut utiliser *.js extrait ou fichier chargé en externe *.js fichier
  • les usages data:font/opentype au lieu du fichier de police.
  • ajoute un script à la tête
  • ajoute des css intégrés à la tête

  • ajoute une feuille de style externe à la tête

    vous pouvez facilement ajouter/supprimer/ajuster des polices et des sélecteurs ciblés à partir de typekit.com

résultats du test

  169ms load of html
  213ms load of js
  31ms load of css
  3ms load of data:font/

enter image description here

… & la méthode Font Squirrel

@font-face{
    font-weight:400;
    font-style:normal;
    font-family:open_sanslight;
    src:url(../font/opensans-light-webfont.eot);
    src:url(../font/opensans-light-webfont.eot?#iefix) format(embedded-opentype),
        url(../font/opensans-light-webfont.woff) format(woff),
        url(../font/opensans-light-webfont.ttf) format(truetype),
        url(../font/opensans-light-webfont.svg#open_sanslight) format(svg)
}

… Ou avec des données: méthode de la police de caractères…

@font-face {
    font-family: 'open_sanslight';
    src: url('opensans-light-webfont-f.eot');
}

@font-face {
    font-family: 'open_sanslight';
    src: url(data:application/x-font-woff;charset=utf-8;base64,d09GRgABAAAAAF4sABMAAAAArXQAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABGRlRNAAABqAAAABwAAAAcZLn0KkqwK44Jq866WBSpzpsNY2IyGAhoJFBbYjuxmyns5sNa4NwldcJ7eh3Uy5gQkURIlqWzONe3HcLsDX1x/+jifDXvbzgTBjopZElndil3hJkERJkmRJkVRJk3TJkEzJkmzOc4HLXOEOF7nEX/*thisisnotafullencodingjustanexample*/bZwUnK4yS3JlTx2Sr4USKEUSbHVX9fcGNBs4fqgw+GoNHU7lKr36Eqn0lCWt6pHFpWaUlc6lS6loSxRlirLlP/uuU01dVfT7L6gPxyqraluCpgj3WtqeC1V4VBDW2N4K1r1esw/IupKp9L1FwlqnuIAAAB42j3NvQ7BUBjG8R5tTz/0u2UjNTTESYQbMGmXLiISbeI6zBYjbuWtye7CeMJxtuf3LP8ne1+IXbWa7G3TMXZru4qLZkJRW1O2wzi3I+Li2Gik5yXpYkNGXj70YU98YQLGHxwwXxIWwO8SNmAdJBzAXku4gFNI9AF38QMjTwZ9vN6yJzq9OoEB6I8VQzDYK0ZguFKMwWiumIDxTDEFk6liBqaF4gDMFFvKxAfOxFUGAAABUxSL9gAA) format('woff'),
         url('opensans-light-webfont-f.ttf') format('truetype'),
         url('opensans-light-webfont-f.svg#open_sanslight') format('svg');
    font-weight: normal;
    font-style: normal;

}
javascriptcssfontswebfonts
93
darcher

Tout d'abord, je vais clarifier quelque chose sur l'offre de Google. Il chargera le plus petit format que votre navigateur peut gérer. WOFF propose des fichiers de petite taille et votre navigateur le prend en charge. C'est donc celui que vous voyez. WOFF est également assez largement soutenu. Cependant, dans Opera par exemple, vous obtiendrez probablement la version TrueType de la police.

Je pense que la logique de la taille des fichiers explique également pourquoi Font Squirrel les tente dans cet ordre. Mais ce sont surtout des spéculations de ma part.

Si vous travaillez dans un environnement où chaque demande et chaque octet compte, vous devrez effectuer un profilage pour déterminer celle qui convient le mieux à votre cas d'utilisation. Est-ce que les gens ne verront qu'une page et ne reviendront jamais? Si c'est le cas, les règles de mise en cache importent moins. S'ils consultent ou reviennent, Google pourrait appliquer de meilleures règles de mise en cache que votre serveur. La latence est-elle le problème majeur, ou la bande passante? En cas de latence, visez moins de demandes, alors hébergez-le localement et combinez les fichiers autant que possible. Si bande passante, choisissez l'option qui se termine avec le plus petit code et le plus petit format de police.

Passons maintenant à la considération CSS vs JS. Regardons le morceau de HTML suivant:

<head>
    <script type="text/javascript" src="script1.js"></script>
    <link rel="stylesheet" type="text/css" href="style1.css" />
    <style type="text/css">
        @import url(style2.css);
    </style>
    <script type="text/javascript">
        (function() {
            var wf = document.createElement('script');
            wf.src = 'script2.js';
            wf.type = 'text/javascript';
            wf.async = 'true';
            var s = document.getElementsByTagName('script')[0];
            s.parentNode.insertBefore(wf, s);
        })();
    </script>
</head>

Dans de nombreux cas, script1, style1, et style2 serait bloquant. Cela signifie que le navigateur ne peut pas continuer à afficher le document tant que cette ressource n'est pas chargée (bien que les navigateurs modernes falsifient un peu cela). Ce qui peut en fait être une bonne chose, surtout avec les feuilles de style. Cela évite les éclats de contenu non-stylé, ainsi que le décalage important qui se produirait lors de l'application des styles (et le changement de contenu est vraiment ennuyant pour un utilisateur).

D'autre part, script2 ne serait pas bloquant. Il peut être chargé plus tard et le navigateur peut ensuite analyser et afficher le reste du document. Cela peut donc être bénéfique aussi.

En ce qui concerne plus particulièrement les polices (et plus particulièrement l'offre de Google), je préférerais probablement utiliser une méthode CSS (j'aime bien @import _ parce qu'il continue à styler avec la feuille de style, mais cela pourrait n'être que moi). Le fichier JS chargé par le script ( http://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js ) est plus volumineux que le @font-face déclaration et juste ressemble à beaucoup plus de travail. Et je ne crois pas que le chargement de la police elle-même (le WOFF ou le TTF) bloque, il ne faut donc pas trop retarder les choses. Personnellement, je ne suis pas un grand fan des CDN, mais le fait est qu'ils sont vraiment rapides. Les serveurs de Google vont battre d'un glissement de terrain la plupart des packs d'hébergement partagés, et comme leurs polices sont si populaires, les gens pourraient même les avoir déjà mis en cache.

Et c'est tout ce que j'ai.

Je n'ai aucune expérience de Typekit, je l'ai donc laissée en dehors de ma théorie. S'il y a des inexactitudes, sans compter les généralisations entre navigateurs à des fins d'arguments, veuillez les indiquer.

31
ZachRabbit

Je pense que vous avez très bien abordé les temps de chargement dans votre question. De mon point de vue, quelques sources devraient être ajoutées à la liste, ainsi que quelques autres considérations à examiner pour obtenir une vue complète des options.

Quelques autres sources de polices réputées

nuage.typographie

http://www.typography.com/cloud/

D'après ce que je peux dire, les polices sont incorporées sous forme de données dans un fichier CSS:

@font-face{ 
    font-family: "Font Name"; 
    src: url(data:application/x-font-woff;base64,d09GRk9UVE8AACSCAA0AAAAARKwAAQAAAAAiVAAAAi4AAAadAAAAAAAAAABDRkYgAAAIyAAAFCgAABmIK5m+CkdERUYAABzwAAAAHQAAACAAXQAER1BPUwAAHRAAAAQlAAAYAq+OkMNHU1VC ... ); 
    font-weight:400; font-style:normal; 
}

Voici mes spécifications:

94ms load of css from their server
37ms load of css from our server (will vary based on your configuration)
195ms load of data:fonts from our server (will vary based on your configuration)

Voici leur description de très haut niveau de leur déploiement .

Fonts.com

Je n'ai pas utilisé ce service, mais il s'agit d'un fournisseur de polices bien établi very, et les informations qu'ils ont répertoriées sur leur site sont assez impressionnantes. Je n'ai pas de spécifications sur leurs méthodes exactes, mais voici ce que je sais qu'ils ont:

  • Certaines des polices les plus connues au monde
  • Une très grande bibliothèque de polices (plus de 20 000)
  • Téléchargements de polices de bureau pour créer des maquettes
  • Un outil personnalisé pour tester les polices Web dans le navigateur
  • Contrôles typographiques fins et sous-ensembles
  • Options d'auto-hébergement

FontSpring

Affilié à FontSquirrel. Les polices peuvent être achetées ici pour un prix fixe. Les fichiers de polices accompagnant un fichier CSS sont livrés et doivent être déployés sur votre propre serveur, un peu comme FontSquirrel.

Spécifications étendues

En ce qui concerne les avantages et les inconvénients de chaque service de polices, voici quelques comparaisons:

Taille de la bibliothèque de polices

  • Fonts.com : 20 000+
  • FontSpring : plus de 1000
  • FontSquirrel : 300+
  • Google : 600+
  • Typekit : 900+
  • Typography.com (cloud.typography.com): probablement plus de 300 (35 familles)

Prix

  • Fonts.com : 20 $/mois pour 500 000 pages vues
  • FontSpring : Varie selon les polices (achat unique de polices)
  • FontSquirrel : Gratuit
  • Google : Gratuit
  • Typekit : 4 $/mois pour 500 000 pages vues
  • Typography.com : 12,50 $/mois pour 1 000 000 de pages vues

Qualité de la police

La qualité des polices Web peut varier un peu. Cela peut englober des éléments tels que les formes de lettre elles-mêmes, l'espacement ou la taille du jeu de caractères. Tous ces éléments déterminent l'impression générale de qualité qu'une police donnera. Bien que les options gratuites offrent de bonnes options, certaines polices ne sont pas aussi de haute qualité. Vous devez donc choisir avec soin parmi ces sources.

  • Fonts.com : élevé
  • FontSpring : mélangé à élevé
  • FontSquirrel : Mixte
  • Google : Mixte
  • Typekit : Élevé
  • Typography.com : Très élevé (je l’appelle "très élevé", car Fonts.com, FontSpring et Typekit prennent en charge plusieurs types de fonderies, où sont uniquement des polices de la fonderie H & FJ, qui est parmi les meilleures au monde)

Qualité de police II: Typographie

Il y a beaucoup de raffinements dans la typographie de bureau qui ont été très difficiles à obtenir dans les polices Web. Certains de ces services offrent des moyens de les fournir.

  • Fonts.com : crénage, espacement des lettres, ligatures, autres caractères, fractions, etc.
  • FontSpring : Aucun
  • FontSquirrel : Aucun
  • Google : Aucun
  • Typekit : Aucun
  • Typography.com : petites majuscules, ligatures, autres caractères, styles de numéros alternatifs, fractions, etc.

Support du navigateur

Cela concerne principalement les formats de polices pris en charge par chaque service. Les principaux sont:

  • EOT: pour Internet Explorer (IE 4+)
  • TrueType et OpenType: formats traditionnels (Safari 3.1+, FF 3.5+, Opera 10+)
  • WOFF: Nouvelle norme pour les polices Web (FF 3.6+, Chrome 5+)
  • SVG: IOS <4.2

Plus d'informations sur La règle @ Font-Face et les astuces utiles sur les polices Web

Tous ces services prennent en charge les principaux formats de police. Avec les polices auto-hébergées, tant que vous utilisez la bonne syntaxe, vous devriez être couvert. Voici une mise à jour 2011 de la syntaxe bulletproof de FontSpring :

@font-face {
  font-family: 'MyWebFont';
  src: url('webfont.eot'); /* IE9 Compat Modes */
  src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('webfont.woff') format('woff'), /* Modern Browsers */
       url('webfont.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
  }

Performance I: Téléchargements

Autant que je sache, utiliser la syntaxe ci-dessus permet aux navigateurs de saisir le format spécifique qui leur convient. Il n'y a donc pas de téléchargements inutiles de formats de polices qui ne fonctionnent pas.

Les services payants tels que Fonts.com, Typekit ou Typography.com utilisent des méthodes pour détecter le format correct et alors fournissent le bon format de police, souvent sous la forme de données base64 dans un fichier CSS.

D'après ce que je peux voir, les différences entre les méthodes que vous avez énumérées ci-dessus sont assez négligeables pour les utilisateurs d'internet à haut débit (une différence <200 ms), mais pourraient être utiles pour les appareils sur des réseaux plus lents, en particulier pour les hits de page non mis en cache.

Performance II: Subsetting

Si vous savez que vous ne souhaitez utiliser que certains caractères, vous pouvez construire votre police avec un sous-ensemble de caractères et réduire ainsi la taille du téléchargement.

  • Fonts.com : Contrôle très détaillé
  • FontSpring : peut recompiler un sous-ensemble via générateur de police de caractères FontSquirrel
  • FontSquirrel : Peut recompiler en tant que sous-ensemble via générateur de webfont
  • Google : Contrôle très détaillé
  • Typekit : options limitées de "tous les caractères" ou "par défaut"
  • Typography.com : Contrôle très détaillé

Performance III: Livraison

  • Fonts.com : CDN global ou votre propre serveur
  • FontSpring : Basé sur votre serveur
  • FontSquirrel : basé sur votre serveur
  • Google : super-CDN global
  • Typekit : CDN global
  • Typography.com : CDN global (125 000 serveurs)

Support linguistique

  • Fonts.com : 40 langues, dont l’Asie et le Moyen-Orient
  • FontSpring : Western, en fonction de la police
  • FontSquirrel : Western, en fonction de la police
  • Google : Western, en fonction de la police
  • Typekit : Western, en fonction de la police
  • Typography.com : Western, en fonction de la police

Test et mise en oeuvre

  • Fonts.com : très simple, avec des outils complets et personnalisables
  • FontSpring : Technique (faites le vous-même)
  • FontSquirrel : Technique (faites le vous-même)
  • Google : facile
  • Typekit : facile
  • Typography.com : tests faciles, un peu plus compliqué à changer une fois déployé
11
nwalton

Eh bien, comme vous êtes après

... en recherchant les meilleures pratiques, la performance est un facteur important, mais l’évolutivité et la facilité d’utilisation le sont également. Sans parler, regarder et sentir.

la réponse est (comme toujours dans la conception web): Cela dépend!

Une chose est sûre, c'est que je ne recommanderais pas d'utiliser l'approche JS (montrée dans votre deuxième exemple).

Personnellement, je n'aime pas créer des présentations et des styles CSS en fonction de Javascript, même si la grande majorité des utilisateurs l’a activé. C'est une question de ne pas mélanger les choses.

Et comme vous pouvez le voir dans votre exemple, il existe une sorte de FOUC (flas de contenu non stylé), car la page est déjà affichée par le navigateur avant que la police ne soit disponible. Dès que c'est, la page est redessinée. Et plus le site est grand, plus l'impact (sur les performances) est important!

Je n’utiliserai donc jamais de solution JS pour l’intégration de polices.

Voyons maintenant les méthodes CSS pures.
Depuis un certain temps, voici une discussion sur "vs @import". Personnellement, je préfère éviter d'utiliser @import et utiliser toujours <link> seulement. Mais c’est surtout une question de préférences personnelles. La seule chose que vous ne devriez jamais faire est de mélanger les deux!

Local vs CDN
Lorsque vous décidez d'héberger vos fichiers de polices localement ou d'utiliser un CDN, cela dépend principalement du nombre de polices différentes et des polices respectives que vous souhaitez intégrer.

Pourquoi est-ce important ou joue un rôle?
Du point de vue des performances, je recommanderais d’inclure la police Base64 codée dans votre (une) feuille de style. Mais seul le format .woff, utilisé par presque tous les navigateurs modernes, ce qui signifie pour la majorité de vos visiteurs. Pour tous les autres utilisateurs vivent avec la demande supplémentaire.

Mais en raison de la "surcharge" causée par l'encodage Base64 et la taille d'un fichier de polices (même au format .woff), cette technique ne doit être utilisée que si vous n'avez pas plus de 3 ou 4 polices différentes. Et assurez-vous toujours que votre serveur fournit les fichiers (CSS) gzipés.

Le gros avantage de cette solution est que vous n’avez pas de demande supplémentaire pour le fichier de police. Et après le chargement de la première page (quelle que soit la page de votre site), le fichier CSS est mis en cache. C'est également un avantage si vous utilisez le cache d'application HTML5 (ce que vous ferez certainement).

Outre le fait qu'un auteur ne devrait pas utiliser plus de 3 ou 4 polices différentes sur son site, examinons la méthode d'utilisation du CDN de Google.

Tout d’abord, sachez que vous pouvez (et devriez toujours) inclure toutes les polices souhaitées dans un seul <link>, ainsi:

<link href='http://fonts.googleapis.com/css?family=PT+Serif:400,700,400italic,700italic|PT+Sans:400,700,400italic,700italic|Montez' rel='stylesheet' type='text/css'>

Cela entraînera la réponse suivante:

@font-face {
  font-family: 'Montez';
  font-style: normal;
  font-weight: 400;
  src: local('Montez'), local('Montez-Regular'), url(http://themes.googleusercontent.com/static/fonts/montez/v4/Zfcl-OLECD6-4EcdWMp-Tw.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-weight: 400;
  src: local('PT Sans'), local('PTSans-Regular'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/LKf8nhXsWg5ybwEGXk8UBQ.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-weight: 700;
  src: local('PT Sans Bold'), local('PTSans-Bold'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/0XxGQsSc1g4rdRdjJKZrNBsxEYwM7FgeyaSgU71cLG0.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: italic;
  font-weight: 400;
  src: local('PT Sans Italic'), local('PTSans-Italic'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/PIPMHY90P7jtyjpXuZ2cLD8E0i7KZn-EPnyo3HZu7kw.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: italic;
  font-weight: 700;
  src: local('PT Sans Bold Italic'), local('PTSans-BoldItalic'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/lILlYDvubYemzYzN7GbLkHhCUOGz7vYGh680lGh-uXM.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: normal;
  font-weight: 400;
  src: local('PT Serif'), local('PTSerif-Regular'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/sDRi4fY9bOiJUbgq53yZCfesZW2xOQ-xsNqO47m55DA.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: normal;
  font-weight: 700;
  src: local('PT Serif Bold'), local('PTSerif-Bold'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/QABk9IxT-LFTJ_dQzv7xpIbN6UDyHWBl620a-IRfuBk.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: italic;
  font-weight: 400;
  src: local('PT Serif Italic'), local('PTSerif-Italic'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/03aPdn7fFF3H6ngCgAlQzBsxEYwM7FgeyaSgU71cLG0.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: italic;
  font-weight: 700;
  src: local('PT Serif Bold Italic'), local('PTSerif-BoldItalic'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/Foydq9xJp--nfYIx2TBz9QFhaRv2pGgT5Kf0An0s4MM.woff) format('woff');
}

Comme vous pouvez le constater, il y a 9 fichiers de polices différents, ce qui signifie un total de 10 demandes (y compris celle de l'élément link) si l'utilisateur ne dispose pas d'une ou de plusieurs des polices demandées installées localement. Et ces demandes sont répétées à chaque nouvelle demande de page sur votre site (bien qu'aucune donnée ne soit transférée)! Également la réponse à la demande du <link> n'est jamais mis en cache.

Recommandation:
Après tout, je recommanderais vraiment d’inclure vos fichiers de polices au format .woff Base64 encodé dans votre feuille de style!

Voir cet article de Nice pour un exemple et une description de la marche à suivre!

10
Netsurfer

J'utilise la méthode CSS en ligne, car la surcharge de la demande supplémentaire est supérieure à l'augmentation de la taille lors du codage bease64. Ceci est également compensé par la compression gizip par le serveur des fichiers css.

Une autre option consiste à utiliser le chargement asynchrone des polices, mais le plus souvent, les utilisateurs verront les polices apparaître après le chargement.

Quelle que soit la méthode utilisée, vous pouvez réduire la taille du fichier de police en n'incluant que les jeux de caractères que vous utiliserez.

3
Chris Gunawardena

La meilleure option consiste à importer les polices en utilisant ajax, comme ceci:

<script>
    (function() {
        var font = document.createElement('link'); 
        font.type = 'text/css'; 
        font.rel = 'stylesheet';
        font.href = '/url/to/font.css';
        var s = document.getElementsByTagName('link')[0]; 
        s.parentNode.insertBefore(font, s);
      })();
</script>

Je le fais sur ma page Web et j'augmente de 9 points le test de Google Insights.

1
Phok7

Personnellement, j'utilise Google Fonts. Ils ont une belle variété de choix et ils ont récemment amélioration de la compression des polices en passant à la compression Zopfli aussi. Google s'efforce de rendre le Web plus rapide, donc j'imagine que cette optimisation va également venir de cette partie.

Quel que soit votre choix en tant que livraison de polices externalisée, vous obtiendrez toujours des gains de rapidité grâce aux demandes d'obtention des polices. La meilleure chose à faire, du point de vue de la vitesse, serait de servir vous-même les polices. Si vous ne vous souciez pas de ces millisecondes supplémentaires nécessaires au chargement d'une livraison sous-traitée, choisissez-le si vous pensez que leur facilité d'utilisation vaut la peine de les millisecondes.

Je ne connais pas Typekit ni les autres, mais avec Google Fonts, vous pouvez choisir de vous servir des sous-ensembles spécifiques et une gamme de caractères pour accélérer encore davantage la diffusion.

Choix d'un sous-ensemble: 

<link href="http://fonts.googleapis.com/css?family=Open+Sans&subset=latin" rel="stylesheet">

Choix d'une plage de caractères: 

<!-- Only serve H,W,e,l,o,r and d -->
<link href="http://fonts.googleapis.com/css?family=Open+Sans&text=HelloWorld" rel="stylesheet">

Vous pouvez utiliser dns-prefetch pour améliorer encore plus la vitesse avec la livraison des polices.

Je pense et espère que Google mettra tout en œuvre pour accélérer au maximum la livraison des polices. Les millisecondes qu'il faut pour les charger ne font pas mal à mon site Web, alors je les utilise avec plaisir.

Longue histoire courte:

Si la livraison des polices en millisecondes nuit à votre site, par exemple en le chargeant plus de 1 seconde de charge, je pense que vous devriez l'héberger vous-même.

1
Jeremy Karlsson