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

443

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:

ingrese la descripción de la imagen aquí

Laurent
fuente
72
En este caso particular, PortableApps.com está utilizando la fuente "Ubuntu". John probó OpenSans primero, pero cambiamos a Ubuntu con bastante rapidez. Fui el principal defensor del cambio ... una forma de eliminar el problema es instalar la familia de fuentes usted mismo. Si lo instala desde font.ubuntu.com , funcionará de inmediato.
Chris Morgan
21
La respuesta de Daniel es reveladora. Pensé que esto se hace a propósito para que podamos ver todos los anuncios en la página.
Manoj R
1
Como varias personas han señalado aquí, hay infinitas razones para que el texto se represente de manera inesperada, ya que la representación de una página solo está limitada por la imaginación del desarrollador / diseñador, que ha sido el caso al menos desde que los códigos de posición ANSI permitieron el boletín de la década de 1980 tableros para implementar chats multiusuario e interfaces de usuario con ventanas superpuestas con sombras paralelas. Meebo fue uno de los primeros en reproducir algunos de estos efectos en un navegador sin Applet. "Funciona al revés como solía" simplifica enormemente Internet y ni siquiera se refiere a un período de tiempo específico.
PJ Brunet
66
Entonces, ¿por qué hacer generalizaciones generales sobre Internet basadas en una tapa de pantalla aleatoria de un sitio web con un rango bajo de Alexa? La mejor respuesta también hace una afirmación audaz: "hoy en día los diseñadores hacen XYZ" deben respaldarse con algunos números reales, como "el 5% de los sitios web utilizan fuentes web de Google a partir de 2012" o lo que sea.
PJ Brunet
1
Pero los archivos de fuentes se guardan en caché, este sitio tiene una larga espera para cargar m.aspx, podrían verificar esa parte
user613326

Respuestas:

482

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.

Daniel Andersson
fuente
77
¿Alguno de los navegadores ha intentado representar el texto primero en una fuente disponible y volver a representarlo una vez que se descarga la fuente preferida?
Steve Bennett
44
Oh, duh, comenta la siguiente respuesta: paulirish.com/2009/fighting-the-font-face-fout
Steve Bennett
55
@ratchetfreak sería desconcertante volver a formatear la página, ya que las fuentes probablemente no tendrían las mismas métricas
Samuel Edwin Ward,
66
algunos prefieren llegar a la parte de lectura de navegar por una página web en lugar de esperar las edades para la fuente de conseguir carga
trinquete monstruo
@ SteveBennett Estoy bastante seguro de que eso es exactamente lo que está haciendo Internet Explorer 10. Nunca he visto aparecer mensajes de texto más tarde. Para mí, siempre aparece texto en alguna "fuente estándar" y unos segundos después cambia al estilo / descargado. Sin embargo, no estoy seguro de si elige el próximo CSS o solo el predeterminado del sistema. Editar: Ah, bien, ¿entonces es solo Webikit con el texto oculto? Consideraría ese comportamiento molesto y malo. ¿Hay algún navegador que ignore / oculte la carga progresiva de imágenes?
Mario
117

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.

Marcel
fuente
Lamentablemente es una respuesta incorrecta, si visita esta página una vez, el archivo de fuente residiría en su efectivo web; para otras páginas en este sitio u otros sitios web que usen esta fuente, se recuperaría de efectivo.
user613326
19

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.

KevSheedy
fuente
14

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.

Greg H
fuente
66
Nueve de cada diez veces no será deliberado, es simplemente un efecto secundario de incrustar fuentes web de la manera más simple posible. De hecho, se necesita un poco más de esfuerzo para presentar una alternativa visible mientras las fuentes web se están agotando. Ver developers.google.com/webfonts/docs/webfont_loader
Marcel
@Marcel: esto puede ser causado por hojas de estilo lentas y fuentes lentas, consulte phpied.com/css-and-the-critical-path
r3m0t
El código para evitar el "destello de contenido útil" tiende a evitar que aparezcan imágenes y texto.
Jon Hanna
Me cuesta entender por qué el texto sin estilo es peor que ningún texto. Prefiero poder comenzar a leer y aceptar que podría moverse un poco. Me parece más discordante cuando aparece repentinamente por ninguna parte y es muy frustrante cuando una página se ha cargado y te ves obligado a esperar una fuente.
Richard Le Poidevin
8

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/

Bryan McQuade
fuente
4

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.

Benny
fuente
21
No, lo que describe puede bloquear la visualización de elementos del DOM, pero no solo texto. La respuesta tiene que ver con el reemplazo de fuentes y es culpa de los diseñadores , no de los desarrolladores.
Toby
+1 @Toby porque realmente es culpa de los diseñadores. También es extremadamente irritante si estás en un enlace lento (como, oh, no sé, mi teléfono celular o el teléfono fijo en casa). Cosas como esas solo hacen que los sitios web sean más lentos e irritan a los usuarios sin ningún beneficio.
Magnus
1
Respuesta larga: desarrolladores, desarrolladores, desarrolladores, desarrolladores.
iono
@Toby Los diseñadores especifican qué fuentes usar, sí, pero es el trabajo de todo buen desarrollador tomar las decisiones correctas durante la implementación técnica. El buen desarrollador también entendería por qué está sucediendo (explicado en una respuesta anterior), qué opciones se pueden hacer para evitar el problema (Google Webfont Loader) y cómo eso afecta la experiencia.
Arbales
3

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.

Michael Dillon
fuente
-1

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.

usuario613326
fuente
Entonces, ¿intentas ayudar a la gente y que te voten? ¿No es divertido? Ok, lo pensaré dos veces más antes de explicar las cosas técnicas de las personas en términos simples aquí.
user613326
21
Explicaste lo incorrecto, es por eso que te votan negativamente. Como puede ver en la captura de pantalla, la página está completamente cargada, solo no se muestra el texto. Esto no tiene nada que ver con las imágenes.
Femaref
8
El cuerpo del documento casi siempre se carga antes de CSS externo. El navegador no deja de analizar la página solo para cargar contenido externo. Intentar ayudar solo es útil si realmente está siendo útil. La información errónea es peor que ninguna información.
raylu
1
@raylu No sé sobre esa información errónea. Ver una respuesta con muchos votos negativos puede ser bastante útil a veces. :-)
LarsTech
77
Hola @ user613326: alentamos el voto honesto aquí, ya que estamos aquí principalmente para proporcionar respuestas útiles para la comunidad. ¡No te lo tomes como algo personal!
Flimm