¿Por qué las páginas web no muestran inmediatamente su texto?

Si es propenso a mirar el panel del navegador con un ojo de águila, puede haber notado que con frecuencia las páginas cargan sus imágenes y el 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?

Pregunta de hoy &La sesión de respuesta nos llega por cortesía de SuperUser, una subdivisión de Stack Exchange, una agrupación de sitios web Q & A dirigida por la comunidad.

El lector

SuperUser de Question Laurent es muy curioso acerca de por qué exactamente las páginas parecen cargar elementos de forma completamente diferente a como lo hacían alguna vez.Él escribe:

. He notado que recientemente muchos sitios web tardan en mostrar su texto. Por lo general, el fondo, las imágenes, etc. se cargarán, 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 cargaban 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.

Vea [arriba] para ver un ejemplo: todo está cargado, pero demora unos segundos más para que finalmente se muestre el texto.

Entonces, ¿qué da? Laurent, y muchos de nosotros, recordamos una época en la que el texto se cargaba primero y todo lo demás( guardan GIF animados, fondos en mosaico y todos los demás artefactos de la navegación web de finales de los 90) llegó más tarde.¿Qué causa primero la situación actual de los elementos de diseño, texto posterior?

La respuesta

SuperUser contribuidor Daniel Andersson ofrece una respuesta maravillosamente detallada que llega al fondo del misterio de por qué las fuentes de carga-último:

Una razón es que los diseñadores web hoy en día les gusta usar fuentes web( generalmente en formato WOFF), p.eja través de las fuentes web de Google.

Anteriormente, las únicas fuentes que se podían mostrar en un sitio eran aquellas que el usuario tenía instaladas localmente. Desde, por ejemplo, Los usuarios de Mac y Windows no necesariamente tenían las mismas fuentes, los diseñadores siempre definían las reglas como

font-family: Arial, Helvetica, sans-serif;

donde, si la primera fuente no se encontraba en el sistema, el buscador buscaría la segunda y, por último, una fuente "sans-serif" alternativa.

Ahora, uno puede dar una fuente URL como una 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 carga la fuente para un elemento específico, por ejemplo:

font-family: 'Droid Serif', sans-serif;

Esto es muy popular para poder usar fuentes personalizadas, pero también genera el problema de que no se muestra texto hasta que el navegador carga el recurso, 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ás experimentando.

Como ejemplo: uno de mis periódicos nacionales, Dagens Nyheter, utiliza fuentes web para sus titulares, pero no sus clientes potenciales, así que cuando ese sitio está cargado, generalmente veo los clientes potenciales primero, y medio segundo después aparecen todos los espacios en blanco.poblado con titulares( esto es cierto en Chrome y Opera, al menos. No he probado otros).

( Además, los diseñadores rocían JavaScript absolutamente en todas partes en estos días, por lo que tal vez alguien esté tratando de hacer algo inteligente con el texto, que es por lo que se retrasa. Sin embargo, eso sería muy específico del sitio: la tendencia general a retrasar el textoestos tiempos es el problema de las fuentes web descrito anteriormente, creo.)

Adición:

Esta respuesta se volvió muy upvoted, aunque no entre en mucho detalle, o tal vez porque de esto. Ha habido muchos comentarios en el hilo de preguntas, así que intentaré expandir un poco [...]

El fenómeno es aparentemente conocido como "flash de contenido sin estilo" en general, y "flash de texto sin estilo" en particular. La búsqueda de "FOUC" y "FOUT" brinda más información.

Puedo recomendar la publicación del diseñador web Paul Irish en 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 mediante , no , renderizando texto de fuente web con una fuente alternativa durante el período de carga de la fuente web. Incluso si la fuente web está en caché, será un de retardo de representación. Hay una gran cantidad de comentarios en este hilo de preguntas que dicen lo contrario y es totalmente erróneo que las fuentes en caché se comporten así, pero p.desde el enlace anterior:

En qué casos obtendrá un FOUT

• Will: Descargando y mostrando un ttf remoto /otf/ woff
• Will: Mostrando un ttf en caché /otf/ woff
• Will: Descargando y visualizando un data-uri ttf /otf/ woff
• Will: Mostrar un archivo almacenado en memoria caché de datos /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 utilizando el local() ubicación

Debido a que Chrome espera hasta que el riesgo de FOUT haya desaparecido antes de la renderización, se produce un retraso. A qué extensión el efecto es visible( especialmente al cargar desde el caché) parece depender, entre otras cosas, de la cantidad de texto que se debe representar y quizás de otros factores, pero el almacenamiento en caché no elimina por completo el efecto.

Irish también tiene algunas actualizaciones sobre el comportamiento del navegador a partir del 2011-04-14 en la parte inferior de la publicación:

• Firefox ( a partir de FFb11 y FF4 Final) ¡ ya no tiene un FOUT! Wooohoo! Http: //bugzil.la/ 499292 Básicamente, el texto es invisible durante 3 segundos, y luego devuelve la fuente alternativa. Sin embargo, el webfont probablemente se cargue dentro de esos tres segundos. .. con suerte. ..
• IE9 admite WOFF y TTF y OTF( aunque requiere un conjunto de bits incrustado, casi irrelevante si usas WOFF). SIN EMBARGO! !!IE9 tiene un FOUT.:(
• Webkit tiene un parche esperando aterrizar para mostrar el texto de repliegue después de 0.5 segundos. Así que el mismo comportamiento que FF pero 0.5s en vez de 3.

Si esta era una pregunta dirigida a los diseñadores, uno podría tomar medidas para evitar estos tiposde problemas como webfontloader, pero esa sería otra pregunta. El enlace de Paul Irish entra en más detalles sobre este asunto.

¿Tiene algo que agregar a la explicación? Suena apagado en los comentarios. ¿Quieres leer más respuestas de otros técnicos?¿Conoce a los usuarios de Stack Exchange? Consulte el hilo de discusión completo aquí.