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 caricarne il testo, il modello di caricamento esattamente opposto che abbiamo sperimentato negli anni '90. Cosa sta succedendo?

La sessione di domande e risposte di oggi ci viene fornita per gentile concessione di SuperUser, una suddivisione di Stack Exchange, un raggruppamento di siti Web di domande e risposte basato sulla comunità.

La domanda

Lettore SuperUser Laurent è molto curioso di sapere perché esattamente le pagine sembrano caricare gli elementi in modo completamente diverso rispetto a una volta. Lui 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).

Funziona fondamentalmente l'opposto 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 su 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. Ciò che causa la situazione attuale degli elementi di design prima, testo dopo?

La risposta

Il contributore 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 caratteri web (di solito in formato WOFF), ad es. attraverso i font Web di Google.

In precedenza, gli unici 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 hanno sempre istintivamente definito regole come

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

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

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

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

e quindi caricare il carattere per un elemento specifico, ad es.

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 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 sono popolati 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 testo a ritardare in questi volte è il problema dei caratteri web descritto sopra, credo.)

aggiunta:

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

Il fenomeno è apparentemente noto come "flash di contenuto inascoltato" in generale, e "flash of unstyled text" in particolare. La ricerca di "FOUC" e "FOUT" fornisce ulteriori informazioni.

Posso consigliare 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 di non rendering del testo del font web con un font di fallback durante il periodo di caricamento del font web. Anche se il font web è memorizzato nella cache, lì volontà essere 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 link precedente:

In quali casi otterrai un FOUT

• Volontà: Download e visualizzazione di un ttf / otf / woff remoto
• Volontà: Visualizzazione di un ttf / otf / woff memorizzato nella cache
• Volontà: Download e visualizzazione di un data-urt ttf / otf / woff
• Volontà: Visualizzazione di dati memorizzati nella cache-uri ttf / otf / woff
• Non lo farò: Visualizzazione di un font che è già stato installato e denominato nel tuo tradizionale stack di font
• Non lo farò: Visualizzazione di un font installato e denominato utilizzando la posizione locale ()

Poiché Chrome attende fino a quando il rischio FOUT non scompare prima del rendering, ciò provoca un ritardo. A cui estensione 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.

Irlandese ha anche alcuni aggiornamenti riguardanti il ​​comportamento del browser dal 2011-04-14 in calce al post:

• Firefox (come da FFb11 e FF4 Final) 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 (sebbene richieda un bit di incorporamento - per lo più discutibile se si usa WOFF). PERÒ!!! IE9 ha un FOUT. :(
• Webkit ha una patch in attesa di atterrare per mostrare il testo di fallback dopo 0,5 secondi. Quindi lo stesso comportamento di FF ma 0.5s invece di 3s.

Se questa fosse una domanda rivolta ai designer, si potrebbe andare in modi per evitare questo tipo di problemi come webfontloader, ma quella sarebbe un'altra domanda. Il collegamento di Paul in Irlanda approfondisce ulteriormente la questione.

Hai qualcosa da aggiungere alla spiegazione? Sound off nei commenti. Vuoi leggere più risposte dagli altri utenti di Stack Exchange esperti di tecnologia? Controlla la discussione completa qui.