96 votes

Polices Web ou polices chargées localement ?

Depuis les problèmes causés par l'utilisation Cufon J'ai renoncé à utiliser des ressources de polices externes, mais dernièrement, j'ai cherché d'autres méthodes de chargement des polices pour voir s'il n'y avait pas une meilleure façon de faire ; les meilleures méthodes ont une façon de surgir de nulle part.

Il y a beaucoup de nouvelles méthodes et des variantes pour chacune d'entre elles, semble-t-il. kit d'encodage ? ou polices de caractères google (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 mieux accueillies, avec quelques tests, mais cela vaut-il vraiment la peine de passer à une police Web ? Il semble qu'il y aurait une plus grande charge de ressources (requêtes http) et moins de types de formats de fichiers (moins de compatibilité), etc. Mais il semble que les fichiers soient chargés de manière asynchrone et efficace dans la plupart des cas.

  1. Est-ce simplement une question de situation et de besoin ? Si oui, quels sont-ils ?
  2. Y a-t-il des différences radicales entre ces méthodes ?
  3. Existe-t-il une meilleure méthode que je n'ai pas mentionnée ?
  4. Quels sont les avantages et les inconvénients de la performance ? L'aspect ? les dépendances ? les compatibilités ?

Je suis vraiment à la recherche des meilleures pratiques. Les performances sont un élément important, mais aussi l'évolutivité et la facilité d'utilisation. Sans oublier l'aspect et la convivialité.

J'ai supprimé le code de la question pour faciliter la lecture, le code peut être vu sur les pages de test fournies.


Google CSS

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

URL de la page de test : http://leftdeaf.com/so/gwebfontcss.html

résultats des tests

  78ms load of html
  36ms load of css

enter image description here


Méthode Google JS

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

URL de la page de test : http://leftdeaf.com/so/gwebfontjs.html

résultats des tests

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

enter image description here


Méthode Typekit

  • ajoute :root avec la classe.
  • peut utiliser *.js extrait ou fichier chargé en externe *.js fichier
  • utilise data:font/opentype au lieu du fichier de police.
  • ajoute script à l'en-tête
  • ajoute le css intégré à l'en-tête
  • ajoute une feuille de style externe à l'en-tête

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

URL de la page de test : http://leftdeaf.com/so/typekitjs.html

résultats des tests

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

enter image description here


& la méthode de l'écureuil de police

@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 la méthode data:font

@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;

}

test à venir

33voto

ZachRabbit Points 2210

Tout d'abord, je vais clarifier un point concernant l'offre de Google. Elle charge en fait le plus petit format que votre navigateur peut gérer. WOFF offre des fichiers de petite taille, et votre navigateur le prend en charge, c'est donc celui que vous voyez. Le WOFF est également assez largement pris en charge. Toutefois, dans Opera par exemple, vous obtiendrez probablement la version TrueType de la police.

La logique de la taille du fichier est aussi, je crois, la raison pour laquelle Font Squirrel les essaie dans cet ordre. Mais c'est surtout une spéculation de ma part.

Si vous travaillez dans un environnement où chaque requête et chaque octet comptent, vous devrez procéder à un profilage pour déterminer ce qui convient le mieux à votre cas d'utilisation. Les utilisateurs ne consulteront-ils qu'une seule page et ne reviendront-ils jamais ? Dans ce cas, les règles de mise en cache n'ont pas une grande importance. S'ils naviguent ou reviennent sur le site, Google a peut-être de meilleures règles de mise en cache que votre serveur. Le problème le plus important est-il la latence ou la bande passante ? Si le problème est la latence, cherchez à réduire le nombre de requêtes, hébergez le site localement et combinez les fichiers autant que possible. Pour ce qui est de la bande passante, choisissez l'option qui offre le plus petit code et le plus petit format de police.

Passons maintenant à la question des CSS et des JS. Examinons 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 y 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 s'arrangent un peu avec cela). Ce qui peut en fait être une bonne chose, surtout avec les feuilles de style. Cela permet d'éviter un flash de contenu non stylisé, ainsi que le décalage géant qui se produirait lors de l'application des styles (et le décalage du contenu est vraiment ennuyeux pour l'utilisateur).

D'un autre côté, script2 ne serait pas bloquant. Il peut être chargé plus tard, et le navigateur peut passer à l'analyse et à l'affichage du reste du document. Cela peut donc aussi être bénéfique.

Pour ce qui est des polices de caractères (et plus particulièrement de l'offre de Google), je m'en tiendrais probablement à une méthode CSS (j'aime bien @import parce qu'il garde le style avec la feuille de style, mais cela pourrait être juste moi). Le fichier JS chargé par le script ( http://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js ) est plus grande que la @font-face déclaration, et juste regarde comme beaucoup plus de travail. Et je ne pense pas que le chargement de la police elle-même (le WOFF ou le TTF) soit bloquant, donc cela ne devrait pas trop retarder les choses. Je ne suis pas personnellement un grand fan des CDN, mais le fait est qu'ils sont VRAIMENT rapides. Les serveurs de Google sont bien plus rapides que la plupart des plans d'hébergement mutualisé, et comme leurs polices sont très populaires, les gens peuvent même les avoir déjà mises en cache.

Et c'est tout ce que j'ai.

Je n'ai aucune expérience avec Typekit, donc je l'ai laissé en dehors de mes théories. S'il y a des inexactitudes, sans compter les généralisations entre navigateurs pour le plaisir de la discussion, merci de les signaler.

11voto

nwalton Points 921

Je pense que vous avez très bien abordé la question des temps de chargement dans votre question. De mon point de vue, il y a quelques sources qui devraient être ajoutées à la liste, et quelques autres considérations qui devraient être examinées pour avoir une vue complète des options.


Quelques autres sources de polices réputées

typographie.des.nuages

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

D'après ce que je sais, les polices sont intégrées comme 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 la description de très haut niveau de leur déploiement .

Fonts.com

Je n'ai pas utilisé ce service, mais c'est un très et les informations qu'ils ont listé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 :

  • Quelques-unes des polices les plus connues dans le monde disponibles
  • Une très grande bibliothèque de polices (plus de 20 000)
  • Téléchargement de polices de bureau pour la réalisation de maquettes
  • Un outil personnalisé pour tester les polices web dans le navigateur
  • Contrôles et sous-ensembles de la typographie fine
  • Options d'auto-hébergement

FontSpring

Affilié à FontSquirrel. Les fontes peuvent être achetées ici à un prix fixe. Les fichiers de police et les CSS qui les accompagnent sont livrés, pour être déployés sur votre propre serveur, tout comme FontSquirrel.


Spécifications étendues

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

Taille de la bibliothèque de polices

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

Fixation des prix

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

Qualité de la police

La qualité des polices Web peut varier considérablement. Elle peut englober des éléments tels que les formes de lettres 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é que donne une police. Si les options gratuites offrent de bonnes possibilités, certaines polices ne sont pas d'aussi bonne qualité. Il convient donc de choisir avec soin parmi ces sources.

  • Fonts.com : Haut
  • FontSpring : Mixte à élevé
  • FontSquirrel : Mixte
  • Google : Mixte
  • Typekit : Haut
  • Typographie.com : Très élevé (je donne la mention " très élevé " parce que Fonts.com, FontSpring et Typekit prennent en charge plusieurs fonderies de caractères, alors qu'il s'agit uniquement de polices provenant de la fonderie H&FJ, qui est parmi les meilleures au monde).

Qualité des polices II : Typographie

Il y a beaucoup de raffinements dans la typographie de bureau qui ont été vraiment difficiles à obtenir dans les polices web. Certains de ces services offrent des moyens d'y parvenir.

  • Fonts.com : crénage, espacement des lettres, ligatures, caractères alternatifs, fractions, etc.
  • FontSpring : Aucun
  • FontSquirrel : Aucun
  • Google : Aucun
  • Typekit : Aucun
  • Typographie.com : petites capitales, ligatures, caractères alternatifs, styles de chiffres alternatifs, fractions, etc.

Support des navigateurs

Cela dépend essentiellement des formats de police pris en charge par chaque service. Les principaux sont les suivants :

  • 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 des astuces utiles sur les polices de caractères pour le Web

Tous ces services prennent en charge les principaux formats de polices. Avec les polices hébergées par vos soins, tant que vous utilisez la bonne syntaxe, vous devriez être couvert. Voici une mise à jour de 2011 de la syntaxe infaillible 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

D'après ce que j'ai compris, l'utilisation de la syntaxe ci-dessus permet aux navigateurs de récupérer le format spécifique qui leur convient, ce qui évite de gaspiller des téléchargements sur des formats de police qui ne fonctionnent pas.

Les services payants comme Fonts.com, Typekit ou Typography.com utilisent des méthodes pour détecter le format correct et puis fournir le bon format de police, souvent sous 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 (il semble que la différence soit de <200ms), mais il pourrait être intéressant de les prendre en considération pour les appareils sur des réseaux plus lents, en particulier pour les occurrences de pages non mises en cache.

Performance II : Sous-ensemble

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 en tant que sous-ensemble via Générateur de polices web FontSquirrel
  • FontSquirrel : Peut recompiler en tant que sous-ensemble via générateur de police Web
  • Google : Contrôle très détaillé
  • Typekit : options limitées à "tous les caractères" ou "par défaut".
  • Typographie.com : Contrôle très détaillé

Performance III : Livraison

  • Fonts.com : CDN global ou votre propre serveur
  • FontSpring : En fonction de votre serveur
  • FontSquirrel : En fonction de votre serveur
  • Google : Super-RNC mondial
  • Typekit : CDN global
  • Typographie.com : CDN mondial (125 000 serveurs)

Soutien linguistique

  • Fonts.com : 40 langues, dont des langues asiatiques et du Moyen-Orient
  • FontSpring : Occidental, selon la police
  • FontSquirrel : Occidental, selon la police
  • Google : Occidental, selon la police
  • Typekit : Occidental, selon la police
  • Typographie.com : Occidental, selon la police

Test et mise en œuvre

  • Fonts.com : Très facile, avec des outils étendus et personnalisables
  • FontSpring : Technique (à faire soi-même)
  • FontSquirrel : Technique (à faire soi-même)
  • Google : Facile
  • Typekit : Facile
  • Typographie.com : Test facile, un peu plus compliqué à modifier une fois déployé.

10voto

Netsurfer Points 2947

Eh bien, comme vous êtes après

... à la recherche des meilleures pratiques, les performances sont un facteur important, mais aussi l'évolutivité et la facilité d'utilisation. Sans oublier l'aspect et la convivialité.

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

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

Personnellement, je n'aime pas faire dépendre les éléments de présentation et les styles CSS de Javascript, même si la grande majorité des utilisateurs l'ont activé. Il s'agit de ne pas mélanger les choses.

Et comme vous pouvez le constater dans votre exemple, il y a une sorte de FOUC (flas of unstyled content), car la page est déjà rendue par le navigateur avant que la police ne soit disponible. Dès qu'elle l'est, la page est redessinée. Et plus le site est grand, plus l'impact (sur les performances) est important !

Je n'utiliserais donc jamais une solution JS pour l'intégration des polices.

Voyons maintenant les méthodes CSS pures.
Depuis un certain temps, il y a une discussion sur " vs. @import ". Personnellement, je préfère éviter l'utilisation de @import et toujours utiliser <link> seulement. Mais c'est surtout une question de préférences personnelles. La seule chose à ne jamais faire en effet est de mélanger les deux !

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

Pourquoi cela est-il important, ou joue-t-il un rôle ?
Du point de vue des performances, je recommanderais d'inclure la police encodée en base64 dans votre (unique) feuille de style. Mais seulement le format .woff, car il est utilisé par presque tous les navigateurs modernes, ce qui signifie pour la majorité de vos visiteurs. Pour tous les autres utilisateurs, vivez avec la demande supplémentaire.

Mais en raison de l'encombrement causé par l'encodage Base64 et de la taille d'un fichier de police (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 livre les fichiers (CSS) gzip'ed.

Le gros avantage de cette méthode est que vous n'avez pas de demande supplémentaire pour le fichier de police. Et après le premier chargement de la 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 de l'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 devez) inclure toutes les polices souhaitées dans un seul et même fichier. <link> comme ça :

<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'>

Il en résultera 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 voir, il y a 9 fichiers de polices différents, ce qui signifie un total de 10 (y compris celui de l'élément lien) demandes, si l'utilisateur n'a pas une ou 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) ! De même, la réponse à la demande de l'élément <link> n'est jamais mis en cache.

Recommandation :
Après tout, je vous recommande vraiment d'inclure votre/vos fichier(s) de polices au format .woff encodé Base64 dans votre feuille de style !

Voir ce bel article pour un exemple et une description de la manière de procéder !

3voto

Chris Gunawardena Points 1179

J'utilise la méthode des css en ligne parce que la surcharge de la demande supplémentaire est plus importante que l'augmentation de la taille lors de l'encodage bease64. Ceci est également compensé par la compression gizip des fichiers css par le serveur.

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.

1voto

Jeremy Karlsson Points 333

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 je suppose qu'ils vont également optimiser davantage cette partie.

Quel que soit votre choix en matière de livraison externalisée de polices, vous obtiendrez toujours des réductions de vitesse par les demandes d'obtention des polices. La meilleure chose à faire, du point de vue de la vitesse, serait de servir les polices vous-même. Si vous ne tenez pas compte des millisecondes supplémentaires nécessaires au chargement à partir d'une livraison externalisée, vous pouvez opter pour cette solution si vous pensez que la facilité d'utilisation vaut ces millisecondes.

Je ne sais pas ce qu'il en est de Typekit et des autres, mais avec Google Fonts, vous pouvez choisir de recevoir des sous-ensembles et des gammes de caractères spécifiques pour accélérer encore plus la livraison.

Choisir un sous-ensemble :

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

Choisir un éventail de personnages :

<!-- 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 d'améliorer encore les vitesses avec la livraison de polices.

Je pense et j'espère que Google fera tout ce qui est en son pouvoir pour accélérer au maximum la livraison des polices. Les millisecondes qu'il faut pour les charger ne nuisent pas à mon site Web, et je les utilise donc avec plaisir.

Pour faire court :

Si les millisecondes que prend la livraison des polices nuisent à votre site, par exemple en le faisant charger plus que la seconde recommandée, je pense que vous devriez les héberger vous-même.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X