IT-Swarm.Net

De ce site-urile web nu își afișează imediat textul în aceste zile?

Am observat că recent, multe site-uri web își afișează lent textul. De obicei, fundalul, imaginile și așa mai departe vor fi încărcate, dar niciun text. După ceva timp, textul începe să apară aici și acolo (nu întotdeauna toate în același timp).

Practic funcționează invers, atunci când textul a fost afișat întâi, apoi imaginile și restul se încărcau după aceea. Ce tehnologie nouă creează această problemă? Vreo idee?

Rețineți că sunt pe o conexiune lentă, ceea ce accentuează probabil problema.

Vedeți mai jos un exemplu - totul este încărcat, dar durează câteva secunde până când textul va fi afișat în cele din urmă:

enter image description here

443
laurent

Un motiv este acela că, în prezent, designerii web le place să folosească fonturi web (de obicei în format WOFF ), de ex. prin fonturi Google Web .

Anterior, singurele fonturi care au putut fi afișate pe un site au fost cele pe care utilizatorul le-a instalat local. De exemplu, de ex. Utilizatorii de Mac și Windows nu au neapărat aceleași fonturi, instinctiv întotdeauna au definit reguli ca

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

în cazul în care, în cazul în care primul font nu a fost găsit în sistem, browserul ar căuta al doilea și, în sfârșit, un tip „sans-serif” de tip fallback.

Acum, se poate da o adresă URL a fontului ca regulă CSS pentru ca browserul să descarce un font, ca atare:

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

apoi încărcați fontul pentru un anumit element de exemplu:

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

Acest lucru este foarte popular pentru a putea folosi fonturi personalizate, dar duce și la problema că nu este afișat niciun text până când resursa nu a fost încărcată de browser, care include timpul de descărcare, timpul de încărcare a fontului și timpul de redare. Aștept că acesta este artefactul cu care te confrunți.

Ca exemplu: unul dintre ziarele mele naționale, Dagens Nyheter , folosește fonturi web pentru titlurile lor, dar nu și link-urile lor, așa că atunci când site-ul este încărcat, de obicei văd principalele, și jumătate de secundă mai târziu toate spațiile goale de mai sus sunt populate cu titluri (acest lucru este valabil pe Chrome și Opera, cel puțin. N-au încercat altele).

(De asemenea, designerii stropesc JavaScript absolut peste tot în aceste zile, așa că poate cineva încearcă să facă ceva inteligent cu textul, motiv pentru care acesta este întârziat. Asta ar fi foarte specific site-ului, totuși: tendința generală de a întârzia textul în acestea Times este problema fonturilor web descrise mai sus.)


Plus

Acest răspuns a devenit foarte atrăgător, deși nu am dat prea multe detalii, sau poate pentru că despre asta. Au fost multe comentarii în firul de întrebări, așa că voi încerca să mă extind un pic (o mulțime de comentarii par să dispară la scurt timp după ce subiectul a fost protejat - un moderator probabil le-a curățat manual). De asemenea, citiți celelalte răspunsuri din acest thread, deoarece toate se extind în propriile lor moduri.

Fenomenul este aparent cunoscut sub numele de „bliț al conținutului nestilat” în general și „fulgerul textului nelipsit” în special. Căutarea „FOUC” și „FOUT” oferă mai multe informații.

Pot recomanda postarea designerului web Paul Irish pe FOUT în legătură cu fonturile web .

Ceea ce se poate remarca este faptul că diferite browsere tratează acest lucru în mod diferit. Am scris mai sus că am testat Opera și Chrome, care s-au comportat în mod similar. Toate cele bazate pe WebKit (Chrome, Safari etc.) aleg să evite FOUT prin nu redarea textului de font web cu un font de tip fallback în perioada de încărcare a fontului web. Chiar dacă fontul web este în cache, acolo va fi o întârziere de redare . Există o mulțime de comentarii în acest subiect de întrebare care spun altfel și că este greșit faptul că fonturile din cache se comportă astfel, dar de ex. de la linkul de mai sus:

În ce cazuri veți primi un FOUT

  • Va: Descărcarea și afișarea unei fișiere telecomandate/otf/woff de la distanță
  • Va: Afișarea unui ctf/otf/woff în cache
  • Va: Descărcarea și afișarea unei date-uri ttf/otf/woff
  • Va: Afișarea unei date cache-uri ttf/otf/woff
  • Nu va: Afișarea unui font care este deja instalat și numit în stiva de fonturi tradiționale
  • Nu va: Afișarea unui font care este instalat și numit folosind locația locală ()

Din moment ce Chrome așteaptă până când riscul FOUT nu va fi eliminat înainte de redare, acest lucru dă o întârziere. În ce măsură măsura efectul este vizibil (în special atunci când se încarcă din cache) pare să depindă, printre altele, de cantitatea de text care trebuie redată și poate de alți factori, dar în cache nu înlătură complet efectul.

Irlandeză are, de asemenea, câteva actualizări privind comportamentul browserului din 2011–04–14 în partea de jos a postării:

  • Firefox (din FFb11 și FF4 Final) nu mai are FOUT! Wooohoo! http://bugzil.la/499292 Practic, textul este invizibil timp de 3 secunde, apoi readuce fontul de retragere. Webfont-ul se va încărca probabil în cele trei secunde, însă ... sperăm ..
  • IE9 acceptă WOFF și TTF și OTF (deși necesită n bit de încorporareset set - în mare parte moot dacă utilizați WOFF). INDIFERENT !!! IE9 are un FOUT. :(
  • Webkit are n patch care așteaptă să aterizeze pentru a afișa textul de retragere după 0,5 secunde. Deci, același comportament ca FF, dar 0,5s în loc de 3s.
  • Adăugare : Blink are n bug înregistrat și pentru acest lucr , dar se pare că nu s-a ajuns la un consens final cu privire la ce trebuie făcut cu acesta - în prezent aceeași implementare ca WebKit.

Dacă aceasta ar fi o întrebare destinată proiectanților, s-ar putea intra în modalități de a evita aceste tipuri de probleme, cum ar fi webfontloaderNAME _ , dar aceasta ar fi o altă întrebare. Legătura lui Paul irlandez abordează mai detaliat acest aspect.

483
Daniel Andersson

Motivul pentru asta este textul pe care nu îl puteți citi încă este redat cu n font web care se află încă pe drum în conductele către browser.

De asemenea, din moment ce browserul dvs. este Google Chrome, care folosește WebKit pentru a reda pagina, s-a decis de ei (WebKit adică) este mai bine pentru dvs. să nu vedeți niciun text până la fontul web este descărcat. Dacă, totuși, sunteți un dezvoltator care ar prefera ca textul să poată fi citit într-un font de sistem adecvat, atunci puteți folosi ceva de genul Google WebFont Loader pentru a realiza acest lucru.

117
Marcel

Răspuns scurt: AJAX sau WOFF =

Există mai multe cauze de site-uri web "lent pentru a-și afișa textul" . Lentitatea de pe portableapps.com este cauzată de descărcarea WOFF fonturi. Cu toate acestea, ceea ce descrii drept "textul începe să apară aici și acolo" este mai des cauzat de AJAX.

Un site web este format din mai multe părți. Modul în care aceste piese sunt descărcate și asamblate este o alegere de design sub controlul designerului web . Lentitatea este cauzată de modul în care dezvoltatorul alege să asambleze următoarele blocuri de construcție:

  • Pagina inițială HTML
  • CSS
  • JS
  • Imagini
  • Fonturi WOFF
  • Cereri AJAX
  • Manipularea DOM

Site-uri web tradiționale:

În mod tradițional, dezvoltatorii au fost obișnuiți să pună conținutul textului în pagina HTML inițială și să-l afișeze imediat ce a fost disponibil . HTML-ul ar face referire la mai multe resurse care vor fi apoi descărcate. Browserul ar trebui apoi să redirecționeze progresiv ecranul pentru a include stilurile și imaginile pe măsură ce au devenit disponibile. AJAX și WOFF nu erau disponibile.


Site-uri WOFF:

Fonturile WOFF permite unui site web să utilizeze fonturi care nu sunt disponibile în mod normal pentru browser, prin descărcând fonturi cu site-ul . Unii dezvoltatori invită browserul să nu afișeze conținutul textului până când toate fonturile WOFF au fost descărcate. În experiența mea, această abordare nu a obținut încă o utilizare foarte largă.


Site-uri AJAX:

Unii dezvoltatori aleg să nu includă conținutul textului în pagina HTML inițială. În schimb, aleg să descarce conținutul textului folosind AJAX. Acest lucru se întâmplă după ce pagina de bază a fost încărcată . În experiența mea, această metodă a obținut mult mai mult adoptare mai largă decât fonturile WOFF și este cel mai adesea cauza încetinitorului pe care îl descrii.


Determinarea cauzei

Pentru a determina cauza unui anumit site este necesară o analiză folosind instrumente precum Firebug sau Chrome Developer Tools . Sau, alternativ, puteți deschide site-ul folosind Internet Explorer 8 , care acceptă AJAX, dar nu și WOFF. Dacă site-ul este încă lent, problema este AJAX și nu WOFF.

19
KevSheedy

De multe ori este posibil să fie o alegere deliberată pentru a evita „fulgerul de conținut nestilat”. Dacă textul afișat înainte de a fi încărcat CSS, l-ați vedea pe scurt așa cum apare brut, apoi un bliț în timp ce browserul îl redescrie. Prin introducerea unor stiluri de bază pentru a ascunde inițial conținutul, care sunt suprasolicitate în foaia de stil reală sau folosind JS, dezvoltatorii evită acest flash.

14
Greg H

După cum au remarcat alții, fonturile personalizate vor contribui probabil la întârziere.

Pentru a oferi un pic de fundal, browserul face aproximativ următoarele pentru a putea reda conținutul paginii pe ecran:

  1. preluare HTML (mai multe călătorii dus-întors pentru DNS, TCP, cerere/răspuns)
  2. începe să analizeze HTML, să descopere resurse externe, cum ar fi CSS extern și JS. Rețineți că CSS blochează aspectul și JS blochează analizarea. Astfel, resursele externe precum CSS și JS încărcate devreme în document (de exemplu, în cap) încetinesc timpul necesar pentru o pagină pentru a afișa conținut pe ecran.
  3. obțineți CSS și JS externe (mai multe călătorii dus-întors: DNS și TCP dacă aceste resurse sunt pe un domeniu diferit, cum ar fi CDN, precum și un RTT pentru cerere/răspuns)
  4. odată ce CSS-urile externe și JS au terminat încărcarea, analizează/execută JS, analizează/aplică stiluri
  5. dacă CSS face referire la fonturile personalizate, aceste fonturi trebuie acum să fie descărcate, ceea ce duce la întârzieri suplimentare dus-întors pentru a reda orice părți ale paginii care depind de fonturile personalizate

Deși nu este vorba despre întârzierile cauzate de fonturile personalizate, am scris recent o postare pe blog care oferă informații suplimentare despre cauzele întârzierilor de redare. Acesta oferă câteva sugestii pentru a minimiza timpul pentru prima vopsire pentru paginile dvs. Sperăm că acest lucru este util pentru cititorii interesați de a face paginile lor să afișeze conținut mai rapid, inclusiv acele pagini care doresc să folosească fonturi personalizate: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render -in-sub-one-secundă /

8
Bryan McQuade

Răspuns scurt: dezvoltatori.

Când etichetele de legături și scripturi care fac referire la documente externe (cum ar fi fișierele .css sau .js) sunt plasate în capul documentului (mai mare în flux decât corpul și elementele acestuia), acestea sunt încărcate mai întâi. JavaScript execută din marcajul care îl face referire; dacă există o mulțime de coduri de procesat sau este un cod greoi, sau mai frecvent dacă textul pe care așteptați să îl vadă este redat pe un server și populat în documentul încărcat - și codul pe server este greoi, mare sau care blochează I/O din cauza procesării mai multor cereri concomitente, cu siguranță, puteți observa perioade de oprire înainte ca HTML-ul să fi avut șansa să fie redată. Unii dezvoltatori aleg să încarce JavaScript care nu are legătură cu vizualizarea după marcare și stiluri (la sfârșitul corpului) și cel mai bine încearcă să fie mai conștient de modul în care decizia lor de tehnologie va afecta experiența generală a utilizatorului atunci când este implementată.

Viteza conexiunii la Internet joacă un rol în descărcarea lentă a datelor, în mod evident, dar codul slab scris sau stivele tehnologice prost proiectate (pentru tipul de site-ul web) joacă un rol din ce în ce mai central în încărcarea lentă a conținutului dinamic, deoarece conexiunile de rețea mai rapide abordați ubicuitatea.

4
Benny

Pe scurt, pot fi afișate prea multe obiecte care trebuie încărcate din GET-uri HTTP separate înainte de afișarea paginii și o dependență excesivă a latenței medii ca măsură a stării de sănătate a site-ului.

Primul se referă la toate acele .css, .js și webfonts pe care se încarcă pagina, fără a menționa faptul că multe site-uri trebuie să recupereze obiecte JSON viea cereri XHR și apoi să genereze HTML de la cei care folosesc un fel de șablonare.

Dar de ce nu observă că site-ul este lent?

Probabil pentru că au memecache-uri acolo undeva pentru a accelera lucrurile (sau doar se bazează pe cache-urile sistemului de fișiere) și își măsoară sănătatea site-ului folosind latența medie. Astfel, obiectele din cache sunt returnate cu 6 latențe mircrosecunde și maschează faptul că multe solicitări GET au nevoie de 5000 de milisecunde pentru a fi completate. Mediile trebuie să moară. Trăiască numărarea RTT-urilor peste un prag maxim acceptabil! Acest număr ar trebui să fie 0 sau, prin definiție, RTT este inacceptabil.

3
Michael Dillon