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


Me di cuenta de 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 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 el texto finalmente se muestre:

enter image description here


440


origen


En este caso particular, PortableApps.com está usando la fuente "Ubuntu". John intentó OpenSans primero, pero cambiamos a Ubuntu bastante rápido. Yo 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
La respuesta de Daniel es revelador. Pensé que esto se hizo a propósito para que podamos ver todos los anuncios en la página. - Manoj R
Como varias personas han señalado aquí, hay infinitas razones para que el texto se represente de forma inesperada, ya que renderizar una página solo está limitado por la imaginación del desarrollador / diseñador, que ha sido el caso al menos desde que los códigos de posición de ANSI permitieron el boletín de los 80. tableros para implementar chats multiusuario e IU con ventanas superpuestas con sombras paralelas. Meebo fue uno de los primeros en reproducir algunos de estos efectos en un navegador sin un Applet. "Funciona al revés, ya que solía" simplificar demasiado el Internet y ni siquiera se refiere a un período de tiempo específico. - PJ Brunet
Entonces, ¿por qué hacer amplias generalizaciones sobre Internet basadas en un límite de pantalla aleatorio de un sitio web con un rango bajo de Alexa? La mejor respuesta también hace una afirmación audaz: "los diseñadores de hoy en día XYZ" deben respaldarse con algunos números reales, como "el 5% de los sitios web usan Google Web Fonts a partir de 2012" o lo que sea. - PJ Brunet
Pero los archivos de fuentes se guardan en el caché, este sitio tiene una larga espera para cargar m.aspx, pueden verificar esa parte - user613326


Respuestas:


Una razón es que a los diseñadores web hoy en día les gusta usar fuentes web (generalmente en WOFF formato), p. mediante Google Web fonts.

Anteriormente, las únicas fuentes que se podían mostrar en un sitio eran aquellas que el usuario había instalado localmente. Desde, por ejemplo, Los usuarios de Mac y Windows no necesariamente tienen las mismas fuentes, los diseñadores instintivamente siempre definieron 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 finalmente una fuente "sans-serif" alternativa.

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 carga la fuente para un elemento específico por ej .:

font-family: '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 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, use las fuentes web para sus titulares, pero no sus clientes potenciales, de modo que cuando ese sitio está cargado, generalmente veo los clientes potenciales primero, y medio segundo después todos los espacios en blanco de arriba están llenos de titulares (esto es cierto en Chrome y Opera, en menos. No he probado otros).

(Además, los diseñadores rocían JavaScript absolutamente en todas partes en estos días, así 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 texto 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 detalles, o tal vez porque de esta. Ha habido muchos comentarios en el hilo de preguntas, así que trataré de expandirlo un poco (muchos comentarios parecen haber desaparecido poco tiempo después de que el tema fue protegido; algunos moderadores probablemente los limpiaron manualmente). Además, lea las otras respuestas en este hilo, ya que todas se expanden a su manera.

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 por no Renderizar 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é, hay será ser un retraso de render. 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. del enlace de arriba:

¿En qué casos obtendrás un FOUT

  • Será: Descargando y mostrando un ttf / otf / woff remoto
  • Será: Visualización de un ttf / otf / woff en caché
  • Será: Descargando y mostrando un data-uri ttf / otf / woff
  • Será: Visualización de un dato almacenado en memoria caché ttf / otf / woff
  • No lo hará: Mostrar una fuente que ya está instalada y nombrada en su pila tradicional de fuentes
  • No lo hará: Mostrar una fuente que está instalada y nombrada usando la ubicación local ()

Dado que Chrome espera hasta que el riesgo de FOUT haya desaparecido antes de la renderización, esto genera un retraso. A la que grado el efecto es visible (especialmente cuando se carga 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 relacionadas con 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. El webfont probablemente cargará dentro de esos tres segundos ... espero ...
  • IE9 admite WOFF y TTF y OTF (aunque requiere un bit de incrustación  establecer cosa- Casi imposible si usas WOFF). ¡¡¡SIN EMBARGO!!! IE9 tiene un FOUT. :(
  • Webkit tiene un parche esperando aterrizar para mostrar el texto alternativo después de 0.5 segundos. El mismo comportamiento que FF pero 0.5s en vez de 3s.
  • Adición: Blink tiene un error registrado para esto también, pero parece que no se llegó a un consenso final sobre qué hacer con él, actualmente la misma implementación que WebKit.

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


484



¿Alguno de los navegadores intentó renderizar el texto primero en una fuente disponible y volver a representarlo una vez que se descargó la fuente preferida? - Steve Bennett
Oh, duh, comenta la siguiente respuesta: paulirish.com/2009/fighting-the-font-face-fout - Steve Bennett
@ratchetfreak sería desconcertante tener que reformatear la página ya que las fuentes probablemente no tendrían las mismas métricas - Samuel Edwin Ward
algunos preferirían llegar a la parte de lectura de navegar en una página web en lugar de esperar años para que la fuente se cargue - ratchet freak
@SteveBennett Estoy bastante seguro de que eso es exactamente lo que está haciendo Internet Explorer 10. Nunca he visto texto apareciendo más adelante. Para mí, siempre aparece el texto en alguna "fuente estándar" y unos segundos después cambia al estilo / descargado. No estoy seguro de si elige el siguiente CSS o solo el predeterminado del sistema. Editar: Ah, bien, ¿es solo Webikit con el texto oculto? Consideraría ese comportamiento molesto y malo. ¿Hay algún navegador ignorando / ocultando la carga progresiva de imágenes? - Mario


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

Además, dado que su navegador es Google Chrome, que utiliza WebKit para representar la página, fue decidido por ellos (WebKit es) que es mejor que no veas ningún texto hasta que la fuente web esté descargada. Sin embargo, si eres un desarrollador que prefiere que el texto sea legible en una fuente de sistema de recuperación adecuada, entonces puedes usar algo como El cargador de WebFont de Google lograr esto.


117



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


Respuesta corta: AJAX o WOFF

Existen varias causas de sitios web siendo "lento para mostrar su texto". La lentitud en portableapps.com es causado por la descarga WOFF fuentes Sin embargo, lo que describes como "el texto comienza a aparecer aquí y allá" es más a menudo causado por AJAX.

Un sitio web se compone de muchas partes. Cómo se descargan y ensamblan estas piezas es una elección de diseño bajo el control de la diseñador web. La lentitud se debe a la forma en que el desarrollador elige armar los siguientes bloques de construcción:

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

Tradicionalmente sitios web:

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


Sitios web de WOFF:

Las fuentes WOFF permiten que un sitio web utilice fuentes que normalmente no están disponibles para el navegador, por descarga de fuentes con el sitio web. Algunos desarrolladores ordenan al navegador que no muestre el contenido de texto hasta que se hayan descargado todas las fuentes WOFF. En mi experiencia, este enfoque no ha tenido un uso muy amplio todavía.


Sitios web de AJAX:

Algunos desarrolladores eligen no incluir el contenido de texto en la página HTML inicial. En cambio, eligen descargar el contenido de texto usando AJAX. Esto pasa después de que la página básica ha sido cargada. En mi experiencia, este método ha ganado mucho adopción más amplia que las fuentes de WOFF y es a menudo la causa de la lentitud que describes.


Determinando la Causa

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


19





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


14



Nueve de cada diez veces no será deliberado, es simplemente un efecto secundario de incrustación de fuentes web de la manera más simple posible. De hecho, se requiere un pequeño esfuerzo adicional para presentar una alternativa visible mientras las fuentes de la web caen por la tubería. Ver developers.google.com/webfonts/docs/webfont_loader - Marcel
@Marcel: esto puede deberse a las hojas de estilo lentas y a las fuentes lentas, ver phpied.com/css-and-the-critical-path - r3m0t
El código para evitar el "flash 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 no tener texto. Prefiero ser capaz de comenzar a leer y aceptar que podría sacudirse un poco. Me parece más discordante cuando aparece de repente para nada y es muy frustrante cuando una página se ha cargado y estás obligado a esperar por una fuente. - Richard Le Poidevin


Como otros han notado, es probable que las fuentes personalizadas contribuyan a la demora.

Para dar un poco más de antecedentes, el navegador está haciendo aproximadamente lo siguiente antes de que pueda mostrar el contenido de la página a la pantalla:

  1. buscar HTML (varios recorridos de ida y vuelta para DNS, TCP, solicitud / respuesta)
  2. comenzar a analizar HTML, descubrir 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 cabecera) reducen la velocidad del tiempo que le lleva a una página mostrar contenido en la pantalla.
  3. buscar CSS y JS externos (varios viajes redondos: 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 los 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 también tienen que descargarse, lo que resulta en retrasos adicionales de ida y vuelta para representar cualquier parte de la página que dependa de las fuentes personalizadas.

Aunque no se trata de las demoras causadas específicamente por las fuentes personalizadas, recientemente escribí una publicación en el blog que brinda información adicional sobre las causas de los retrasos en el procesamiento. Le da algunas sugerencias para minimizar el tiempo de pintar sus páginas por primera vez. Es de esperar que esto sea útil para los lectores interesados ​​en hacer que sus páginas muestren el 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-one-second/


8





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 lo hace referencia; si hay que procesar un gran número de código, o es engorroso, o más comúnmente si el texto que espera ver se procesa en un servidor y se rellena en el documento al cargarse, y ese código del lado del servidor también es engorroso, E / S de gran tamaño o bloqueante debido al procesamiento de varias solicitudes concurrentes, es posible que observe un tiempo de inactividad antes de que el HTML haya tenido la oportunidad de representarse. Algunos desarrolladores eligen cargar JavaScript no relacionado con la vista después del marcado y los estilos (al final del cuerpo), y lo mejor es tratar de ser más conscientes de cómo su decisión tecnológica afectará la experiencia general del usuario cuando se implemente.

La velocidad de conexión a Internet juega un papel en la lenta descarga 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, como conexiones de red más rápidas acercarse a la ubicuidad


4



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


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 los archivos .css, .js y webfonts que carga la página, por no mencionar el hecho de que muchos sitios también necesitan recuperar objetos JSON viea 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 dependen de los cachés del sistema de archivos) y están midiendo el estado de su sitio usando la latencia promedio. Por lo tanto, los objetos en caché se devuelven con una latencia de 6 microsegundos y enmascaran el hecho de que muchas solicitudes GET tardan 5000 milisegundos en completarse. Los promedios deben morir. ¡Larga vida al conteo de RTTs sobre un umbral máximo aceptable! Ese número debe ser 0 o, por definición, el RTT es inaceptable.


3





Bueno, hay múltiples razones. Una razón también es que los comandos para definir un fondo o en la parte superior de una página html a menudo O recuperado 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 la utilizan. Y entonces, el brouwser tiene que cargar las imágenes completas primero en las páginas para que sepa cómo ajustar el texto a su alrededor.

Algunos diseñadores, también quieren mostrar las primeras imágenes y el texto siguiente, lo logran mediante javascript, por ejemplo, una página simple primero mostrará 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, y solo quiero leer las noticias, entonces hay una solución para usted. Puede usar bloqueadores de spam si usa Firefox. Con dicho complemento, el navegador web conoce los sitios que proporcionan correo no deseado y simplemente los bloquea, lo que genera una carga de página mucho más rápida, mientras que usted todavía puede ver las imágenes importantes relacionadas con los artículos que lee.

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


-1



entonces, ¿intentas ayudar a la gente y votar? ¿No es divertido? Ok, lo pensaré dos veces antes de explicar las cosas técnicas de la gente en términos de legos aquí. - user613326
Explicaste lo incorrecto, es por eso que estás siendo rechazado. Como puede ver en la captura de pantalla, la página está completamente cargada, solo el texto no se muestra. Esto no tiene nada que ver con las imágenes. - Femaref
El cuerpo del documento casi siempre se carga antes de CSS externo. El navegador no detiene el análisis de la página solo para cargar contenido externo. Tratar de ayudar solo es útil si realmente estás siendo útil. La desinformación es peor que la falta de información. - raylu
@raylu No sé acerca de esa desinformación. Ver una respuesta con muchos downvotes puede ser bastante útil a veces. :-) - LarsTech
Hola @ usuario613326: alentamos la votación honesta hacia abajo, ya que estamos aquí principalmente para proporcionar respuestas útiles para la comunidad. ¡No lo tomes como algo personal! - Flimm