Por que os sites não exibem imediatamente seu texto atualmente?

443

Notei que recentemente muitos sites demoram a exibir seu texto. Normalmente, o plano de fundo, as imagens e assim por diante serão carregados, mas nenhum texto. Depois de algum tempo, o texto começa a aparecer aqui e ali (nem sempre todo ao mesmo tempo).

Basicamente, funciona do contrário: quando o texto era exibido primeiro, as imagens e o restante eram carregados depois. Que nova tecnologia está criando esse problema? Qualquer ideia?

Observe que estou com uma conexão lenta, o que provavelmente acentua o problema.

Veja abaixo um exemplo - tudo está carregado, mas leva mais alguns segundos para que o texto seja finalmente exibido:

insira a descrição da imagem aqui

Laurent
fonte
72
Nesse caso específico, o PortableApps.com está usando a fonte "Ubuntu". John experimentou o OpenSans primeiro, mas mudamos para o Ubuntu rapidamente. Eu era o principal defensor da mudança ... uma maneira de solucionar o problema é instalar a família de fontes. Se você instalá-lo a partir do font.ubuntu.com, ele funcionará imediatamente.
31413 Chris Chris
21
A resposta de Daniel é reveladora. Achei que isso foi feito propositadamente para que possamos ver todos os anúncios na página.
Manoj R
1
Como várias pessoas apontaram aqui, existem infinitas razões para a renderização do texto de maneiras inesperadas, pois a renderização de uma página é limitada apenas pela imaginação do desenvolvedor / designer, o que tem acontecido pelo menos desde que os códigos de posição ANSI permitiram o boletim da década de 1980 placas para implementar bate-papos e interfaces do usuário com janelas sobrepostas e sombras projetadas. O Meebo foi um dos primeiros a reproduzir alguns desses efeitos em um navegador sem um Applet. "Funciona do contrário como costumava" simplifica demais a Internet e nem se refere a um período de tempo específico.
PJ Brunet
6
Então, por que fazer generalizações abrangentes sobre a Internet com base em uma tela aleatória de um site com um baixo ranking Alexa? A melhor resposta também faz uma afirmação ousada: "hoje em dia os designers do XYZ" devem ser copiados com alguns números reais, como "5% dos sites usam o Google Web Fonts a partir de 2012" ou o que quer que seja.
PJ Brunet
1
Mas arquivos de fonte são mantidos em cache, este site tem longa espera para o carregamento eles m.aspx pode verificar essa parte
user613326

Respostas:

482

Um dos motivos é que atualmente os designers da Web gostam de usar fontes da Web (geralmente no formato WOFF ), por exemplo, através das fontes da Web do Google .

Anteriormente, as únicas fontes que podiam ser exibidas em um site eram aquelas que o usuário instalava localmente. Como, por exemplo, usuários de Mac e Windows não tinham necessariamente as mesmas fontes, os designers sempre instintivamente definiam regras como

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

onde, se a primeira fonte não foi encontrada no sistema, o navegador procuraria a segunda e, finalmente, uma fonte "sans-serif" de fallback.

Agora, pode-se fornecer um URL da fonte como uma regra CSS para fazer com que o navegador faça o download de uma fonte, como:

@import url(http://fonts.googleapis.com/css?family=Droid+Serif:400,700);

e carregue a fonte para um elemento específico, por exemplo:

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

Isso é muito popular para poder usar fontes personalizadas, mas também leva ao problema de que nenhum texto é exibido até o recurso ter sido carregado pelo navegador, o que inclui o tempo de download, o tempo de carregamento da fonte e o tempo de renderização. Espero que este seja o artefato que você está enfrentando.

Como exemplo: um dos meus jornais nacionais, Dagens Nyheter , usa fontes da Web como manchetes, mas não seus leads; portanto, quando esse site é carregado, geralmente os vejo primeiro e, meio segundo depois, todos os espaços em branco acima são preenchidos com manchetes (isso é verdade no Chrome e no Opera, pelo menos. Não tentei outros).

(Além disso, os designers borrifam o JavaScript absolutamente em todos os lugares hoje em dia, então talvez alguém esteja tentando fazer algo inteligente com o texto, e é por isso que está atrasado. Isso seria muito específico do site: a tendência geral do texto a atrasar nesses textos. vezes, é o problema das fontes da web descrito acima, acredito.)


Adição

Essa resposta ficou muito positiva, embora eu não tenha entrado em muitos detalhes, ou talvez por causa disso. Houve muitos comentários no segmento de perguntas, então tentarei expandir um pouco (muitos comentários parecem ter desaparecido pouco tempo após a proteção do tópico - algum moderador provavelmente os limpou manualmente). Além disso, leia as outras respostas neste tópico, pois todas elas se expandem à sua maneira.

O fenômeno é aparentemente conhecido como "flash de conteúdo não estilizado" em geral e "flash de texto não estilizado" em particular. A busca por "FOUC" e "FOUT" fornece mais informações.

Posso recomendar a publicação do web designer Paul Irish no FOUT em conexão com fontes da web .

O que se pode notar é que navegadores diferentes lidam com isso de maneira diferente. Escrevi acima que havia testado o Opera e o Chrome, que se comportavam da mesma forma. Todos os baseados no WebKit (Chrome, Safari etc.) optam por evitar FOUT ao não renderizar o texto da fonte da Web com uma fonte substituta durante o período de carregamento da fonte da Web. Mesmo que a fonte da Web seja armazenada em cache, haverá um atraso na renderização . Há muitos comentários neste tópico de perguntas que dizem o contrário e que é totalmente errado que as fontes em cache se comportem assim, mas, por exemplo, no link acima:

Em que casos você receberá um FOUT

  • Will: Fazendo o download e exibindo um ttf / otf / woff remoto
  • Will: Exibindo um ttf / otf / woff em cache
  • Will: Fazendo o download e exibindo um data-uri ttf / otf / woff
  • Will: Exibindo um data-uri em cache ttf / otf / woff
  • Não: Exibindo uma fonte que já está instalada e nomeada na pilha de fontes tradicional
  • Não será: exibindo uma fonte instalada e nomeada usando o local ()

Como o Chrome aguarda até que o risco FOUT acabe antes da renderização, isso atrasa. Até que ponto o efeito é visível (especialmente ao carregar do cache) parece depender, entre outras coisas, da quantidade de texto que precisa ser renderizada e talvez de outros fatores, mas o armazenamento em cache não remove completamente o efeito.

O irlandês também tem algumas atualizações sobre o comportamento do navegador em 2011-04-14 na parte inferior da postagem:

  • O Firefox (a partir do FFb11 e FF4 Final) não possui mais um FOUT! Wooohoo! http://bugzil.la/499292 Basicamente, o texto fica invisível por 3 segundos e, em seguida, retorna a fonte de fallback. O webfont provavelmente será carregado dentro desses três segundos ... espero ...
  • O IE9 suporta WOFF e TTF e OTF (embora exija algo de conjunto de bits de incorporação - principalmente discutível se você usar WOFF). CONTUDO!!! O IE9 tem um FOUT. :(
  • O Webkit tem um patch aguardando para pousar para mostrar o texto de fallback após 0,5 segundos. O mesmo comportamento de FF, mas 0,5s em vez de 3s.
  • Além disso : o Blink também possui um bug registrado , mas parece que não foi alcançado um consenso final sobre o que fazer com ele - atualmente a mesma implementação do WebKit.

Se essa fosse uma pergunta voltada para designers, webfontloaderseria possível evitar maneiras de evitar esse tipo de problema , mas isso seria outra pergunta. O link Paul Irish entra em mais detalhes sobre esse assunto.

Daniel Andersson
fonte
7
Algum dos navegadores tentou renderizar o texto primeiro em uma fonte disponível e renderizá-lo novamente após o download da fonte preferida?
Steve Bennett
4
Oh, duh, comentar a seguinte resposta: paulirish.com/2009/fighting-the-font-face-fout
Steve Bennett
5
@ratchetfreak seria desconcertante ter a reformatação página desde as fontes provavelmente não teria o mesmo métricas
Samuel Edwin Ward
6
alguns preferem chegar à parte leitura de navegar de uma página web em vez de esperar as idades para a fonte para obter carregado
catraca aberração
@SteveBennett Tenho certeza de que é exatamente isso que o Internet Explorer 10 está fazendo. Eu nunca vi texto aparecendo mais tarde. Para mim, é sempre o texto que aparece em alguma "fonte padrão" e, alguns segundos depois, muda para a estilizada / baixada. Não tenho certeza se ele escolhe o próximo CSS ou apenas o padrão do sistema. Edit: Ah, legal, então é apenas o Webikit com o texto oculto? Eu consideraria esse comportamento chato e ruim. Existe algum navegador que ignora / oculta o carregamento progressivo de imagens?
8133 Mario Mario
117

A razão para isso é que o texto que você ainda não pode ler está sendo renderizado com uma fonte da Web que ainda está a caminho dos canais para o seu navegador.

Além disso, como seu navegador é o Google Chrome, que usa o WebKit para renderizar a página, foi decidido por eles (ou seja, WebKit) que é melhor você não ver nenhum texto até que a fonte da Web seja baixada. Se, no entanto, você é um desenvolvedor que prefere que o texto seja legível em uma fonte de sistema alternativa adequada, use algo como o WebFont Loader do Google para conseguir isso.

Marcel
fonte
Infelizmente, é uma resposta errada; se você visitar esta página uma vez, o arquivo da fonte residirá no seu caixa da web; para outras páginas deste site ou outros sites que usam essa fonte, eles serão recuperados em dinheiro.
user613326
19

Resposta curta: AJAX ou WOFF

Existem várias causas de os sites serem "lentos para exibir seu texto" . A lentidão no portableapps.com é causada pelo download de fontes WOFF . No entanto, o que você descreve como "o texto começa a aparecer aqui e ali" é mais frequentemente causado pelo AJAX .

Um site é composto de várias partes. Como essas peças são baixadas e montadas é uma opção de design sob o controle do web designer . A lentidão é causada pela maneira como o desenvolvedor escolhe montar os seguintes blocos de construção:

  • Página HTML inicial
  • CSS
  • JS
  • Imagens
  • Fontes WOFF
  • Solicitações AJAX
  • Manipulação de DOM

Tradicionalmente sites:

Tradicionalmente, era comum os desenvolvedores colocarem o conteúdo do texto na página HTML inicial e exibi-lo assim que estivesse disponível . O HTML faria referência a vários recursos que seriam baixados. O navegador então redesenhava progressivamente a tela para incluir os estilos e imagens à medida que se tornavam disponíveis. AJAX e WOFF não estavam disponíveis.


Sites da WOFF:

As fontes WOFF permitem que um site use fontes que normalmente não estão disponíveis para o navegador, baixando fontes com o site . Alguns desenvolvedores instruem o navegador a não exibir o conteúdo do texto até que todas as fontes WOFF tenham sido baixadas. Na minha experiência, essa abordagem ainda não ganhou muito uso.


Sites AJAX:

Alguns desenvolvedores optam por não incluir o conteúdo do texto na página HTML inicial. Em vez disso, eles optam por baixar o conteúdo de texto usando o AJAX. Isso acontece após o carregamento da página básica . Na minha experiência, esse método ganhou uma adoção muito mais ampla do que as fontes WOFF e é frequentemente a causa da lentidão que você descreve.


Determinando a causa

Para determinar a causa de um site específico, é necessário analisar usando ferramentas como Firebug ou Chrome Developer Tools . Ou, como alternativa, você pode abrir o site usando o Internet Explorer 8 , que suporta AJAX, mas não WOFF. Se o site ainda estiver lento, o problema é AJAX e não WOFF.

KevSheedy
fonte
14

Muitas vezes, pode ser uma escolha deliberada evitar o "flash de conteúdo não estilizado". Se o texto exibido antes do CSS for carregado, você o verá brevemente como parece bruto e depois pisca quando o navegador o redesenha. Ao colocar alguns estilos embutidos básicos para ocultar inicialmente o conteúdo, que são substituídos na folha de estilo real ou usando JS, os desenvolvedores evitam esse flash.

Greg H
fonte
6
Nove em cada dez vezes não será deliberado, é simplesmente um efeito colateral da incorporação de fontes da Web da maneira mais simples possível. De fato, é preciso um pouco de esforço extra para apresentar uma alternativa visível enquanto as fontes da Web estão descendo pelo cano. Veja developers.google.com/webfonts/docs/webfont_loader
Marcel
@Marcel - isso pode ser causado por folhas de estilo lento, bem como fontes lentas, consulte phpied.com/css-and-the-critical-path
r3m0t
O código para impedir o "flash de conteúdo útil" tende a impedir que as imagens apareçam e também o texto.
91313 Jon Hanna
Eu luto para entender por que o texto sem estilo é pior do que nenhum texto. Prefiro poder começar a ler um texto que possa balançar um pouco. Acho mais chocante quando aparece repentinamente em lugar nenhum e é muito frustrante quando uma página é carregada e você é forçado a esperar por uma fonte.
Richard Le Poidevin
8

Como outros observaram, as fontes personalizadas provavelmente estão contribuindo para o atraso.

Para fornecer um pouco mais de experiência, o navegador está fazendo aproximadamente o seguinte antes de poder renderizar o conteúdo da página na tela:

  1. buscar HTML (várias viagens de ida e volta para DNS, TCP, solicitação / resposta)
  2. comece a analisar o HTML, descubra recursos externos, como CSS e JS externos. Observe que CSS bloqueia o layout e JS bloqueia a análise. Portanto, recursos externos como CSS e JS carregados no início do documento (por exemplo, na cabeça) diminuem o tempo que leva para uma página exibir o conteúdo na tela.
  3. buscar CSS e JS externos (várias viagens de ida e volta: DNS e TCP se esses recursos estiverem em um domínio diferente, como CDN, bem como um RTT para a solicitação / resposta)
  4. Depois que o CSS e JS externos terminarem o carregamento, analise / execute JS, analise / aplique estilos
  5. se o CSS fizer referência a fontes personalizadas, essas fontes também precisarão ser baixadas, resultando em atrasos adicionais de ida e volta para renderizar qualquer parte da página que dependa das fontes personalizadas

Embora não se refira especificamente aos atrasos causados ​​por fontes personalizadas, escrevi recentemente uma postagem no blog que fornece informações adicionais sobre as causas dos atrasos na renderização. Ele fornece algumas sugestões para minimizar o tempo para pintar primeiro as suas páginas. Espero que isso seja útil para os leitores interessados ​​em tornar suas páginas mais rápidas, incluindo as páginas que desejam usar fontes personalizadas: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -um segundo/

Bryan McQuade
fonte
4

Resposta curta: Desenvolvedores.

Quando as tags de link e script que fazem referência a documentos externos (como arquivos .css ou .js) são colocadas no cabeçalho do documento (maior no fluxo que o corpo e seus elementos), elas são carregadas primeiro. JavaScript é executado a partir da marcação que faz referência a ele; se houver muito código para processar, ou for complicado, ou mais comumente, se o texto que você espera ver estiver sendo renderizado em um servidor e preenchido no documento em carga - e esse código do servidor também for complicado, E / S grande ou bloqueadora devido ao processamento de várias solicitações simultâneas, você certamente notará um tempo de inatividade antes que o HTML tenha a chance de renderizar. Alguns desenvolvedores optam por carregar o JavaScript não relacionado à visualização após marcação e estilos (no final do corpo),

A velocidade da conexão com a Internet desempenha um papel no download lento de dados, obviamente, mas códigos mal escritos ou pilhas de tecnologia mal projetadas (para o tipo de site) desempenham um papel cada vez mais central no carregamento lento de conteúdo dinâmico, como conexões de rede mais rápidas abordagem onipresente.

Benny
fonte
21
Não. O que você descreve pode impedir que elementos do DOM sejam exibidos, mas não apenas texto. A resposta está relacionada à substituição de fontes e é culpa dos designers , não dos desenvolvedores.
7603 Toby
+1 no @Toby porque realmente é culpa dos designers. Também é extremamente irritante se você estiver em um link lento (como, ah, não sei, meu telefone celular ou telefone fixo em casa). Coisas assim apenas tornam os sites mais lentos e irritam os usuários, sem qualquer benefício.
Magnus
1
Resposta longa: desenvolvedores, desenvolvedores, desenvolvedores, desenvolvedores.
iono 07/02
@Toby Os designers especificam quais fontes usar, sim, mas é o trabalho de todo bom desenvolvedor fazer as escolhas certas durante a implementação técnica. O bom desenvolvedor também entenderia por que isso está acontecendo (explicado na resposta acima), que escolhas podem ser feitas para evitar o problema (Google Webfont Loader) e como isso afeta a experiência.
Arbales
3

Em resumo, muitos objetos carregáveis ​​que precisam ser carregados de HTTP GETs separados antes que a página possa ser exibida e uma dependência excessiva da latência média como uma medida da integridade do site.

A primeira refere-se a todas as .css, .js e webfonts que a página carrega, para não mencionar o fato de que muitos sites também precisam recuperar objetos JSON através de solicitações XHR e gerar HTML a partir daqueles que usam algum tipo de modelo.

Mas por que eles não percebem que o site é lento?

Provavelmente porque eles têm um cache de memória em algum lugar para acelerar as coisas (ou apenas contam com os caches do sistema de arquivos) e estão medindo a integridade do site usando latência média. Assim, os objetos em cache são retornados com latência de 6 milcrossegundos e ocultam o fato de que muitas solicitações GET levam 5000 milissegundos para serem concluídas. As médias devem morrer. Viva a contagem de RTTs acima de um limite máximo aceitável! Esse número deve ser 0 ou, por definição, o RTT é inaceitável.

Michael Dillon
fonte
-1

Bem, existem várias razões. Uma razão também é que os comandos para definir um plano de fundo ou no topo de uma página html frequentemente ou recuperados em um CSS separado carregado primeiro. antes do corpo do documento ser carregado, que contém o texto.

Outra causa é que, embora seja possível digitar o tamanho de uma imagem, na maioria dos casos, os web designers não fazem uso disso. E assim, o brouwser precisa carregar as imagens inteiras primeiro nas páginas para saber como envolver o texto.

Alguns designers, também querem mostrar as primeiras fotos e o próximo texto, conseguem isso com algum javascript; por exemplo, uma página simples mostra primeiro um banner e depois tudo o mais.

Mas se você está se perguntando por que há tantas coisas comerciais de spam em minhas páginas enquanto eu só quero ler as notícias, então há uma solução para você. Você pode usar bloqueadores de spam se estiver usando o Firefox. Com esse complemento, o webrowser conhece sites que fornecem spam e simplesmente os bloqueia, resultando em um carregamento de página muito mais rápido, enquanto você ainda pode ver as imagens importantes relacionadas aos artigos que você lê.

Eu recomendaria a todos que lidam com o carregamento lento da página para tentar o Fidler. O fidler pode ser usado com o IEexplorer ou com o FireFox (usando sua função de proxy). O Fidler realmente mostrará quanto tempo realmente leva e quando partes de uma página da web são carregadas. É uma ferramenta de depuração HTML.

user613326
fonte
então você tenta ajudar as pessoas e ser votado não é divertido? Ok, vou pensar duas vezes novamente antes de explicar as coisas técnicas das pessoas em termos laymens aqui.
user613326
21
Você explicou a coisa errada, é por isso que você está recebendo votos negativos. Como você pode ver na captura de tela, a página está totalmente carregada, apenas o texto não é exibido. Isso não tem nada a ver com imagens.
Femaref 7/02
8
O corpo do documento quase sempre é carregado antes do CSS externo. O navegador não para de analisar a página apenas para carregar conteúdo externo. Tentar ajudar só é útil se você estiver realmente sendo útil. Desinformação é pior do que nenhuma informação.
raylu
1
@ Raylu Eu não sei sobre essa desinformação. Ver uma resposta com muitos votos negativos pode ser bastante útil às vezes. :-)
LarsTech
7
Olá @ user613326: incentivamos a votação honesta aqui, pois estamos aqui principalmente para fornecer respostas úteis para a comunidade. Não leve para o lado pessoal!
Flimm