Perché i siti Web non visualizzano immediatamente il loro testo in questi giorni?

Ho notato che recentemente molti siti Web sono lenti a visualizzare il loro testo. Di solito, lo sfondo, le immagini e così via verranno caricati, ma senza testo. Dopo qualche tempo il testo inizia ad apparire qua e là (non sempre tutto allo stesso tempo).

Fondamentalmente funziona l'opposto come una volta, quando il testo veniva visualizzato per primo, quindi le immagini e il resto venivano caricate in seguito. Quale nuova tecnologia sta creando questo problema? Qualche idea?

Nota che sono su una connessione lenta, che probabilmente accentua il problema.

Vedi sotto per un esempio: tutto è caricato ma ci vogliono alcuni secondi prima che il testo venga finalmente visualizzato:

Uno dei motivi è che ai web designer oggigiorno piace usare i caratteri web (di solito in formato WOFF ), ad esempio tramite i caratteri Web di Google .

In precedenza, gli unici caratteri che potevano essere visualizzati su un sito erano quelli installati localmente dall'utente. Dal momento che, ad esempio, gli utenti di Mac e Windows non hanno necessariamente gli stessi caratteri, i progettisti istintivamente hanno sempre definito le regole di

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

dove, se il primo carattere non fosse stato trovato sul sistema, il browser avrebbe cercato il secondo, e infine un carattere "sans-serif" di fallback.

Ora, si può dare un URL di carattere come regola CSS per fare in modo che il browser scarichi un carattere, come tale:

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

e quindi caricare il carattere per un elemento specifico, ad esempio:

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

Questo è molto popolare per essere in grado di utilizzare caratteri personalizzati, ma porta anche al problema che non viene visualizzato alcun testo fino a quando la risorsa non è stata caricata dal browser, che include il tempo di download, il tempo di caricamento del carattere e il tempo di rendering. Mi aspetto che questo sia il manufatto che stai vivendo.

Ad esempio: uno dei miei giornali nazionali, Dagens Nyheter , usa i caratteri web per i loro titoli, ma non i loro contatti, quindi quando quel sito viene caricato di solito vedo i primi, e mezzo secondo dopo tutti gli spazi vuoti sopra sono popolati con titoli (questo è vero su Chrome e Opera, almeno. Non ne ho provati altri).

(Inoltre, i designer spruzzano JavaScript assolutamente ovunque in questi giorni, quindi forse qualcuno sta cercando di fare qualcosa di intelligente con il testo, motivo per cui è in ritardo. Sarebbe molto specifico per il sito, però: la tendenza generale del testo a essere ritardato in questi volte è il problema dei caratteri web sopra descritto, credo.)

aggiunta

Questa risposta è diventata molto votata, anche se non sono entrato nei dettagli, o forse per questo. Ci sono stati molti commenti nel thread delle domande, quindi proverò ad espandermi un po '(molti commenti sembrano essere scomparsi poco dopo la protezione dell'argomento - alcuni moderatori probabilmente li hanno puliti manualmente). Inoltre, leggi le altre risposte in questo thread mentre si espandono a modo loro.

Il fenomeno è apparentemente noto come "lampo di contenuto non stilato" in generale e "lampo di testo non stilato" in particolare. La ricerca di "FOUC" e "FOUT" fornisce ulteriori informazioni.

Posso consigliare il post del web designer Paul Irish su FOUT in relazione ai font web .

Ciò che si può notare è che diversi browser lo gestiscono in modo diverso. Ho scritto sopra che avevo testato Opera e Chrome, che si sono comportati entrambi in modo simile. Tutti quelli a base di WebKit (Chrome, Safari, etc.) scelgono di evitare FOUT da non il rendering del testo carattere web con un carattere di ripiego durante il periodo di web carattere carico. Anche se il font web è memorizzato nella cache, ci sarà un ritardo nel rendering . Ci sono molti commenti in questo thread di domande che dicono il contrario e che è assolutamente sbagliato che i caratteri memorizzati nella cache si comportino in questo modo, ma ad esempio dal link sopra:

In quali casi otterrai un FOUT

• Volontà: download e visualizzazione di un ttf / otf / woff remoto
• Will: Visualizzazione di un ttf / otf / woff memorizzato nella cache
• Volontà: download e visualizzazione di un uri ttf / otf / woff
• Will: Visualizzazione di un uri ttf / otf / woff memorizzato nella cache
• Non: visualizzazione di un carattere già installato e denominato nel proprio stack di caratteri tradizionale
• Non: visualizzazione di un carattere installato e denominato utilizzando la posizione locale ()

Poiché Chrome attende che il rischio FOUT sia passato prima del rendering, ciò comporta un ritardo. In che misura l'effetto è visibile (specialmente quando si carica dalla cache) sembra dipendere tra l'altro dalla quantità di testo che deve essere reso e forse da altri fattori, ma la memorizzazione nella cache non rimuove completamente l'effetto.

In fondo al post, Irish ha anche alcuni aggiornamenti sul comportamento del browser dal 2011 al 14-14:

• Firefox (a partire da FFb11 e FF4 Final) non ha più un FOUT! Wooohoo! http://bugzil.la/499292 Fondamentalmente il testo è invisibile per 3 secondi, quindi ripristina il carattere di fallback. Il webfont probabilmente si caricherà entro quei tre secondi però ... si spera ...
• IE9 supporta WOFF, TTF e OTF (anche se richiede un set di bit di incorporamento , per lo più moot se si utilizza WOFF). PERÒ!!! IE9 ha un FOUT. :(
• Webkit ha una patch in attesa di atterrare per mostrare il testo di fallback dopo 0,5 secondi. Lo stesso comportamento di FF ma 0,5 secondi anziché 3 secondi.
• Aggiunta : Blink ha registrato un bug anche per questo , ma sembra che non sia stato raggiunto un consenso finale su cosa fare con esso - attualmente la stessa implementazione di WebKit.

Se questa fosse una domanda rivolta ai progettisti, si potrebbe cercare di evitare questo tipo di problemi webfontloader, ma sarebbe un'altra domanda. Il link Paul Irish approfondisce ulteriormente la questione.

La ragione di ciò è che il testo che non puoi ancora leggere è il rendering con un font web che sta ancora scendendo dai tubi al tuo browser.

Inoltre, poiché il tuo browser è Google Chrome, che utilizza WebKit per il rendering della pagina, è stato deciso da loro (WebKit cioè) che è meglio per te non vedere alcun testo fino a quando non viene scaricato il font web. Se, tuttavia, sei uno sviluppatore che preferisce invece che il testo sia leggibile in un font di sistema di riserva adatto, allora puoi utilizzare qualcosa come Google WebFont Loader di Google per raggiungere questo obiettivo.

Risposta breve: AJAX o WOFF

Esistono diverse cause per cui i siti Web sono "lenti a visualizzare il loro testo" . La lentezza su portableapps.com è causata dal download dei caratteri WOFF . Tuttavia, ciò che descrivi come "il testo inizia ad apparire qua e là" è più spesso causato da AJAX .

Un sito Web è composto da molte parti. Il modo in cui queste parti vengono scaricate e assemblate è una scelta progettuale sotto il controllo del web designer . La lentezza è causata da come lo sviluppatore sceglie di assemblare i seguenti blocchi:

• Pagina HTML iniziale
• CSS
• JS
• immagini
• Caratteri WOFF
• Richieste AJAX
• Manipolazione DOM

Tradizionalmente siti Web:

Tradizionalmente, era comune per gli sviluppatori inserire il contenuto del testo nella pagina HTML iniziale e visualizzarlo non appena era disponibile . L'HTML farebbe riferimento a diverse risorse che sarebbero state scaricate. Il browser ridisegnerebbe progressivamente lo schermo per includere gli stili e le immagini non appena disponibili. AJAX e WOFF non erano disponibili.

Siti Web WOFF:

I caratteri WOFF consentono a un sito Web di utilizzare caratteri normalmente non disponibili per il browser, scaricando i caratteri con il sito Web . Alcuni sviluppatori indicano al browser di non visualizzare il contenuto del testo fino a quando non sono stati scaricati tutti i caratteri WOFF. Nella mia esperienza, questo approccio non ha ancora ottenuto un uso molto ampio.

Siti Web AJAX:

Alcuni sviluppatori scelgono di non includere il contenuto del testo nella pagina HTML iniziale. Invece, scelgono di scaricare il contenuto del testo usando AJAX. Questo succede dopo che la pagina di base è stata caricata . Nella mia esperienza, questo metodo ha ottenuto un'adozione molto più ampia rispetto ai caratteri WOFF ed è spesso la causa della lentezza che descrivi.

Determinare la causa

Per determinare la causa di un sito specifico è necessaria un'analisi utilizzando strumenti come Firebug o Chrome Developer Tools . In alternativa, è possibile aprire il sito utilizzando Internet Explorer 8 , che supporta AJAX ma non WOFF. Se il sito è ancora lento, il problema è AJAX e non WOFF.

Spesso posso essere una scelta deliberata per evitare il "lampo di contenuti non elaborati". Se il testo visualizzato prima che il CSS fosse caricato, lo vedresti brevemente come appare grezzo e quindi un flash mentre il browser lo ridisegna. Inserendo alcuni stili in linea di base per nascondere inizialmente il contenuto, che vengono sovrascritti nel foglio di stile reale o usando JS, gli sviluppatori evitano questo flash.

Come altri hanno notato, i caratteri personalizzati stanno probabilmente contribuendo al ritardo.

Per dare un po 'più di sfondo, il browser sta effettuando all'incirca quanto segue prima di poter visualizzare il contenuto della pagina sullo schermo:

1. recuperare HTML (diversi round trip per DNS, TCP, richiesta / risposta)
2. iniziare a analizzare HTML, scoprire risorse esterne come CSS e JS esterni. Si noti che CSS blocca il layout e JS blocca l'analisi. Pertanto, risorse esterne come CSS e JS caricate all'inizio del documento (ad es. In testa) rallentano il tempo impiegato da una pagina per visualizzare il contenuto sullo schermo.
3. recupera CSS e JS esterni (diversi round trip: DNS e TCP se queste risorse si trovano su un dominio diverso come CDN, nonché un RTT per la richiesta / risposta)
4. una volta terminato il caricamento di CSS e JS esterni, analizzare / eseguire JS, analizzare / applicare stili
5. se il CSS fa riferimento a caratteri personalizzati, anche questi caratteri devono ora essere scaricati, con conseguenti ulteriori ritardi di andata e ritorno per il rendering di qualsiasi parte della pagina che dipende dai caratteri personalizzati

Sebbene non si tratti dei ritardi causati in particolare dai caratteri personalizzati, di recente ho scritto un post sul blog che fornisce ulteriori informazioni sulle cause dei ritardi di rendering. Fornisce alcuni suggerimenti per ridurre al minimo il tempo di prima pittura per le tue pagine. Speriamo che questo sia utile per i lettori interessati a rendere più veloce la visualizzazione dei contenuti delle loro pagine, comprese quelle che desiderano utilizzare caratteri personalizzati: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -un secondo/

Risposta breve: sviluppatori.

Quando i tag di link e script che fanno riferimento a documenti esterni (come file .css o .js) vengono posizionati nella testa del documento (più in alto nel flusso rispetto al corpo e ai suoi elementi), vengono caricati per primi. JavaScript viene eseguito dal markup che lo fa riferimento; se c'è molto codice da elaborare, o è un codice ingombrante, o più comunemente se il testo che ti aspetti di essere visualizzato viene reso su un server e popolato nel documento al caricamento - e anche quel codice lato server è ingombrante, I / O di grandi dimensioni o bloccante a causa dell'elaborazione di diverse richieste simultanee, è possibile notare sicuramente tempi di inattività prima che l'HTML abbia avuto la possibilità di eseguire il rendering. Alcuni sviluppatori scelgono di caricare JavaScript non correlato alla vista dopo il markup e gli stili (alla fine del corpo),

La velocità della connessione Internet gioca un ruolo nel download lento dei dati, ovviamente, ma il codice scritto male o gli stack tecnologici mal progettati (per il tipo di sito Web) svolgono un ruolo sempre più centrale nel caricamento lento di contenuti dinamici, come connessioni di rete più veloci approccio all'ubiquità.

In breve, troppi oggetti caricabili che devono essere caricati da GET HTTP separati prima di poter visualizzare la pagina e una dipendenza eccessiva dalla latenza media come misura della salute del sito.

Il primo si riferisce a tutti quei .css, .js e webfonts caricati dalla pagina, per non parlare del fatto che molti siti devono anche recuperare oggetti JSON per richieste XHR e quindi generare HTML da quelli che usano un qualche tipo di template.

Ma perché non notano che il sito è lento?

Probabilmente perché hanno memecache lì da qualche parte per accelerare le cose (o semplicemente fare affidamento sulle cache del filesystem) e stanno misurando lo stato del loro sito usando una latenza media. Pertanto, gli oggetti memorizzati nella cache vengono restituiti con una latenza di 6 mircrosecondi e mascherano il fatto che molte richieste GET impiegano 5000 millisecondi per essere completate. Le medie devono morire. Lunga vita al conteggio degli RTT su una soglia massima accettabile! Tale numero dovrebbe essere 0 o, per definizione, la RTT è inaccettabile.

Bene ci sono molte ragioni. Uno dei motivi è anche che i comandi per definire uno sfondo o in cima a una pagina HTML spesso o recuperati in un CSS separato che viene caricato per primo. prima che venga caricato il corpo del documento che contiene il testo.

Un'altra causa è che sebbene sia possibile digitare la dimensione di un'immagine nella maggior parte dei casi i web designer non ne fanno uso. E così il brouwser deve caricare prima le immagini intere sulle pagine in modo che sappia come avvolgerle attorno.

Alcuni designer, vogliono anche mostrare le prime immagini e il testo successivo, lo ottengono con alcuni javascript, quindi ad esempio una semplice pagina mostrerà prima un banner e poi tutto il resto su di esso.

Ma se ti stai chiedendo perché ci sono così tante cose commerciali di spam sulle mie pagine mentre voglio solo leggere le notizie, allora c'è una soluzione per te. È possibile utilizzare i bloccanti dello spam se si utilizza Firefox. Con un tale componente aggiuntivo il webrowser conosce i siti che forniscono spam e li blocca semplicemente, causando un caricamento della pagina molto più veloce, mentre sei ancora in grado di vedere le immagini importanti relative agli articoli che leggi.

Consiglierei a tutti voi che affrontate il caricamento lento della pagina per provare fidler. fidler può essere usato con IEexplorer o FireFox (usando la sua funzione proxy) Fidler ti mostrerà effettivamente quanto tempo impiega effettivamente e quando vengono caricate parti di una pagina web. È uno strumento di debug HTML.