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


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).

Basicamente, funciona exatamente como costumava fazer, quando o texto era exibido primeiro, depois as imagens e o restante estavam sendo carregados depois. Que nova tecnologia está criando esse problema? Qualquer ideia?

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:

enter image description here


440


origem


Neste caso particular, o PortableApps.com está usando a fonte "Ubuntu". John tentou o OpenSans primeiro, mas nós mudamos para o Ubuntu rapidamente. Eu era o principal proponente da mudança ... uma maneira de remover o problema é ter a família de fontes instalada. Se você instalá-lo a partir de font.ubuntu.com vai funcionar imediatamente. - Chris Morgan
A resposta de Daniel é um abridor de olhos. Eu pensei que isso é propositadamente feito para que possamos ver todos os anúncios na página. - Manoj R
Como várias pessoas apontaram aqui, existem infinitas razões para o texto ser processado de formas inesperadas, já que renderizar uma página é limitado apenas pela imaginação do desenvolvedor / designer, o que tem sido o caso pelo menos desde que os códigos de posição ANSI permitiram o boletim de 1980 placas para implementar bate-papos multiusuários e UIs com janelas sobrepostas com sombreamento. O Meebo foi um dos primeiros a reproduzir alguns desses efeitos em um navegador sem um Applet. "Funciona do modo oposto ao que costumava" simplificar muito a Internet e nem se refere a um período de tempo específico. - PJ Brunet
Então, por que fazer generalizações abrangentes sobre a Internet com base em uma capa de tela aleatória de um site com um ranking Alexa baixo? A melhor resposta também faz uma afirmação ousada: "hoje em dia os designers do XYZ" devem ter backup 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
Mas arquivos de fonte são mantidos em cache, este site tem longa espera para carregar m.aspx eles podem verificar essa parte - user613326


Respostas:


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

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

Agora, é possível fornecer uma URL de fonte como uma regra de CSS para fazer o navegador baixar 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 o tempo de renderização. Espero que este seja o artefato que você está experimentando.

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

(Além disso, os designers espalham o JavaScript em todos os lugares atualmente, 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 o texto ser atrasado nesses termos. vezes é o problema de fontes da web descrito acima, eu acredito.)


Adição

Esta resposta ficou muito defendida, embora eu não tenha entrado em muitos detalhes, ou talvez Porque disto. 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 de maneira própria.

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.

Posso recomendar 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. Todas as baseadas no WebKit (Chrome, Safari, etc.) optam por evitar o FOUT por não renderização de texto de fonte da web com uma fonte de fallback durante o período de carregamento da fonte da web. Mesmo se a fonte da Web é armazenada em cache, vai 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:

Em que casos você receberá um FOUT

  • Vai: Baixando e exibindo um remoto ttf / otf / woff
  • Vai: Exibindo um ttf / otf / woff em cache
  • Vai: Baixando e exibindo um data-uri ttf / otf / woff
  • Vai: Exibindo um dado em cache-uri ttf / otf / woff
  • Não vou: Exibindo uma fonte já instalada e nomeada em sua pilha de fontes tradicional
  • Não vou: Exibindo uma fonte que é instalada e nomeada usando o local ()

Como o Chrome aguarda até que o risco FOUT desapareça antes da renderização, isso gera um atraso. Ao qual extensão 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 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:

  • Raposa de fogo (a partir de FFb11 e FF4 Final) não tem mais FOUT! Wooohoo! http://bugzil.la/499292 Basicamente, o texto é invisível por 3 segundos e, em seguida, traz de volta a fonte de fallback. O webfont provavelmente carregará dentro desses três segundos, embora ... esperançosamente ..
  • O IE9 suporta WOFF e TTF e OTF (embora exija um pouco de incorporação  definir coisa- principalmente discutível se você usar WOFF). CONTUDO!!! IE9 tem um FOUT. :(
  • Webkit tem um patch esperando para pousar para mostrar o texto de fallback após 0,5 segundos. Então, mesmo comportamento como FF, mas 0,5s em vez de 3s.
  • Adição: Blink tem um bug registrado para isso também, 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 esta foi uma questão destinada aos designers, poder-se-ia procurar formas de evitar estes tipos de problemas, como webfontloader, mas isso seria outra questão. A ligação de Paul Irish é mais detalhada sobre esse assunto.


484



Algum dos navegadores tentou renderizar o texto primeiro em uma fonte disponível e renderizá-lo novamente quando a fonte preferida é baixada? - Steve Bennett
Ah, comentem a próxima resposta: paulirish.com/2009/fighting-the-font-face-fout - Steve Bennett
@ratchetfreak seria desconcertante ter a reformatação da página, já que as fontes provavelmente não teriam as mesmas métricas - Samuel Edwin Ward
alguns preferem chegar à parte de leitura de navegar em uma página da Web, em vez de esperar que a fonte seja carregada - ratchet freak
@SteveBennett Tenho certeza de que é exatamente isso que o Internet Explorer 10 está fazendo. Eu nunca vi o texto aparecendo mais tarde. Para mim, é sempre texto que aparece em alguma "fonte padrão" e, alguns segundos depois, ele muda para o estilo / download. Eu não tenho certeza se ele escolhe o próximo CSS ou apenas o padrão do sistema. Edit: Ah, legal, então é só o Webikit com o texto oculto? Eu consideraria esse comportamento irritante e ruim. Existe algum navegador ignorando / ocultando o carregamento de imagens progressivas? - Mario


A razão para isto é o texto que você não pode ler ainda está sendo renderizado com uma fonte da web que ainda está a caminho dos canos 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 (WebKit que é) é melhor que você não veja nenhum texto até que a fonte da Web seja baixada. Se, no entanto, você for um desenvolvedor que prefere que o texto seja legível em uma fonte de sistema de fallback adequada, você pode usar algo como WebFont Loader do Google Para alcançar isto.


117



Infelizmente é uma resposta errada, se você visitar esta página uma vez, o arquivo de fonte residiria em seu dinheiro de web; para outras páginas deste site ou outros sites usando essa fonte, ela seria recuperada de dinheiro. - user613326


Resposta curta: AJAX ou WOFF

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

Um site é composto de muitas partes. Como essas partes são baixadas e montadas é um 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
  • Pedidos AJAX
  • Manipulação DOM

Tradicionalmente sites:

Tradicionalmente, era comum os desenvolvedores colocarem o conteúdo do texto no 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 então redesenhar progressivamente a tela para incluir os estilos e imagens à medida que se tornam 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, por 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.


Sites da 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. Isto acontece depois que a página básica foi carregada. Na minha experiência, este método ganhou muito adoção mais ampla de 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 para desenvolvedores do Chrome. Ou, alternativamente, você pode abrir o site usando Internet Explorer 8, que suporta AJAX mas não WOFF. Se o site ainda estiver lento, o problema é AJAX e não WOFF.


19





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.


14



Nove entre dez vezes não será deliberado, é simplesmente um efeito colateral da incorporação de fontes da Web da maneira mais simples possível. Na verdade, é necessário um esforço extra para apresentar uma alternativa visível enquanto as fontes da Web estão descendo pelo canal. Vejo developers.google.com/webfonts/docs/webfont_loader - Marcel
@ Marcel - isso pode ser causado por folhas de estilo lentas, bem como fontes lentas, veja phpied.com/css-and-the-critical-path - r3m0t
Código para evitar o "flash de conteúdo útil", tende a impedir que as imagens apareçam, bem como o texto. - Jon Hanna
Luto para entender por que o texto não estilizado é pior do que nenhum texto. Eu prefiro ser capaz de começar a ler e aceitar que ele pode balançar um pouco. Eu acho mais chocante quando aparece de repente em nenhum lugar e é muito frustrante quando uma página é carregada e você é forçado a esperar por uma fonte. - Richard Le Poidevin


Como outros notaram, 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. começar a analisar HTML, descobrir 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. uma vez que o CSS externo e JS terminaram 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 o conteúdo mais rapidamente, incluindo aquelas páginas que desejam usar fontes personalizadas: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/


8





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 cabeça do documento (mais alto 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 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 da ubiquidade.


4



Não - o que você descreve pode impedir que elementos do DOM sejam exibidos, mas não apenas texto. A resposta está relacionada com a substituição de fontes e é a culpa dos designersnão desenvolvedores. - Toby
+1 @Toby porque realmente é culpa dos designers. É extremamente irritante também se você estiver em um link lento (como, oh, eu não sei, meu celular ou o telefone fixo em casa). Coisas assim apenas tornam os sites mais lentos e irritam os usuários sem nenhum benefício. - Magnus
Resposta longa: desenvolvedores, desenvolvedores, desenvolvedores e desenvolvedores. - iono
@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


Em poucas palavras, muitos objetos carregáveis ​​que precisam ser carregados de GETs HTTP separados antes da exibição da página, além de 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 que a página carrega, sem mencionar o fato de que muitos sites também precisam recuperar objetos JSON e executar solicitações XHR e, em seguida, gerar HTML daqueles que usam algum tipo de modelo.

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 do 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.


3





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 criador tem que carregar as imagens inteiras primeiro nas páginas para que ele saiba como envolver o texto em volta 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.

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 existe 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, 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 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.


-1



então você tenta ajudar as pessoas e descer não é tão divertido? Ok, eu vou pensar duas vezes antes de explicar as coisas técnicas de pessoas em termos laymens aqui. - user613326
Você explicou a coisa errada, é por isso que você está sendo derrotado. 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
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 ajudando. A desinformação é pior que nenhuma informação. - raylu
@raylu Eu não sei sobre essa desinformação. Vendo uma resposta com um monte de downvotes pode ser bastante útil às vezes. :-) - LarsTech
Oi @ user613326: nós encorajamos o downvoting honesto aqui, já que estamos aqui para fornecer respostas úteis para a comunidade. Não tome isso pessoalmente! - Flimm