Tehnici prefetch pentru îmbunătățirea performanței site-ului

Când vorbim despre performanță pe front-end, de obicei ne gândim la lucruri cum ar fi concatenarea, mineritul, cache-ul și scăderea resurselor pe server, permițând paginii să se încarce mai repede și ajută utilizatorii să își atingă obiectivele mai repede.







Pre-selectarea resurselor (prefetting) este o altă tehnică care îmbunătățește performanța. Îl putem folosi pentru a le spune browserului ce resurse ar putea avea nevoie utilizatorul în viitorul apropiat, înainte ca utilizatorul să le solicite.

Prefetarea este o modalitate de a împiedica browserul să știe despre resursele care pot fi utilizate în viitor, unele avertismente sunt legate de pagina curentă, unele sunt legate de paginile viitoare. În calitate de dezvoltatori știm că aplicațiile noastre sunt mai bune decât browserul. Și putem transmite aceste informații browserului.

Practica de anticipare a nevoilor utilizatorilor în resurse este numită prebrowing. Acesta este un termen compus, acesta include un întreg set de tehnici diferite - dns-prefetch. subresource. conectare anticipată. prefetch standard și predare.

DNS-prefetch

În textul său epic despre performanța interfeței, Harry Roberts sugerează utilizarea acestei tehnici:

Această linie simplă instruiește browserele care acceptă să înceapă căutările DNS pentru domeniul specificat înainte de a avea cu adevărat nevoie. Acest lucru înseamnă că procesul de căutare DNS va fi finalizat până la momentul în care este necesar, adică browser-ul primește un start mic atunci când descarcă resurse din "URL-ul preconfirmat".

conectare anticipată

Această metodă este foarte similară cu prefetarea DNS, dar în plus față de rezoluția DNS, această metodă inițiază o conexiune TCP și negocierea TLS cu o conexiune securizată.

Această metodă este descrisă în detaliu într-un articol recent al lui Ilya Grigorik:

Browserele moderne încearcă să prevadă ce conexiuni va avea nevoie site-ul înainte de a face cereri. Prin inițierea "pre-conexiunilor" timpurii, browserul poate configura în prealabil prizele necesare și poate elimina toate lucrările scumpe cu DNS, TCP și TLS din calea critică a cererii curente. Dar indiferent de modul în care browserele moderne au fost avansate, nu vor putea să aloce obiective adecvate de pre-conectare pentru toate site-urile. Vestea bună este că acum putem spune browserului care socket-uri ar trebui să fie deschise înainte ca cererea să fie inițiată datorită tehnologiei de pre-conectare implementată în Firefox 39 și Chrome 46!

Dacă suntem siguri că un anumit fișier va fi necesar după un timp, îl putem solicita browserului să îl descarce în avans și să îl salveze în memoria cache pentru utilizare ulterioară. Poate fi o imagine sau un script, sau orice altceva, stocat în cache de browser.







Spre deosebire de prefetarea DNS, browserul solicită și descarcă resursele solicitate și le stochează în memoria cache. Cu toate acestea, depinde de anumite condiții, prefetarea poate fi ignorată de browser. De exemplu, dacă solicitați un fișier de fonturi cu o conexiune lentă la Internet. Și Firefox preloads resurse numai în timp ce într-un mod leneș.

Bram Stein în postarea sa pe această temă scrie că acest lucru poate da o îmbunătățire notabilă a performanței la descărcarea fonturilor web. În prezent, fișierele cu fonturi înainte de a descărca așteaptă construcția DOM și CSSOM. Prefetarea vă permite să ocoliți problemele de performanță rezultate.

Notă: Cele mai recente versiuni de Chrome și Firefox arată care resurse au fost preîncărcate în fila Rețea în instrumentele pentru dezvoltatori. De asemenea, este util să rețineți că nu există restricții de "aceeași origine" pentru prefetare, adică puteți seta preîncărcarea resurselor din orice domeniu.

subresource

O altă tehnică a prefetării ajută la identificarea resurselor cu cea mai mare prioritate, care ar trebui solicitate mai întâi. De exemplu, în Chrome și Opera, putem adăuga următoarea intrare în cap:

Conform documentației Chrome, această intrare funcționează după cum urmează:

"LINK rel = subresource" oferă un nou tip de referință de link cu o altă semantică LINK rel = prefetch. În timp ce rel = prefetch stabilește prioritatea pentru încărcarea resurselor pentru alte pagini, rel = subresource oferă o încărcare timpurie a resurselor pentru pagina curentă.

Deci, dacă resursa este necesară pe pagina curentă sau cât mai curând posibil, este mai bine să utilizați sub-sursa. și în alte cazuri prefetch.

Această opțiune absolut atomică - prerender vă permite să încărcați preventiv toate fișierele și resursele pentru un anumit document:

Dar fii atent. Trebuie să fiți sigur că utilizatorul va merge la link-ul corect, altfel clientul nu va descărca toate resursele pentru redarea paginii în zadar.

Ca și în cazul oricărei lucrări anticipate, există riscul că va fi în zadar. Și dacă este costisitor (are nevoie de o mulțime de resurse CPU, se scurge bateria sau este nevoie de mult trafic), este necesară precauție. Gândirea intențiilor utilizatorului poate părea complicată, dar cele mai frecvente sunt următoarele scenarii: * Dacă acesta este un rezultat al căutării și este evident, atunci această pagină este cel mai probabil să fie descărcată. * Dacă utilizatorul a intrat în pagina de conectare, următoarea pagină va fi confirmată de login. * Dacă un utilizator citește un articol care este împărțit în mai multe pagini, este probabil să meargă la pagina urmând cea curentă.

În cele din urmă, API pentru vizibilitatea paginilor poate fi folosit pentru a proteja împotriva difuzării scripturilor înainte de a le afișa pe pagină.

Mu a discutat deja despre toate soiurile actuale de prefettare, este timpul să preiau oportunități care vor fi realizate în viitor.

Caracteristică viitoare: preload

În noua specificație, preload-ul este folosit pentru acele resurse care sunt întotdeauna descărcate. indiferent de browser. Dacă preîncărcarea poate fi ignorată de browser, resursele în preîncărcare sunt solicitate de browser în orice caz.

În ciuda faptului că preîncărcarea nu este încă susținută de niciunul dintre browsere, această idee este cu siguranță interesantă.

concluzie

Anticiparea a ceea ce vor face utilizatorii necesită planificare și testare, dar beneficiile în performanță merită. Și dacă vrem să îmbunătățim performanța, ar trebui să experimentăm aceste tehnici.

Citirea ulterioară







Articole similare

Trimiteți-le prietenilor: