Desde los problemas provocados por el uso de Cufon, me aventuré a dejar de usar recursos de fuentes externos, pero últimamente, he estado buscando métodos alternativos para cargar fuentes para ver si hay una mejor manera; mejores métodos tienen una forma de aparecer de la nada.
Hay muchos métodos nuevos por ahí, y parece que hay variaciones para cada método; ¿Debería usar typekit ? o google webfonts (con js o css)? ¿Debo seguir usando fuentes de carga local (por ejemplo, método generado por fontsquirrel.com)?
A continuación, enumeraré los métodos que parecen ser los más bien recibidos, con algunas pruebas, pero ¿realmente vale la pena pasar a una fuente web? Parece que llevaría una mayor carga de recursos (solicitudes http) y tendría menos tipos de formato de archivo (menos compatibilidad), etc. Pero parece que los archivos se cargan de forma asincrónica y eficiente en la mayoría de los casos.
- ¿Es solo una cuestión de situación y necesidad? Si es así, ¿Que son?
- ¿Existen diferencias drásticas entre estos métodos?
- ¿Existe un método mejor que no haya enumerado?
- ¿Cuáles son los pros y los contras del rendimiento? ¿Mira? dependencias? compatibilidades?
Realmente estoy buscando las mejores prácticas aquí, el rendimiento es una gran cosa, pero también lo es la escalabilidad y la facilidad de uso. Sin mencionar el aspecto y la sensación.
CSS de Google
- solo usa hoja de estilo externa
- solo usa el tipo de archivo compatible más pequeño
- puede usar
@importo<link>tomar el contenido de styleshee (@font-face) y ponerlo directamente en su propia hoja de estilo.
resultados de la prueba
78ms load of html 36ms load of css
Método JS de Google
- utiliza
webfont.jspara cargar styleshet - solo usa el tipo de archivo compatible más pequeño
- agrega
:rootelemento con clase - agrega guión a la cabeza.
resultados de la prueba
171ms load of html 176ms load of js 32ms load of css
Método Typekit
- agrega el
:rootelemento con la clase. - puede usar un
*.jsfragmento o un archivo de*.jsarchivo cargado externamente - utiliza en
data:font/opentypelugar de archivo de fuente. - agrega guión a la cabeza
- agrega CSS incrustado a la cabeza
agrega una hoja de estilo externa al encabezado
puede agregar / eliminar / ajustar fácilmente fuentes y selectores de destino de typekit.com
resultados de la prueba
169ms load of html 213ms load of js 31ms load of css 3ms load of data:font/
… Y el método 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)
}... o con datos: método de fuente ...
@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;
}fuente
<link href='http://fonts.googleapis.com/css?family=Open+Sans:300' rel='stylesheet'>Georgian. Estoy usando el método font-squirrel y también me gustaría ver una gran respuesta a esta pregunta.@font-facedeclaraciones a prueba de balas , tal vez pueda encontrar información útil. paulirish.com/2009/bulletproof-font-face-implementation-syntaxRespuestas:
Primero, aclararé algo sobre la oferta de Google. De hecho, cargará el formato más pequeño que pueda manejar su navegador. WOFF ofrece archivos de tamaño pequeño y su navegador lo admite, por lo que es el que ve. WOFF también cuenta con un apoyo bastante amplio. Sin embargo, en Opera, por ejemplo, probablemente obtendrá la versión TrueType de la fuente.
La lógica del tamaño del archivo también es, creo, la razón por la que Font Squirrel los prueba en ese orden. Pero eso es principalmente especulación de mi parte.
Si está trabajando en un entorno en el que cada solicitud y cada byte cuenta, tendrá que crear un perfil para descubrir cuál funciona mejor para su caso de uso. ¿La gente solo verá una página y nunca volverá a visitarla? Si es así, las reglas de almacenamiento en caché no importan tanto. Si están navegando o regresando, Google podría tener mejores reglas de almacenamiento en caché que su servidor. ¿Es la latencia el mayor problema o el ancho de banda? Si hay latencia, apunte a menos solicitudes, así que alójelo localmente y combine archivos tanto como sea posible. Si es ancho de banda, elija la opción que termine con el código más pequeño y el formato de fuente más pequeño.
Ahora, pasemos a la consideración de CSS vs JS. Veamos el siguiente fragmento de HTML:
En muchos casos,
script1,style1, ystyle2sería el bloqueo. Esto significa que el navegador no puede seguir mostrando el documento hasta que ese recurso se haya cargado (aunque los navegadores modernos modifican esto un poco). Lo que realmente puede ser algo bueno, especialmente con las hojas de estilo. Evita un destello de contenido sin estilo y también evita el cambio gigante que ocurriría al aplicar los estilos (y cambiar el contenido es realmente molesto para el usuario).Por otro lado,
script2no estaría bloqueando. Se puede cargar más tarde y el navegador puede pasar a analizar y mostrar el resto del documento. Entonces eso también puede ser beneficioso.Hablando específicamente de fuentes (y aún más específicamente, la oferta de Google), probablemente me quedaría con un método CSS (me gusta
@importporque sigue estilizando con la hoja de estilo, pero podría ser solo yo). El archivo JS cargado por el script ( http://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js ) es más grande que la@font-facedeclaración, y parece mucho más trabajo. Y no creo que cargar la fuente real en sí (WOFF o TTF) esté bloqueando, por lo que no debería retrasar demasiado las cosas. Personalmente, no soy un gran fanático de los CDN, pero el hecho es que son REALMENTE rápidos. Los servidores de Google superarán por completo a la mayoría de los planes de alojamiento compartido, y debido a que sus fuentes son tan populares, es posible que la gente incluso las tenga almacenadas en caché.Y eso es todo lo que tengo.
No tengo experiencia con Typekit, así que lo dejé fuera de mi teorización. Si hay alguna inexactitud, sin contar las generalizaciones entre navegadores por el bien de los argumentos, indíquelo.
fuente
Creo que ha abordado muy bien los tiempos de carga en su pregunta. Desde mi perspectiva, hay algunas fuentes que deben agregarse a la lista y algunas otras consideraciones que deben examinarse para obtener una visión completa de las opciones.
Algunas otras fuentes de fuentes confiables
tipografía de nube
http://www.typography.com/cloud/
Por lo que puedo decir, las fuentes están incrustadas como datos en un archivo CSS:
Aquí están mis especificaciones:
Aquí está su descripción de muy alto nivel de su implementación .
Fonts.com
No he usado este servicio, pero son un proveedor de fuentes muy establecido y la información que han incluido en su sitio es bastante impresionante. No tengo especificaciones sobre sus métodos exactos, pero esto es lo que sé que tienen:
FontSpring
Afiliado con FontSquirrel. Las fuentes se pueden comprar aquí por un precio fijo. Se entregan los archivos de fuentes y el CSS que los acompaña, para ser implementados en su propio servidor, al igual que FontSquirrel.
Especificaciones ampliadas
En cuanto a los pros y los contras generales de cada servicio de fuentes, aquí hay algunas comparaciones:
Tamaño de la biblioteca de fuentes
Precios
Calidad de fuente
La calidad de las fuentes web puede variar bastante. Esto puede abarcar cosas como las formas de las letras o el espaciado o el tamaño del conjunto de caracteres. Todo esto determina la impresión general de calidad que dará una fuente. Si bien las opciones gratuitas tienen algunas buenas opciones, también tienen algunas fuentes que no son de tan alta calidad, por lo que debe elegir cuidadosamente entre esas fuentes.
Calidad de fuente II: tipografía
Hay muchas mejoras en la tipografía de escritorio que han sido muy difíciles de conseguir en las fuentes web. Algunos de estos servicios ofrecen formas de brindarlos.
Soporte de navegador
Esto se reduce principalmente a los formatos de fuente que admite cada servicio. Los principales son:
Más información en The @ Font-Face Rule y útiles trucos de fuentes web
Todos estos servicios admiten los principales formatos de fuente. Con fuentes autohospedadas, siempre que use la sintaxis correcta, debe estar cubierto. Aquí hay una actualización de 2011 de la sintaxis a prueba de balas de FontSpring :
Performance I: Descargas
Por lo que yo entiendo, el uso de la sintaxis anterior permite a los navegadores tomar el formato específico que funciona para ellos, por lo que no hay descargas desperdiciadas en formatos de fuente que no funcionan.
Los servicios pagos como Fonts.com, Typekit o Typography.com utilizan métodos para detectar el formato correcto y luego entregar el formato de fuente correcto, a menudo como datos base64 en un archivo CSS.
Por lo que puedo ver, las diferencias en los métodos que ha enumerado anteriormente son bastante insignificantes para los usuarios de Internet de alta velocidad (parece una diferencia de <200 ms), pero podría valer la pena considerar para dispositivos en redes más lentas, especialmente para visitas a páginas sin caché.
Desempeño II: Subconjunto
Si sabe que solo habrá ciertos caracteres que desea usar, puede construir su fuente con un subconjunto de caracteres y así reducir el tamaño de la descarga.
Desempeño III: Entrega
Ayuda de idioma
Prueba e implementación
fuente
Bueno, como buscas
la respuesta es (como siempre en el diseño web): ¡Depende!
Una cosa es segura es que no recomendaría usar el enfoque JS (que se muestra en su segundo ejemplo).
Personalmente no me gusta hacer cosas de presentación y estilos CSS dependiendo de Javascript, aunque la gran mayoría de usuarios lo tienen habilitado. Se trata de no mezclar las cosas.
Y como puede ver en su ejemplo dado, hay algún tipo de FOUC (flasheo de contenido sin estilo), porque el navegador ya representa la página antes de que la fuente esté disponible. Tan pronto como esté, la página se vuelve a dibujar. ¡Y cuanto más grande sea el sitio, mayor será el impacto (de rendimiento)!
Por lo tanto, nunca usaría ninguna solución JS para incrustar fuentes.
Ahora echemos un vistazo a los métodos CSS puros.
Desde hace bastante tiempo aquí hay una discusión sobre "vs. @import". Personalmente prefiero evitar el uso de @import y usar siempre
<link>solo. Pero esto es principalmente una cuestión de preferencias personales. ¡Lo único que nunca debes hacer es mezclar ambos!Local frente a CDN
Al decidir si alojar sus archivos de fuentes localmente o usar una CDN, en mi humilde opinión, depende principalmente del número de fuentes diferentes y las fuentes respectivas que desea incrustar.
¿Por qué es esto importante o juega un papel?
Desde el punto de vista del rendimiento, recomendaría incluir la fuente Base64 codificada en su (una) hoja de estilo. Pero solo el formato .woff, ya que es utilizado por casi todos los navegadores modernos, lo que significa para la mayoría de sus visitantes. Para todos los demás usuarios viven con la solicitud adicional.
Pero debido a la "sobrecarga" causada por la codificación Base64 y el tamaño de un archivo de fuente (incluso en formato .woff), esta técnica solo debe usarse si no tiene más de 3 o 4 fuentes diferentes. Y siempre asegúrese de que su servidor entregue los archivos (CSS) en formato gzip.
La gran ventaja de hacerlo es que no tiene una solicitud adicional para el archivo de fuente. Y después de la primera carga de la página (sin importar la página de su sitio), el archivo CSS se almacena en caché. Esto también es una ventaja si utiliza la caché de la aplicación HTML5 (lo que sin duda hará).
Además del hecho de que un autor no debería usar más de un máximo de 3 o 4 fuentes diferentes en su sitio, echemos un vistazo al método para usar la CDN de Google.
En primer lugar, tenga en cuenta que puede (y siempre debe) incluir todas las fuentes deseadas en una sola
<link>, así:Esto resultará en la siguiente respuesta:
Como puede ver, hay 9 archivos de fuentes diferentes, lo que significa un total de 10 (incluido el del elemento de enlace) solicitudes, si el usuario no tiene una o más de las fuentes solicitadas instaladas localmente. ¡Y estas solicitudes se repiten en cada solicitud de página nueva a su sitio (aunque no se transfieren más datos)! Además, la respuesta a la solicitud del
<link>nunca se almacenará en caché.Recomendación: ¡
Después de todo, realmente recomendaría incluir su (s) archivo (s) de fuente en formato .woff codificado en Base64 en su hoja de estilo!
¡Vea este bonito artículo para ver un ejemplo y una descripción de cómo hacerlo!
fuente
Utilizo el método css en línea porque la sobrecarga de la solicitud adicional es mayor que el aumento de tamaño cuando se codifica bease64. Esto también se compensa aún más con la compresión gizip por parte del servidor de los archivos css.
Otra opción es usar la carga asincrónica de fuentes, pero la mayoría de las veces los usuarios verán las fuentes apareciendo después de la carga.
Independientemente del método, puede reducir el tamaño del archivo de fuente si solo incluye los conjuntos de caracteres que utilizará.
fuente
Personalmente utilizo Google Fonts. Tienen una buena variedad de opciones y recientemente han mejorado la compresión de las fuentes al pasar también a la compresión Zopfli . Google se esfuerza por hacer que la web sea más rápida, por lo que supongo que también vendrá de ellos una mayor optimización en esa parte.
Independientemente de lo que elija como entrega de fuentes subcontratada, siempre obtendrá reducciones en la velocidad de las solicitudes para obtener las fuentes. Lo mejor, visto desde una perspectiva de velocidad, sería servir las fuentes usted mismo. Si no le importan esos milisegundos adicionales que se necesitan para cargar desde una entrega subcontratada, debe aceptarlos si cree que la facilidad de uso vale la pena los milisegundos.
No sé sobre Typekit y los demás, pero con Google Fonts puede elegir que le sirvan subconjuntos específicos y rango de caracteres para acelerar la entrega aún más.
Elegir un subconjunto:
Elegir una variedad de personajes:
Puede utilizar dns-prefetch para mejorar aún más la velocidad con la entrega de fuentes.
Creo, y espero, que Google hará todo lo posible para acelerar la entrega de fuentes tanto como pueda. Los milisegundos que se necesitan para cargarlos no perjudican a mi sitio web, así que los uso felizmente.
Larga historia corta:
Si la entrega de fuentes en milisegundos está dañando su sitio, por ejemplo, al hacer que cargue más del 1 segundo recomendado, creo que debería alojarlas usted mismo.
fuente
<link rel=dns-prefetch href='//fonts.googleapis.com'>que lo uso para análisis, mapas de calor y subdominios, por alguna razón no se registró para ejecutarse para las fuentes web externas. Y el tiempo de carga difiere enormemente de una fuente a otra, supongo que si está usando una fuente bastante popular (puede estar almacenada en caché) o solo un puñado de fuentes, usar webfonts es una excelente fuente de fuentes bastante rápida. Publicaré pruebas de velocidad aquí en breve.La mejor opción es importar las fuentes usando ajax, así:
Hago esto en mi página web y aumento 9 puntos en la prueba de Google Insights.
fuente
asyncatributo? Hace la misma cosa.