Cum să faci site-urile să se încarce mai repede

  • Cunoștințe necesare: Intermediar CSS și JavaScript , de bază HTML5
  • Necesită: Un site web pentru a accelera
  • Timpul proiectului: Foarte dependent de site

Acest articol a apărut pentru prima dată în numărul 231 al revistei .net

Viteza ar trebui să fie importantă pentru fiecare site web. Este un fapt bine cunoscut că Google folosește viteza site-ului ca valoare de clasare pentru rezultatele căutării. Acest lucru ne spune că vizitatorii preferă site-urile web rapide - nicio surpriză acolo!

Jakob Nielsen a scris în 1993 despre cele trei limite ale timpilor de răspuns ; deși cercetarea este veche conform standardelor internetului, psihologia noastră nu s-a schimbat prea mult în ultimii 19 ani. El afirmă că, dacă un sistem răspunde în mai puțin de 0,1 secunde, acesta va fi perceput ca instantaneu, în timp ce răspunsurile mai rapide de o secundă permit fluxului de gândire al utilizatorului să rămână neîntrerupt. Este probabil imposibil să aveți o pagină web încărcată în 0,1 secunde; aproximativ 0,34 secunde reprezintă cel mai bun timp de încărcare Google din Marea Britanie, astfel încât acesta servește ca un punct de referință mai realist (deși ambițios). O încărcare a paginii undeva în regiunea de 0,34 la 1 secundă este realizabilă și importantă.

01. Prețul încetinirii

Aceste tipuri de ținte au implicații în lumea reală pentru site-ul și afacerea dvs. Marissa Mayer de la Google a vorbit în 2006 despre un experiment în care numărul de rezultate returnate de motorul de căutare a crescut la 30. Acest lucru a încetinit timpul de încărcare a paginii cu aproximativ 500 ms, atribuindu-se o scădere de 20% a traficului. Între timp, Amazon a întârziat artificial încărcarea paginii în trepte de 100 ms și a constatat că „chiar și întârzieri foarte mici ar duce la scăderi substanțiale și costisitoare ale veniturilor”.



Plugin-ul browserului pentru evaluarea performanței paginilor web open source YSlow se bazează pe recomandările de performanță ale site-ului Yahoo Developer Network

Plugin-ul browserului pentru evaluarea performanței paginilor web open source YSlow se bazează pe recomandările de performanță ale site-ului Yahoo Developer Network

Alte asociații adverse legate de site-uri web lent includ credibilitate redusă, calitate percepută mai mică și site-ul fiind văzut ca fiind mai puțin interesant și atractiv . Frustrarea crescută a utilizatorului și creșterea tensiunii arteriale sunt alte două efecte pe care probabil le-am experimentat cu toții la un moment dat! Dar cum ne putem asigura că site-urile noastre web se încarcă suficient de repede pentru a evita aceste probleme?

Unul dintre primele lucruri de luat în considerare este dimensiunea codului dvs. HTML. Aceasta este probabil una dintre zonele cele mai trecute cu vederea, poate pentru că oamenii presupun că nu mai este atât de relevantă cu conexiunile moderne în bandă largă. Unele sisteme de gestionare a conținutului sunt destul de liberale cu cantitatea pe care o produc - un motiv pentru care poate fi mai bine să vă creați manual site-urile.

Ca orientare, ar trebui să puteți încadra cu ușurință în majoritatea paginilor<50KB of HTML code, and if you’re under 20KB then you’re doing very well. There are obviously exceptions, but this is a fairly good rule of thumb.

De asemenea, este important să rețineți că utilizatorii navighează pe site-uri web mai frecvent pe dispozitive mobile acum. Diferențele de viteză între site-urile vizualizate de pe un telefon sunt adesea mai vizibile, datorită faptului că au rate de transfer mai mici decât conexiunile prin cablu. Două site-uri web concurente cu o diferență de dimensiune de 100 KB pe pagină pot însemna mai mult de o secundă diferență de timp de încărcare pe unele rețele mobile lente - chiar în regiunea „flux de gândire întreruptă” specificată de Jakob Nielsen. Site-ul web mai rapid și mai rapid va fi mult mai puțin frustrant de navigat, oferind un avantaj competitiv distinct față de site-urile web mai grase și va merge mult spre încurajarea vizitelor repetate.

Există resurse alternative de înaltă calitate pentru măsurarea performanței, cum ar fi instrumentul Google gratuit bazat pe pagina, PageSpeed ​​Online

Există resurse alternative de înaltă calitate pentru măsurarea performanței, cum ar fi instrumentul Google gratuit bazat pe pagina, PageSpeed ​​Online

O caracteristică importantă a majorității serverelor web este capacitatea de a difuza codul HTML într-un format comprimat. Întrucât HTML conține în mod natural o mulțime de date repetate, acesta îl face un candidat perfect pentru compresie. De exemplu, codul HTML de 18,1 KB al unei pagini de pornire este redus la 6,3 KB când este difuzat în format comprimat. Aceasta reprezintă o economie de 65%! Algoritmii de compresie sporesc eficiența cu cât corpul de text din care trebuie să lucreze este mai mare, astfel veți vedea economii mai mari cu pagini HTML mai mari. O pagină de 138,1K pe un forum popular este redusă la 25,7K atunci când este servită comprimată, o economie de peste 80% - ceea ce poate îmbunătăți semnificativ timpul total de transfer al resurselor.

Practic, nu există aspecte negative în ceea ce privește difuzarea HTML în această formă; toată lumea ar trebui să o activeze pentru tot conținutul HTML. Unele servere web au setări diferite pentru comprimarea conținutului static și generat dinamic, deci merită să vă asigurați că difuzați conținut comprimat pentru ambele, dacă este posibil.

02. Rețele de livrare de conținut

Rețelele de livrare a conținutului (cunoscute sub numele de CDN-uri) pot, de asemenea, să îmbunătățească semnificativ timpul de încărcare pentru site-ul dvs. CDN-urile sunt o colecție de servere distribuite pe tot globul, care dețin toate copii ale conținutului dvs. Când un utilizator solicită o imagine de pe site-ul dvs. web găzduită pe un CDN, serverul din CDN geografic cel mai apropiat de utilizator va fi utilizat pentru a difuza imaginea.

Există o mulțime de servicii CDN disponibile. Unele dintre acestea sunt foarte costisitoare, dar anunță că vor oferi performanțe mai bune decât CDN-urile mai ieftine. Serviciile CDN gratuite au început, de asemenea, să apară și pot merita să le experimentați pentru a vedea dacă pot îmbunătăți performanța pe site-ul dvs. web.

Un aspect important atunci când utilizați un CDN este să vă asigurați că îl configurați corect, astfel încât să nu pierdeți nicio valoare SEO. Este posibil să primiți mult trafic din imaginile găzduite pe domeniul dvs., în funcție de natura site-ului dvs. web și, mutându-le într-un domeniu extern, vă poate afecta în mod negativ traficul. Serviciul Amazon S3 vă permite să indicați un subdomeniu către CDN-ul său, care este o caracteristică extrem de preferabilă într-un CDN.

cum să blochezi poza de profil pe facebook

Instrumentul gratuit Pingdom pentru analiza „cascadei” paginii dvs. web ajută la descompunerea timpului de încărcare a fiecărei resurse, ceea ce poate ajuta la evidențierea blocajelor

Servirea conținutului pe un alt domeniu (cum ar fi un CDN) sau un subdomeniu pe propriul nume de domeniu care nu setează cookie-uri are un alt avantaj cheie. Când un cookie este setat pe un domeniu, browserul trimite datele cookie cu fiecare cerere către fiecare resursă din același domeniu. Cel mai adesea, datele cookie nu sunt necesare pentru conținutul static, cum ar fi imagini, fișiere CSS sau JavaScript. Tarifele de încărcare ale utilizatorilor web sunt adesea mult mai mici decât tarifele de descărcare disponibile, ceea ce, în unele cazuri, poate provoca o încetinire semnificativă a timpilor de încărcare a paginii. Utilizând un alt nume de domeniu pentru a vă difuza conținutul static, browserele nu vor trimite aceste date cookie inutile, deoarece au politici stricte între domenii. Acest lucru poate accelera semnificativ timpul de solicitare pentru fiecare resursă.

Cookie-urile de pe site-uri web pot prelua, de asemenea, cea mai mare parte a unei cereri HTTP; 1.500 de octeți este în jurul limitei cele mai frecvent utilizate pentru un singur pachet pentru rețelele mari, așa că, dacă puteți păstra solicitările HTTP sub această limită, întreaga solicitare HTTP ar trebui trimisă într-un singur pachet. Acest lucru poate oferi îmbunătățiri privind timpul de încărcare a paginii. Google recomandă ca cookie-urile dvs. să aibă o dimensiune mai mică de 400 de octeți - acest lucru contribuie la menținerea solicitărilor HTTP ale site-urilor dvs. web sub limita unui pachet / 1.500 de octeți.

03. Tehnici suplimentare

Există alte tehnici mai ușor de implementat, care pot oferi avantaje mari vitezei site-ului dvs. Una este să puneți fișierele JavaScript la sfârșitul documentului HTML, chiar înainte de eticheta de închidere a corpului, deoarece browserele au limite de resurse pe care le pot descărca în paralel de la aceeași gazdă.

Specificația HTTP 1.1 originală scrisă în 1999 recomandă ca browserele să descarce doar până la două resurse în paralel din fiecare nume de gazdă. Dar browserele moderne au în mod implicit o limită de aproximativ șase. Dacă pagina dvs. web are mai mult de șase resurse externe (cum ar fi imagini / fișiere JavaScript / CSS), aceasta vă poate oferi performanțe îmbunătățite pentru a le difuza din mai multe domenii (cum ar fi un subdomeniu pe numele dvs. de domeniu principal sau un CDN) pentru a asigura browserul nu atinge limita maximă pentru descărcările paralele.

Foile Sprite sunt ușor de implementat și pot oferi îmbunătățiri semnificative asupra performanței paginii prin reducerea numărului total de solicitări HTTP

Foile Sprite sunt ușor de implementat și pot oferi îmbunătățiri semnificative asupra performanței paginii prin reducerea numărului total de solicitări HTTP

În loc să împărțiți mai multe cereri pe domenii diferite, vă recomandăm să le combinați. Fiecare solicitare HTTP are o cheltuială asociată cu aceasta. Zeci de imagini, cum ar fi pictogramele de pe site-ul dvs. web servite ca resurse separate, vor crea o mulțime de costuri irositoare și vor provoca o încetinire a site-ului dvs., adesea semnificativă. Combinând imaginile într-o singură imagine cunoscută sub numele de „foaie sprite”, puteți reduce numărul de solicitări necesare. Pentru a afișa imaginea, o definiți în CSS, setând lățimea și înălțimea unui element la cea a imaginii pe care doriți să o afișați, apoi setând fundalul pe foaia sprite. Prin utilizarea fundal-poziție proprietate putem muta foaia sprite de fundal în poziție, astfel încât să apară pe site-ul dvs. ca imagine dorită.

Foile Sprite oferă și alte avantaje. Dacă utilizați imagini cu mouse-ul, stocarea lor pe aceeași foaie de sprite înseamnă că atunci când este pornit mouse-ul nu există nicio întârziere, deoarece imaginea de mouse-over a fost deja încărcată în foaia de sprite! Acest lucru poate îmbunătăți în mod semnificativ timpul de încărcare perceput de utilizator și poate crea un site web mult mai receptiv.

Specificarea dimensiunilor oricăror alte imagini din etichetele sunt, de asemenea, un factor important în creșterea timpului perceput de încărcare a paginii dvs. web. Este obișnuit ca dezvoltatorii să nu stabilească în mod explicit lățimea și înălțimea pentru imaginile de pe pagini. Acest lucru poate face ca dimensiunea paginii să se extindă în salturi pe măsură ce fiecare imagine (parțial) se încarcă, făcând lucrurile să se simtă lent. Dacă sunt setate dimensiuni explicite, browserul poate rezerva spațiu pentru imagine pe măsură ce se încarcă, oprind modificarea dimensiunii paginii și, uneori, îmbunătățind semnificativ timpul de încărcare perceput de utilizator.

Deci, ce altceva putem face pentru a îmbunătăți acest lucru? Pre-preluarea este una dintre aceste caracteristici disponibile în HTML5. Pre-preluarea permite încărcarea paginilor și a resurselor înainte ca utilizatorul să le solicite efectiv. Suportul său este limitat în prezent la Firefox și Chrome (cu o sintaxă alternativă). Cu toate acestea, ușurința sa de implementare și utilitatea în îmbunătățirea timpului perceput de încărcare a paginii dvs. web sunt atât de grozave încât este ceva de luat în considerare.






Există o diferență de comportament între pre-preluare și prerender. Mozilla’s preluare va încărca resursa de nivel superior pentru o anumită adresă URL, de obicei pagina HTML în sine, și acolo se oprește încărcarea. Google prerender încarcă și resursele copilului și, în cuvintele Google, „face toată munca necesară pentru a afișa pagina utilizatorului, fără a o afișa efectiv până când acesta nu face clic”.

Google Analytics are în el mai multe instrumente și rapoarte utile care vă pot ajuta să identificați cele mai lente pagini de pe site-ul dvs. web

Google Analytics are în el mai multe instrumente și rapoarte utile care vă pot ajuta să identificați cele mai lente pagini de pe site-ul dvs. web

04. Considerații privind preluarea și prelerarea

Dar utilizarea acestei caracteristici vine, de asemenea, cu considerații importante. Dacă pregătiți / preluați prea multe materiale sau pagini, atunci întreaga experiență de navigare a utilizatorului poate avea de suferit; dacă aveți statistici de la server, acestea pot deveni puternic distorsionate. Dacă utilizatorul nu face clic pe resursa preîncărcată și iese din site-ul dvs., urmăritorul de statistici poate considera vizita ca două vizualizări de pagină, nu ca pe cea reală. Acest lucru poate fi înșelător pentru valori importante, cum ar fi ratele de respingere.

Chrome prerender are un alt avertisment pe care dezvoltatorii trebuie să-l conștientizeze, deoarece pagina prestabilită va executa JavaScript. Prerenderul va încărca pagina aproape exact în același mod ca și când utilizatorul a făcut clic pe link. Chrome nu trimite antete HTTP speciale cu un prerender; totuși, API-ul pentru vizibilitatea paginii vă permite să distingeți dacă pagina este predefinită. Acest lucru este esențial din nou pentru orice scripturi terță parte pe care le utilizați, cum ar fi scripturile de publicitate și urmăritoarele de statistici (Google Analytics folosește deja API-ul de vizibilitate a paginii, astfel încât să nu vă faceți griji cu privire la asta). Gestionarea necorespunzătoare a acestor active cu API-ul Vizibilitate pagină vă face să riscați să distorsionați valori importante.

Folosind preluare și prerender pe conținut paginat este probabil o implementare sigură și utilă - de exemplu pe o pagină web de tutoriale care este împărțită în mai multe secțiuni. În special în ceea ce privește conținutul, cum ar fi tutorialele, este probabil important să păstrăm în limitele „fluxului de gândire neîntrerupt” al Nielsen.

Google Analytics poate oferi, de asemenea, indicii valoroase cu privire la paginile pe care ați putea dori să le prerenderizați / preluați în prealabil. Utilizând analiza sa în pagină, puteți stabili ce link din pagina dvs. de pornire este cel mai probabil să fie făcut clic. În unele cazuri, cu apeluri la acțiune foarte definite, acest procent poate fi extrem de ridicat - ceea ce îl face un candidat excelent pentru preîncărcare.

Atât preluarea, cât și prelerarea funcționează pe mai multe domenii - o atitudine neobișnuit de liberală pentru browsere, care sunt de obicei extrem de stricte în ceea ce privește accesul între domenii. Cu toate acestea, acest lucru funcționează probabil în favoarea Google și Mozilla, deoarece acestea sunt capabile să creeze o experiență de navigare mai rapidă pentru utilizatorii lor în mai multe moduri, oferind un avantaj competitiv semnificativ față de alte browsere care nu acceptă încă astfel de funcții.

cum să desenezi o fată pinup

O captură de ecran de pe serverul web IIS7 care arată cât de ușor este să permiți compresia atât a conținutului static, cât și a celui dinamic

O captură de ecran de pe serverul web IIS7 care arată cât de ușor este să permiți compresia atât a conținutului static, cât și a celui dinamic

Pre-preluarea și în special prerenderizarea sunt instrumente puternice care pot avea îmbunătățiri semnificative asupra timpilor de încărcare percepuți ai paginilor web. Dar este important să înțelegeți cum funcționează, astfel încât experiența de navigare a utilizatorului dvs. să nu fie afectată direct și negativ.

05. Încărcarea conținutului Ajax

O altă modalitate de îmbunătățire a timpilor de încărcare este de a utiliza Ajax pentru a încărca conținut, spre deosebire de a încărca din nou întreaga pagină - mai eficient, deoarece încărcați doar modificările, nu plăcuța din jurul conținutului de fiecare dată.

Problema cu o mulțime de încărcări Ajax este că se poate simți ca o experiență de navigare nefirească. Dacă nu sunt executate corect, butoanele înapoi și înainte nu vor funcționa așa cum se așteaptă utilizatorul, iar efectuarea de acțiuni precum marcarea paginilor sau reîmprospătarea paginii se comportă și în moduri neașteptate. Atunci când proiectați site-uri web, este recomandabil să nu interferați cu astfel de comportamente de nivel scăzut - este foarte desconcertant și neprietenos pentru utilizatori. Un prim exemplu în acest sens ar fi eforturile depuse de unele site-uri web pentru a dezactiva clic-dreapta pe paginile lor web ca o încercare inutilă de a preveni încălcarea drepturilor de autor. Deși implementarea Ajax nu afectează funcționarea browserului cu aceeași intenție de a dezactiva clic dreapta, efectele sunt similare.

HTML5 merge într-un fel pentru a rezolva aceste probleme cu API-ul Istoric. Este bine acceptat pe browsere (în afară de Internet Explorer, deși este planificat să fie acceptat în IE10). Lucrând cu API-ul istoric HTML5 putem încărca conținut cu Ajax, simulând în același timp o experiență de navigare „normală” pentru utilizatori. Când sunt utilizate corect butoanele din spate, înainte și de reîmprospătare, toate funcționează conform așteptărilor. Adresa URL a barei de adrese poate fi, de asemenea, actualizată, ceea ce înseamnă că marcajele funcționează corect din nou. Dacă este implementat corect, puteți elimina o mulțime de încărcări repetate de resurse, precum și a avea back-up-uri grațioase pentru browserele cu JavaScript dezactivat.

Magazinul web Chrome încarcă mult conținut cu Ajax într-un mod care pare o experiență de navigare rapidă și naturală

Magazinul web Chrome încarcă mult conținut cu Ajax într-un mod care pare o experiență de navigare rapidă și naturală

Cu toate acestea, există un mare dezavantaj: în funcție de complexitatea și funcția site-ului pe care încercați să îl construiți, implementarea încărcării conținutului Ajax cu API-ul Istoric într-un mod invizibil pentru utilizator este dificilă. Dacă site-ul folosește și scripturi pe partea de server, s-ar putea să vă regăsiți scriind lucruri de două ori: o dată în JavaScript și din nou pe server - ceea ce poate duce la probleme de întreținere și neconcordanțe. Poate fi dificil și consumator de timp să se perfecționeze, dar dacă funcționează așa cum ați intenționat, puteți reduce semnificativ timpul de încărcare actual, precum și perceput pentru utilizator.

Când încercați să îmbunătățiți viteza site-ului dvs., puteți întâmpina unele probleme de nerezolvat. Așa cum am menționat la începutul acestui articol, nu este un secret faptul că Google folosește viteza paginii ca valoare de clasare. Aceasta ar trebui să fie o motivație semnificativă pentru a îmbunătăți viteza site-ului dvs. Cu toate acestea, este posibil să observați că, atunci când utilizați resurse, cum ar fi rapoartele de viteză ale paginii Google Webmaster Tools, acestea vor raporta timpi de încărcare mai mici decât v-ați aștepta.

Cauza pot fi scripturi de la terțe părți, cum ar fi butoanele Facebook Like sau butoanele Tweet. Acestea pot avea adesea timpi de așteptare în sute de milisecunde, ceea ce poate trage semnificativ timpul de încărcare a întregului site web. Dar acesta nu este un argument pentru a elimina aceste scripturi - este probabil mai important să aveți butoanele de socializare pe site-ul dvs. web. Aceste butoane ocupă de obicei spații relativ mici pe pagina dvs., deci nu vor afecta în mod semnificativ timpul de încărcare perceput de vizitator - ceea ce ar trebui să luăm în considerare în primul rând atunci când facem optimizări de viteză.

Tom Gullen este fondatorul Scirra Ltd, un startup care construiește instrumente de creare a jocurilor: www.scirra.com/

I-a plăcut asta? Citiți acestea!