Perché le pagine Web non mostrano immediatamente il loro testo?

Se sei incline a guardare il riquadro del browser con un occhio d'aquila, potresti aver notato che le pagine caricano frequentemente le immagini e il layout prima di caricare il loro testo, il modello di caricamento esattamente opposto che abbiamo sperimentato negli anni '90.Cosa sta succedendo?

Today's Question &La sessione di risposta ci viene fornita per gentile concessione di SuperUser, una suddivisione di Stack Exchange, un raggruppamento di Q & A basato su community.

La domanda

SuperUser reader Laurent è molto curioso di sapere perché esattamente le pagine sembrano caricare gli elementi in modo completamente diverso rispetto a una volta. Scrive:

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

Fondamentalmente funziona al contrario come prima, quando il testo veniva visualizzato per primo, poi le immagini e il resto veniva caricato in seguito. Quale nuova tecnologia sta creando questo problema? Qualche idea?

Si noti che sono in una connessione lenta, che probabilmente accentua il problema.

Vedi [sopra] per un esempio: tutto è caricato ma ci vogliono ancora alcuni secondi prima che il testo venga finalmente visualizzato.

Quindi cosa dà?Laurent, e molti di noi, ricordano un tempo in cui il testo veniva caricato per primo e tutte le altre GIF animate, gli sfondi piastrellati e tutti gli altri artefatti della navigazione web degli ultimi anni '90 venivano in seguito. Che cosa causa la situazione attuale degli elementi di design, testo dopo?

The Answer

Il collaboratore di SuperUser Daniel Andersson offre una risposta meravigliosamente dettagliata che arriva direttamente al mistero del perché-i-caratteri-carico-ultimo:

Una ragione è che ai web designer oggigiorno piace usare i font web( di solito in formato WOFF), per esempioattraverso i font Web di Google.

In precedenza, i soli caratteri che potevano essere visualizzati su un sito erano quelli che l'utente aveva installato localmente. Poiché ad es. Gli utenti Mac e Windows non avevano necessariamente gli stessi caratteri, i progettisti istintivamente definivano sempre le regole come famiglia di font

: Arial, Helvetica, sans-serif;

dove, se il primo font non è stato trovato sul sistema, il browser cercherebbe il secondo e infine un font "sans-serif" di fallback.

Ora, si può dare un URL di carattere come regola CSS per ottenere il browser per scaricare un font, come tale:

URL @import( http: //fonts.googleapis.com/ css? Family = Droid + Serif: 400.700);

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

: '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 finché la risorsa non è stata caricata dal browser, che include il tempo di download, il tempo di caricamento dei font e il tempo di rendering. Mi aspetto che questo sia l'artefatto che stai vivendo.

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

( Inoltre, i designer spargono JavaScript assolutamente dappertutto in questi giorni, quindi forse qualcuno sta cercando di fare qualcosa di intelligente con il testo, motivo per cui è in ritardo. Ciò sarebbe molto specifico per il sito, tuttavia: la tendenza generale del ritardo del testo inquesti tempi è il problema dei font web descritto sopra, credo.)

Aggiunta:

Questa risposta è diventata molto upvoted, anche se non sono andato molto nei dettagli, o forse perché di questo. Ci sono stati molti commenti nel thread di domande, quindi cercherò di espandere un po '[...]

Il fenomeno è apparentemente noto come "flash di contenuto non animato" in generale, e "flash di testo non animato" in particolare. La ricerca di "FOUC" e "FOUT" fornisce maggiori informazioni.

Posso raccomandare il post del web designer Paul Irish su FOUT in connessione con i caratteri web.

Quello che si può notare è che i diversi browser gestiscono diversamente. Ho scritto sopra che avevo testato Opera e Chrome, che si comportavano entrambi allo stesso modo. Tutti quelli basati su WebKit( Chrome, Safari, ecc.) Scelgono di evitare FOUT da , non , rendendo il testo del font web con un font di fallback durante il periodo di caricamento dei font web. Anche se il carattere web è memorizzato nella cache, sarà un ritardo di rendering .Ci sono molti commenti in questa domanda che dicono il contrario e che è completamente sbagliato che i caratteri memorizzati nella cache si comportino in questo modo, ma ad es.dal seguente link:

In quali casi otterrai un FOUT

• Will: Download e visualizzazione di un ttf remoto /otf/ woff
• Will: Visualizzazione di un ttf cache /otf/ woff
• Will: Download e visualizzazione di un data-uri ttf /otf/ woff
• Will: Visualizzazione di un dato memorizzato nella cache-uri ttf /otf/ woff
• Non: Visualizzazione di un font già installato e denominato nello stack di font tradizionale
• Non: Visualizzazione di un font installato e denominato utilizzando il local() posizione

Poiché Chrome attende fino a quando il rischio FOUT non si esaurisce prima del rendering, questo dà un ritardo. A quale estendersi l'effetto è visibile( specialmente quando si carica dalla cache) sembra dipendere, tra le altre cose, dalla quantità di testo che deve essere reso e forse da altri fattori, ma la cache non rimuove completamente l'effetto.

Irish ha anche alcuni aggiornamenti riguardanti il ​​comportamento del browser dal 2011-04-14 nella parte inferiore del post:

• Firefox ( a partire da FFb11 e FF4 finale) non ha più un FOUT! Wooohoo! Http: //bugzil.la/ 499292 Fondamentalmente il testo è invisibile per 3 secondi, quindi riporta il font di fallback. Il webfont probabilmente caricherà entro quei tre secondi anche se. .. si spera. .
• IE9 supporta WOFF e TTF e OTF( anche se richiede un bit di incorporamento - principalmente se si usa WOFF). TUTTAVIA! !!IE9 ha un FOUT.:(
• Webkit ha una patch in attesa di atterrare per mostrare il testo di fallback dopo 0,5 secondi, quindi ha lo stesso comportamento di FF ma 0.5s invece di 3.

Se questa era una domanda per i progettisti, si potrebbe andare in modi per evitare questo tipodi problemi come il webfontloader, ma questa sarebbe un'altra domanda: il link Paul irlandese approfondisce ulteriormente la questione

C'è qualcosa da aggiungere alla spiegazione? Sound off nei commenti.utenti esperti di Stack Exchange? Guarda il thread completo di discussione qui.