¿Por qué los sitios web no muestran inmediatamente su texto en estos días?

Me he dado cuenta de que recientemente muchos sitios web son lentos para 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 todo lo contrario que antes, 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 estoy en una conexión lenta, lo que probablemente acentúa el problema.

Vea a continuación un ejemplo: todo está cargado pero tarda unos segundos más antes de que finalmente se muestre el texto:

Una razón es que a los diseñadores web hoy en día les gusta usar fuentes web (generalmente en formato WOFF ), por ejemplo, a 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 había instalado localmente. Dado que, por ejemplo, los usuarios de Mac y Windows no necesariamente tenían las mismas fuentes, los diseñadores siempre definieron instintivamente las reglas como

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

donde, si no se encuentra la primera fuente en el sistema, el navegador buscará la segunda y, por último, una fuente alternativa "sans-serif".

Ahora, uno puede dar una URL de fuente 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 cargue 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 lleva al problema de que no se muestra texto hasta que el navegador haya cargado el recurso, que incluye el tiempo de descarga, el tiempo de carga de la fuente y el tiempo de representación. Espero que este sea el artefacto que estás experimentando.

Como ejemplo: uno de mis periódicos nacionales, Dagens Nyheter , usa fuentes web para sus titulares, pero no sus leads, por lo que cuando se carga ese sitio, generalmente veo los leads primero, y medio segundo después todos los espacios en blanco de arriba están ocupados con titulares (esto es cierto en Chrome y Opera, al menos. No he probado otros).

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

Adición

Esta respuesta se volvió muy votada, aunque no entre en muchos detalles, o tal vez por esto. Ha habido muchos comentarios en el hilo de preguntas, por lo que intentaré expandirme un poco (muchos comentarios parecen haber desaparecido poco después de que se protegió el tema; es probable que algún moderador los haya limpiado manualmente). Además, lea las otras respuestas en este hilo, ya que todas se expanden a su manera.

El fenómeno aparentemente 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" 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 al no representar el texto de la fuente web con una fuente alternativa durante el período de carga de la fuente web. Incluso si la fuente web se almacena en caché, habrá un retraso de renderizado . Hay muchos comentarios en este hilo de preguntas que dicen lo contrario y que es completamente incorrecto que las fuentes en caché se comporten así, pero, por ejemplo, desde el enlace anterior:

En qué casos obtendrás un FOUT

• Will: descargar y mostrar un ttf / otf / woff remoto
• Will: Mostrar un ttf / otf / woff en caché
• Will: descarga y muestra un data-uri ttf / otf / woff
• Will: mostrar un data-uri en caché 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 ()

Como Chrome espera hasta que el riesgo FOUT haya desaparecido antes de renderizar, esto genera un retraso. Hasta qué punto el efecto es visible (especialmente cuando se carga desde la memoria caché) parece depender, entre otras cosas, de la cantidad de texto que debe procesarse 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 de 2011–04–14 al final 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 recupera la fuente alternativa. Sin embargo, la fuente web probablemente se cargará dentro de esos tres segundos ... con suerte ...
• IE9 admite WOFF y TTF y OTF (aunque requiere un conjunto de bits de incrustación , principalmente discutible si usa WOFF). ¡¡¡SIN EMBARGO!!! IE9 tiene un FOUT. :(
• Webkit tiene un parche en espera de aterrizar para mostrar el texto alternativo después de 0,5 segundos. Así mismo comportamiento que FF pero 0.5s en lugar de 3s.
• Adición : Blink también tiene un error registrado para esto , pero parece que no se ha alcanzado un consenso final sobre qué hacer con él, actualmente la misma implementación que WebKit.

Si se tratara de una pregunta dirigida a los diseñadores, uno podría buscar formas de evitar este tipo de problemas webfontloader, pero esa sería otra pregunta. El enlace de Paul Irish entra en más detalles sobre este asunto.

La razón de esto es que el texto que aún no puede leer se representa con una fuente web que todavía está en camino hacia su navegador.

Además, dado que su navegador es Google Chrome, que usa WebKit para representar la página, ellos decidieron (es decir, WebKit) que es mejor que no vea ningún texto hasta que se descargue la fuente web. Sin embargo, si usted es un desarrollador que prefiere que el texto sea legible en una fuente de sistema alternativa adecuada, puede usar algo como el WebFont Loader de Google para lograr esto.

Respuesta corta: AJAX o WOFF

Hay varias causas de que los sitios web sean "lentos para mostrar su texto" . La lentitud en portableapps.com es causada por la descarga de fuentes WOFF . Sin embargo, lo que usted describe como "el texto comienza a aparecer aquí y allá" es causado con mayor frecuencia por AJAX .

Un sitio web se compone de muchas partes. La forma en que estas partes se descargan y ensamblan es una opción de diseño bajo el control del diseñador web . La lentitud es causada por cómo el desarrollador elige ensamblar los siguientes bloques de construcción:

• Página HTML inicial
• CSS
• JS
• Imágenes
• Fuentes WOFF
• Solicitudes AJAX
• Manipulación DOM

Tradicionalmente sitios web:

Tradicionalmente, era común que los desarrolladores pusieran el contenido de texto en la página HTML inicial y lo mostraran tan pronto como estuviera disponible . El HTML haría referencia a varios recursos que luego se descargarían. El navegador redibujaría progresivamente la pantalla para incluir los estilos e imágenes a medida que estuvieran disponibles. AJAX y WOFF no estaban disponibles.

Sitios web de WOFF:

Las fuentes WOFF permiten que un sitio web use fuentes que normalmente no están disponibles para el navegador, descargando fuentes con el sitio web . Algunos desarrolladores le indican al navegador que no muestre el contenido del texto hasta que se hayan descargado todas las fuentes WOFF. En mi experiencia, este enfoque aún no ha ganado un uso muy amplio.

Sitios web de AJAX:

Algunos desarrolladores optan por no incluir el contenido de texto en la página HTML inicial. En su lugar, eligen descargar el contenido de texto usando AJAX. Esto sucede después de que se haya cargado la página básica . En mi experiencia, este método ha adquirido una adopción mucho más amplia que las fuentes WOFF y, a menudo, es la causa de la lentitud que usted describe.

Determinando la Causa

Para determinar la causa de un sitio específico se requiere un análisis utilizando herramientas como Firebug o Chrome Developer Tools . O bien, puede abrir el sitio con Internet Explorer 8 , que admite AJAX pero no WOFF. Si el sitio aún es lento, el problema es AJAX y no WOFF.

A menudo, puede ser una elección deliberada evitar el "destello de contenido sin estilo". Si el texto que se muestra antes de que se cargue el CSS, lo verá brevemente como aparece sin formato y luego parpadeará cuando el navegador lo vuelva a dibujar. Al poner algunos estilos básicos en línea para ocultar inicialmente el contenido, que se anula en la hoja de estilo real, o usar JS, los desarrolladores evitan este flash.

Como otros han señalado, es probable que las fuentes personalizadas contribuyan al retraso.

Para dar un poco más de información de fondo, el navegador está haciendo aproximadamente lo siguiente antes de poder mostrar el contenido de la página en la pantalla:

1. buscar HTML (varios viajes de ida y vuelta para DNS, TCP, solicitud / respuesta)
2. comience a analizar HTML, descubra recursos externos como CSS y JS externos. Tenga en cuenta que CSS bloquea el diseño y JS bloquea el análisis. Por lo tanto, los recursos externos como CSS y JS cargados al principio del documento (por ejemplo, en la cabeza) reducen el tiempo que tarda una página en mostrar contenido en la pantalla.
3. buscar CSS y JS externos (varios viajes de ida y vuelta: DNS y TCP si estos recursos están en un dominio diferente, como CDN, así como un RTT para la solicitud / respuesta)
4. una vez que CSS y JS externos hayan terminado de cargarse, analizar / ejecutar JS, analizar / aplicar estilos
5. si el CSS hace referencia a fuentes personalizadas, esas fuentes ahora también deben descargarse, lo que resulta en demoras adicionales de ida y vuelta para representar cualquier parte de la página que dependa de las fuentes personalizadas

Aunque no se trata de los retrasos causados ​​específicamente por las fuentes personalizadas, escribí una publicación de blog recientemente que brinda información adicional sobre las causas de los retrasos en el renderizado. Da algunas sugerencias para minimizar el tiempo de la primera pintura para sus páginas. Esperemos que esto sea útil para los lectores interesados ​​en hacer que sus páginas muestren contenido más rápido, incluidas aquellas páginas que desean usar fuentes personalizadas: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -un segundo/

Respuesta corta: desarrolladores.

Cuando las etiquetas de enlace y script que hacen referencia a documentos externos (como archivos .css o .js) se colocan en el encabezado del documento (más alto en el flujo que el cuerpo y sus elementos), se cargan primero. JavaScript se ejecuta desde el marcado que hace referencia a él; si hay mucho código para procesar, o es un código engorroso, o más comúnmente si el texto que espera ver se procesa en un servidor y se completa en el documento al cargarlo, y ese código del lado del servidor también es engorroso, grande, o bloqueando E / S debido al procesamiento de varias solicitudes concurrentes, ciertamente puede notar el tiempo de inactividad antes de que el HTML haya tenido la oportunidad de renderizarse. Algunos desarrolladores optan por cargar JavaScript no relacionado con la vista después del marcado y los estilos (al final del cuerpo),

La velocidad de conexión a Internet juega un papel en la descarga lenta de datos, obviamente, pero el código mal escrito o las pilas de tecnología mal diseñadas (para el tipo de sitio web) juegan un papel cada vez más central en la carga lenta de contenido dinámico, ya que las conexiones de red más rápidas enfoque ubicuidad.

En pocas palabras, demasiados objetos cargables que deben cargarse desde HTTP GET separados antes de que se pueda mostrar la página, y una dependencia excesiva en la latencia promedio como una medida del estado del sitio.

El primero se refiere a todos esos .css, .js y fuentes web que carga la página, sin mencionar el hecho de que muchos sitios también necesitan recuperar objetos JSON a partir de solicitudes XHR y luego generar HTML a partir de aquellos que utilizan algún tipo de plantilla.

Pero, ¿por qué no se dan cuenta de que el sitio es lento?

Probablemente porque tienen memecache en algún lugar para acelerar las cosas (o simplemente confían en los cachés del sistema de archivos) y están midiendo el estado de su sitio usando una latencia promedio. Por lo tanto, los objetos en caché se devuelven con una latencia de 6 mircrosegundos y enmascaran el hecho de que muchas solicitudes GET tardan 5000 milisegundos en completarse. Los promedios deben morir. ¡Viva el recuento de RTT por encima de un umbral máximo aceptable! Ese número debe ser 0 o, por definición, el RTT es inaceptable.

Bueno, hay múltiples razones. Una razón también es que los comandos para definir un fondo o encima de una página html a menudo o recuperados en un CSS separado que se carga primero. antes de cargar el cuerpo del documento que contiene el texto.

Otra causa es que, aunque es posible escribir el tamaño de una imagen en la mayoría de los casos, los diseñadores web no hacen uso de eso. Y entonces el brouwser tiene que cargar todas las imágenes primero en las páginas para que sepa cómo envolver el texto.

Algunos diseñadores, también quieren mostrar las primeras imágenes y el siguiente texto, lo logran con algunos JavaScript, por ejemplo, una página simple mostrará primero un banner y luego todo lo demás en él.

Pero si se pregunta por qué hay tanto material comercial de spam en mis páginas mientras solo quiero leer las noticias, entonces hay una solución para usted. Puedes usar bloqueadores de spam si usas firefox. Con tal complemento, el navegador web conoce los sitios que proporcionan spam y simplemente los bloquea, lo que resulta en una carga de página mucho más rápida, mientras aún puede ver las imágenes importantes que se relacionan con los artículos que lee.

Les recomendaría a todos ustedes que se ocupan de la carga lenta de páginas que prueben Fidler. Fidler se puede usar con IEexplorer o con FireFox (usando su función proxy). Fidler realmente le mostrará cuánto tiempo lleva realmente y cuándo se cargan partes de una página web. Es una herramienta de depuración de HTML.