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

Question

Tenho notado que recentemente muitos sites demoram a exibir seu texto. Normalmente, o fundo, as imagens e assim por diante serão carregados, mas não haverá texto. Depois de algum tempo, o texto começa a aparecer aqui e ali (nem sempre tudo ao mesmo tempo).

Funciona basicamente ao contrário, quando o texto foi exibido primeiro, depois as imagens e o restante foram carregados depois. Que nova tecnologia está criando esse problema? Alguma idéia?

Note que estou em uma conexão lenta, o que provavelmente acentua o problema.

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

    

Answer 1

Uma razão é que os web designers hoje em dia gostam de usar fontes da web (geralmente no formato WOFF ), por exemplo através das fontes do Google Web .

Anteriormente, as únicas fontes que podiam ser exibidas em um site eram aquelas que o usuário tinha instalado localmente. Desde e. Os usuários de Mac e Windows não tinham necessariamente as mesmas fontes, os designers instintivamente sempre 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 fonte e, por último, uma fonte "sans-serif" alternativa.

Agora, é possível fornecer uma URL de fonte como uma regra de CSS para que o navegador baixe uma fonte, como:

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

e, em seguida, carregue a fonte de 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é que o recurso tenha sido carregado pelo navegador, o que inclui o tempo de download, o tempo de carregamento da fonte e a renderização. Tempo. Espero que este seja o artefato que você está experimentando.

Como exemplo: um dos meus jornais nacionais, o Dagens Nyheter , usa fontes da Web para suas manchetes, mas não suas indicações, então quando esse site é carregado, eu geralmente vejo os leads 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, designers espalham JavaScript absolutamente em qualquer lugar nos dias de hoje, 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 de texto ser atrasado nestes tempos é o problema de fontes da web descrito acima, eu acredito.)

Adição

Essa resposta ficou muito defendida, embora eu não tenha entrado em muitos detalhes, ou talvez porque disso. Houve muitos comentários no tópico da questão, então vou tentar expandir um pouco (muitos comentários parecem ter desaparecido pouco depois de o tópico ser protegido - 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. Procurando por "FOUC" e "FOUT" dá mais informações.

Eu posso recomendar o web designer Paul Irish post sobre FOUT em conexão com fontes da web .

O que se pode notar é que diferentes navegadores lidam com isso de maneira diferente. Eu escrevi acima que eu tinha testado o Opera e Chrome, que se comportaram de forma semelhante. Todos os baseados no WebKit (Chrome, Safari, etc.) optam por evitar o FOUT por não a renderização do texto da fonte da Web com uma fonte de fallback durante o período de carregamento da fonte da web. Mesmo se a fonte da Web estiver em cache, será um atraso de renderização . Há muitos comentários neste encadeamento de pergunta dizendo o contrário e é totalmente errado que as fontes armazenadas em cache se comportem assim, mas, por exemplo, a partir do link acima:

In what cases will you get a FOUT

• Will: Downloading and displaying a remote ttf/otf/woff
• Will: Displaying a cached ttf/otf/woff
• Will: Downloading and displaying a data-uri ttf/otf/woff
• Will: Displaying a cached data-uri ttf/otf/woff
• Will not: Displaying a font that is already installed and named in your traditional font stack
• Will not: Displaying a font that is installed and named using the local() location

Como o Chrome aguarda até que o risco FOUT desapareça antes da renderização, isso gera um atraso. Em que extensão o efeito é visível (especialmente ao carregar do cache) parece ser dependente, entre outras coisas, da quantidade de texto que precisa ser renderizado e talvez outros fatores, mas o 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 do post:

• Firefox (as of FFb11 and FF4 Final) no longer has a FOUT! Wooohoo! http://bugzil.la/499292 Basically the text is invisible for 3 seconds, and then it brings back the fallback font. The webfont will probably load within those three seconds though… hopefully..
• IE9 supports WOFF and TTF and OTF (though it requires an embedding bit set thing– mostly moot if you use WOFF). HOWEVER!!! IE9 has a FOUT. :(
• Webkit has a patch waiting to land to show fallback text after 0.5 seconds. So same behavior as FF but 0.5s instead of 3s.
• Addition: Blink has a bug registered for this too, but it seems a final consensus has not been reached regarding what to do with it - currently same implementation as WebKit.

Se essa fosse uma questão voltada para os designers, seria possível encontrar maneiras de evitar esses problemas, como webfontloader , mas isso seria outra questão. A ligação de Paul Irish é mais detalhada sobre esse assunto.

    

Answer 2

A razão para isso é que o texto que você não pode ler ainda está sendo processado com uma fonte da Web ainda está a caminho dos canos até 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 (WebKit) que é melhor você não ver nenhum texto até que a fonte da Web seja baixada. Se, no entanto, você for um desenvolvedor que preferiria que o texto fosse legível em uma fonte de sistema de fallback apropriada, você poderá usar algo como WebFont Loader do Google para conseguir isso.

    

Answer 3

Resposta curta: AJAX ou WOFF

Existem várias causas de websites sendo "lentos para exibir o texto" . A lentidão em portableapps.com é causada pelo download Fontes WOFF . No entanto, o que você descreve como "texto começa a aparecer aqui e ali" é mais frequentemente causado por AJAX .

Um site é composto de muitas partes. Como essas partes são baixadas e montadas é uma escolha de design sob o controle do web designer . A lentidão é causada por como o desenvolvedor escolhe montar os seguintes blocos de construção:

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

Tradicionalmente, websites:

Tradicionalmente, era comum os desenvolvedores colocarem o conteúdo de texto na página HTML inicial e exibi-lo assim que estivesse disponível . O HTML referenciaria vários recursos que seriam então baixados. O navegador iria então redesenhar progressivamente a tela para incluir os estilos e imagens assim que eles se tornassem disponíveis. AJAX e WOFF não estavam disponíveis.

Websites 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 tem um uso muito amplo.

Websites AJAX:

Alguns desenvolvedores optam por não incluir o conteúdo de texto na página HTML inicial. Em vez disso, eles escolhem fazer o download do conteúdo de texto usando o AJAX. Isso acontece depois que a página básica foi carregada . Na minha experiência, este método ganhou muito adoção mais ampla do que as fontes WOFF e é mais 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 Ferramentas do desenvolvedor do Google Chrome . Ou, como alternativa, você pode abrir o site usando o Internet Explorer 8 , que suporta o AJAX mas não WOFF. Se o site ainda estiver lento, o problema é AJAX e não WOFF.

    

Answer 4

Eu muitas vezes pode ser uma escolha deliberada para evitar o "flash de conteúdo unstyled". Se o texto exibido antes de o CSS ser carregado, você o verá brevemente como aparece em bruto e, em seguida, um flash enquanto o navegador o redesenha. Ao inserir alguns estilos inline básicos para ocultar inicialmente o conteúdo, que são substituídos na folha de estilo real ou usando o JS, os desenvolvedores evitam esse flash.

    

Answer 5

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

Para dar um pouco mais de fundo, o navegador está fazendo aproximadamente o seguinte para 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 HTML, descubra recursos externos, como CSS e JS externos. Observe que o CSS bloqueia o layout e o JS bloqueia a análise. Por isso, recursos externos como CSS e JS carregados no início do documento (por exemplo, na cabeça) diminuem o tempo que uma página leva para 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. quando o CSS e JS externos terminam de carregar, analisar / executar JS, analisar / aplicar estilos
5. se o CSS fizer referência a fontes personalizadas, essas fontes também terão que ser baixadas, resultando em atrasos adicionais de ida e volta para processar todas as partes da página que dependem das fontes personalizadas

Embora não seja especificamente sobre os atrasos causados por fontes personalizadas, escrevi recentemente uma postagem no blog que fornece informações adicionais sobre as causas de atrasos na renderização. Ele dá algumas sugestões para minimizar o tempo para primeiro pintar suas páginas. Espero que isso seja útil para os leitores interessados em fazer com que suas páginas exibam conteúdo mais rapidamente, incluindo aquelas páginas que desejam usar fontes personalizadas:

    

Answer 6

Resposta curta: desenvolvedores.

Quando as tags de link e de script que fazem referência a documentos externos (como arquivos .css ou .js) são colocadas na parte superior 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 se for um código complicado, ou mais comumente se o texto que você espera ver estiver sendo renderizado em um servidor e preenchido no documento durante o carregamento - e esse código do lado do servidor também é incômodo, grande, ou bloqueio de E / S devido ao processamento de várias solicitações simultâneas, você pode certamente notar tempo de inatividade antes de o HTML ter a chance de renderizar. Alguns desenvolvedores optam por carregar o JavaScript não relacionado à visualização após a marcação e os estilos (no final do corpo), e o melhor é ter mais consciência de como a decisão de tecnologia afetará a experiência do usuário quando implementada.

A velocidade de conexão com a Internet desempenha um papel no download lento de dados, obviamente, mas o código mal escrito ou as 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. conexões de rede mais rápidas aproximam a onipresença.

    

Answer 7

Em poucas palavras, muitos objetos carregáveis que precisam ser carregados de GETs HTTP separados antes da exibição da página e uma dependência excessiva da latência média como medida de integridade do site.

O primeiro refere-se a todos aqueles .css, .js e webfonts carregados pela página, sem mencionar o fato de que muitos sites também precisam recuperar objetos JSON e executar pedidos XHR e, em seguida, gerar HTML daqueles que usam algum tipo de template. .

Mas por que eles não percebem que o site está lento?

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

    

Answer 8

Bem, existem vários motivos. Uma razão também é que os comandos para definir um plano de fundo ou em cima de uma página html com freqüência Ou recuperado em um CSS separado que é carregado primeiro. antes que o corpo do documento seja carregado e contenha 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 gerador de pássaros precisa carregar as imagens inteiras primeiro nas páginas, para que elas saibam como envolver o texto em torno dele.

Alguns designers, também querem mostrar as primeiras imagens e o próximo texto, eles conseguem isso por meio de algum javascript, por exemplo, uma página simples mostrará primeiro um banner e depois todo o resto nele.

Mas se você está se perguntando por que há tanto material comercial de spam nas minhas páginas enquanto eu só quero ler as notícias, então há uma solução para você. Você pode fazer uso de bloqueadores de spam se estiver usando o firefox. Com esse addon, o webrowser conhece sites que fornecem spam e simplesmente os bloqueia, o que resulta em um carregamento de página muito mais rápido, enquanto você ainda pode ver as imagens importantes relacionadas aos artigos lidos.

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