Si eres propenso a mirar el panel del navegador con ojo de águila, es posible que hayas notado que las páginas cargan con frecuencia sus imágenes y diseño antes de cargar su texto, el patrón de carga exactamente opuesto que experimentamos durante la década de 1990. ¿Que esta pasando?
La sesión de preguntas y respuestas de hoy nos llega por cortesía de SuperUser, una subdivisión de Stack Exchange, una agrupación de sitios web de preguntas y respuestas impulsada por la comunidad.
La pregunta
El lector de superusuario Laurent siente mucha curiosidad por saber por qué exactamente las páginas parecen cargar elementos de manera completamente diferente a como lo hacían una vez. El escribe:
He notado que recientemente muchos sitios web tardan en mostrar su texto. Por lo general, se cargarán el fondo, las imágenes, etc., pero no el texto. Después de un tiempo, el texto comienza a aparecer aquí y allá (no siempre todo al mismo tiempo).
Básicamente, funciona al revés como solía hacerlo, cuando el texto se mostraba primero, luego las imágenes y el resto se cargaba después. ¿Qué nueva tecnología está creando este problema? ¿Alguna idea?
Tenga en cuenta que tengo una conexión lenta, lo que probablemente acentúe el problema.
Consulte [above] para ver un ejemplo: todo está cargado, pero se necesitan unos segundos más antes de que finalmente se muestre el texto.
Entonces, ¿qué pasa? Laurent, y muchos de nosotros, recordamos una época en la que el texto se cargaba primero y todo lo demás (GIF animados, fondos en mosaico y todos los demás artefactos de la navegación web de finales de los noventa) llegó después. ¿Qué causa la situación actual de los elementos de diseño primero, texto después?
La respuesta
El colaborador de superusuario Daniel Andersson ofrece una respuesta maravillosamente detallada que llega hasta el fondo del misterio de por qué las fuentes se cargan por última vez:
Una de las razones es que a los diseñadores web hoy en día les gusta usar fuentes web (generalmente en WOFF formato), p. ej. mediante Fuentes web de Google .
Anteriormente, las únicas fuentes que podían mostrarse en un sitio eran las que el usuario tenía instaladas localmente. Dado que p. Ej. Los usuarios de Mac y Windows no tenían necesariamente las mismas fuentes, los diseñadores siempre definieron instintivamente las reglas como
familia de fuentes: Arial, Helvetica, sans-serif;donde, si la primera fuente no se encuentra en el sistema, el navegador buscará la segunda y, por último, una fuente alternativa "sans-serif".
Ahora, se puede dar una URL de fuente como regla CSS para que el navegador descargue una fuente, como tal:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700);y luego cargue la fuente para un elemento específico por ejemplo:
familia de fuentes: 'Droid Serif', sans-serif;Esto es muy popular para poder usar fuentes personalizadas, pero también conduce al problema de que no se muestra texto hasta que el navegador ha cargado el recurso, lo que incluye el tiempo de descarga, el tiempo de carga de la fuente y el tiempo de renderizado. Espero que este sea el artefacto que está experimentando.
Como ejemplo: uno de mis periódicos nacionales, Noticias de hoy , use fuentes web para sus titulares, pero no para sus clientes potenciales, por lo que cuando se carga ese sitio, generalmente veo los clientes potenciales primero, y medio segundo después, todos los espacios en blanco de arriba se llenan con títulos (esto es cierto en Chrome y Opera, en menos. No he probado otros).
(Además, los diseñadores esparcen JavaScript por todas partes en estos días, por lo que tal vez alguien esté tratando de hacer algo inteligente con el texto, razón por la cual se retrasa. Sin embargo, eso sería muy específico del sitio: la tendencia general de que el texto se retrase en estos veces es el problema de las fuentes web descrito anteriormente, creo).
Adición:
Esta respuesta se volvió muy positiva, aunque no entré en muchos detalles, o tal vez porque de esta. Ha habido muchos comentarios en el hilo de preguntas, así que intentaré expandirlo un poco […]
Al parecer, el fenómeno se conoce como "destello de contenido sin estilo" en general, y "destello de texto sin estilo" en particular. La búsqueda de "FOUC" y "FOUT" proporciona más información.
Puedo recomendar la publicación del diseñador web Paul Irish sobre FOUT en relación con las fuentes web .
Lo que se puede notar es que diferentes navegadores manejan esto de manera diferente. Escribí anteriormente que había probado Opera y Chrome, que se comportaron de manera similar. Todos los basados en WebKit (Chrome, Safari, etc.) eligen evitar FOUT al no renderizar texto de fuente web con una fuente alternativa durante el período de carga de fuentes web. Incluso si la fuente web está almacenada en caché, allí será ser un retraso de renderizado . Hay muchos comentarios en este hilo de preguntas que dicen lo contrario y que es completamente incorrecto que las fuentes almacenadas en caché se comporten así, pero p. desde el enlace anterior:
¿En qué casos obtendrá un FOUT
- Será: Descarga y visualización de un ttf / otf / woff remoto
- Será: Visualización de un ttf / otf / woff en caché
- Será: Descarga y visualización de datos-uri ttf / otf / woff
- Será: Visualización de datos en caché-uri ttf / otf / woff
- No: Mostrar una fuente que ya está instalada y nombrada en su pila de fuentes tradicional
- No: Mostrar una fuente que está instalada y nombrada usando la ubicación local ()
Dado que Chrome espera hasta que desaparezca el riesgo CUATRO antes de renderizar, esto produce un retraso. A la que grado el efecto es visible (especialmente cuando se carga desde la caché) parece depender, entre otras cosas, de la cantidad de texto que se necesita procesar y quizás de otros factores, pero el almacenamiento en caché no elimina completamente el efecto.
Irish también tiene algunas actualizaciones sobre el comportamiento del navegador a partir de 2011-04-14 en la parte inferior de la publicación:
- Firefox (a partir de FFb11 y FF4 Final) ya no tiene CUATRO! ¡Wooohoo! http://bugzil.la/499292 Básicamente, el texto es invisible durante 3 segundos y luego recupera la fuente alternativa. Sin embargo, la fuente web probablemente se cargará en esos tres segundos ... con suerte ...
- IE9 admite WOFF y TTF y OTF (aunque requiere un poco de incrustación establecer cosa - mayormente discutible si usa WOFF). ¡¡¡SIN EMBARGO!!! IE9 tiene un FOUT. :(
- Webkit tiene un parche esperando aterrizar para mostrar el texto de respaldo después de 0,5 segundos. Así que el mismo comportamiento que FF pero 0.5s en lugar de 3s.
Si esta fuera una pregunta dirigida a los diseñadores, se podrían buscar formas de evitar este tipo de problemas como
webfontloader, pero esa sería otra pregunta. El vínculo de Paul Irish entra en más detalles sobre este asunto.
¿Tiene algo que agregar a la explicación? Habla en los comentarios. ¿Quieres leer más respuestas de otros usuarios de Stack Exchange expertos en tecnología? Consulte el hilo de discusión completo aquí .
