/Viteza/faceti site-urile sa se incarce mai repede

Viteza ar trebui sa fie foarte importanta pentru orice site. Este un fapt bine-cunoscut ca Google foloseste viteza site-ului ca indicator in generarea rezultatelor de cautare. Aceasta ne spune ca vizitatorii prefera siteurile rapide – dupa cum era de asteptat!

Jakob Nielsen a scris in 1993 despre cele trei limite ale timpului de raspuns (http://www.nngroup.com/articles/response-times-3-important-limits/); desi cercetarea este veche dupa standardele internetului, psihologia noastra nu s-a schimbat prea mult in ultimii 20 de ani. El afirma ca, daca un sistem raspunde in mai putin de 0,1 secunde, va fi perceput ca instantaneu, iar timpii de raspuns mai mici de o secunda ii permit fluxului de gandire al utilizatorului sa ramana neintrerupt. O pagina care se incarca in 0,1 secunde este probabil un lucru imposibil. O pagina care se incarca intre 0,34 si 1 secunda este un lucru realizabil si important.

Viteza gratuita

Plug-in-ul pentru browser open source Yslow (yslow.org) destinat determinarii performantei paginilor web se bazeaza pe recomandarile Yahoo Developer Network referitoare la performanta siteului

 

Pretul incetinelii

Aceste tipuri de obiective au implicatii reale pentru site-ul si afacerea dumneavoastra. Marissa Mayer de la Google a vorbit in 2006 despre un experiment in care numarul rezultatelor returnate de catre motorul de cautare a fost crescut pana la 30. Din cauza aceasta, timpul de incarcare a paginilor a fost incetinit cu aproximativ 500 ms, o scadere de 20% a traficului fiind atribuita acestui fapt. In acelasi timp, Amazon a intarziat artificial incarcarea paginii in pasi de 100ms si a descoperit ca “si intarzierile foarte mici ar duce la scaderi substantiale si costisitoare ale veniturilor.”

Alte asocieri nefavorabile pentru site-urile incete includ credibilitate diminuata, calitate inferioara si perceperea site-ului drept mai putin interesant si atractiv (netm.ag/webpsychology-231). Cresterea frustrarii si cresterea tensiunii arteriale sunt alte doua efecte pe care probabil ca le-am trait cu totii la un moment dati Insa cum putem sa ne asiguram ca site-urile noastre se incarca destul de rapid incat sa evitam aceste probleme?

Unul dintre primele lucruri la care trebuie sa va uitati este marimea codului HTMl. Probabil ca aceasta este una dintre zonele cele mai neglijate, deoarece se presupune ca nu mai este relevanta odata ce au aparut conexiunile moderne in banda larga. Unele dintre sistemele de gestiune a continutului sunt destul de liberale in privinta cantitatii de date pe care o produc – un motiv pentru care poate fi preferabil sa va reglati singuri site-urile.

Retelele de livrare a continutului pot imbunatati semnificativ timpii de incarcare pentru site-ul dumneavoastra.

De principiu, ar trebui sa puteti sa incadrati cu usurinta majoritatea paginilor in mai putin de 50 KB de cod HTMl, iar daca sunteti sub 20 KB, atunci va descurcati foarte bine. Evident. exista si exceptii, insa este un principiu destul de bun.

De asemenea, este important sa aveti in vedere faptul ca navigarea unor site-uri intregi pe dispozitive mobile este mai frecventa acum. Diferentele de viteza intre site-urile pe care navigati in retele mobile sunt adesea mai evidente si din cauza acestora apar ratele mai mici de transfer comparativ cu conexiunile pe cablu. Intre doua site-uri concurente cu o diferenta de marime de 100 KB per pagina poate aparea o diferenta de mai mult de o secunda la timpul de incarcare in retelele mobile lente – adica intra bine de tot in intervalul “fluxului de gandire intrerupt” de care spunea Jakob Nielsen. Site-ul mai suplu si mai rapid o sa fie mult mai putin frustrant de navigat. obtinand un avantaj competitiv real fata de site-urile mai incarcate si, astfel, o sa incurajeze vizitele repetate.

O caracteristica importanta a majoritatii serverelor web este posibilitatea de a livra codul HTMl intr-un format comprimat. Deoarece, prin natura sa, codul HTMl contine o multime de date redundante, este un candidat perfect pentru comprimare. De exemplu, codul HTMl de 18,1 KB al unei pagini de start poate fi redus la 6,31KB atunci cand este livrat intr-un format comprimat. Aceasta inseamna o economie de 65%! Eficienta algoritmilor de compresie creste odata cu marimea corpului de text de la care trebuie sa porneasca, astfel incat veti observa economii mai substantiale la paginile HTMl mai mari. O pagina de 138,1K de pe un forum cunoscut este redusa la 25,7K atunci cand este livrata comprimata, o economie de peste 80% – care poate imbunatati semnificativ timpii totali de transfer ai resurselor.

Practic, nu exista parti negative la livrarea codului HTMl in aceasta forma; toata lumea ar trebui sa il permita pentru tot continutul HTMl. O serie de servere web au setari diferite pentru comprimarea continutului static si a celui generat dinamic, prin urmare merita sa va asigurati ca livrati continut comprimat pentru amandoua daca este posibil.

Retele de livrare a continutului

Retelele de livrare a continutului (cunoscute drept CDN) pot imbunatati semnificativ timpii de incarcare pentru site-ul dumneavoastra. CDN-urile sunt o colectie de servere distribuite la nivel global, care detin copii ale continutului. Atunci cand un utilizator cere o imagine de pe site-ul dumneavoastra, care este gazduit pe un CDN, pentru a livra imaginea va fi folosit serverul din serviciul CDN care se afla cel mai aproape de utilizator din punct de vedere geografic. Sunt disponibile o multime de servicii CDN. O parte dintre acestea sunt costisitoare, insa isi fac publicitate ca vor oferi performanta mai buna decat CDN-urile mai ieftine. Au inceput sa apara si servicii CDN gratuite si s-ar putea sa merite sa experimentati cu ele ca sa vedeti daca pot imbunatati performanta site-ului dumneavoastra.

Un aspect important atunci cand utilizati un serviciu CDN este sa va asigurati ca il configurati corect pentru a nu pierde din valoarea SEO. S-ar putea sa primiti foarte mult trafic de la imaginile gazduite pe domeniul dumneavoastra, in functie de natura site-ului, iar prin mutarea lor pe un domeniu extern este posibil ca traficul sa fie afectat negativ. Serviciul Amazon S3 va permite sa asociati un sub-domeniu catre serviciul sau CDN, o caracteristica de preferat pentru un CDN.

Livrarea continutului de pe un domeniu diferit (precum un CDN) sau de pe un sub-domeniu care nu stocheaza ccokie-uri are alt avantaj principal. Atunci cand un cookie este setat pe un domeniu, browserul trimite datele din cookie la fiecare cerere pentru fiecare resursa de pe acel domeniu. Cel mai adesea, datele cookie-urilor nu sunt necesare pentru continut static, precum imagini, fisiere CSS sau JavaScript.

Ratele de upload ale utilizatorilor web sunt adesea mult mai mici decat vitezele de download disponibile, iar in anumite situatii, pot provoca o intarziere semnificativa in timpii de incarcare ai paginii.

Prin folosirea unui nume diferit de domeniu pentru a livra continutul static, browserele nu vor trimite datele inutile ale cookie-uri lor, deoarece au politici de securitate stricte inter-domeniu. Prin aceasta, se poate accelera semnificativ viteza cererilor pentru fiecare resursa.

Site-urile incete sunt asociate cu credibilitate diminuata si calitate inferioara

Cookie-urile de pe site-uri pot ocupa mare parte dintr-o cerere HTTP; 1.500 de octeti este aproape de limita cel mai des folosita pentru un singur pachet in retelele mari, deci daca puteti sa mentineti cererile HTTP sub aceasta limita, intreaga cerere HTTP ar trebui trimisa intr-un singur pachet. In acest fel se pot imbunatati timpii de incarcare ai paginii. Google recomanda marimea cookie-urilor sa fie mai mica de 400 de octeti – va ajuta sa mentineti cererile HTTP ale site-uri lor sub limita de 1.500 octeti/per pachet.

Alte tehnici

Exista alte tehnici mai usor de implementat care pot aduce avantaje deosebite vitezei site-ului. Una dintre ele este sa plasati fisierele JavaScript la finalul documentului HTMl, chiar inainte de tagul de inchidere body deoarece browserele sunt limitate in privinta numarului de resurse pe care le pot descarca in paralel de la acelasi serviciu de gazduire.

Specificatia originala HTTP 1.1 scrisa in 1999 recomanda ca browserele sa descarce doar pana la doua resurse in paralel de a fiecare server. Insa, implicit browserele moderne au o limita de aproximativ sase.

Daca pagina web are mai mult de sase resurse externe (ca imagini, fisiere JavaScript/CSS), s-ar putea sa aveti o performanta imbunatatita daca le livrati de pe mai multe domenii (precum un sub-domeniu al domeniului principal sau un CDN) pentru a garanta ca browserul nu atinge limita maxima de descarcari simultane.

In loc sa impartiti cererile multiple pe domenii diferite, ati putea incerca sa le combinati. Toate cererile HTIP au asociat un timp de procesare pe server. Zeci de imagini, precum pictogramele de pe site livrate ca resurse separate, vor necesita timp de procesare inutil si vor provoca o incetinire a site-ului, adesea una semnificativa. Prin combinarea imaginilor intr-una singura cunoscuta ca “sprite”, puteti reduce numarul necesar de cereri. Ca sa afisati imaginea dorita, folositi CSS prin modificarea latimii si inaltimii unui element la acelea ale imaginii pe care doriti sa o afisati, iar apoi stabilirea fundalului ca fiind imaginea de tip sprite. Prin folosirea proprietatii bacl<ground-position, putem muta pe pozitie imaginea de tip sprite din fundal ca sa apara pe site la fel ca imaginea dorita.

Imaginile de tip sprite ofera si alte avantaje. Daca folositi imagini pentru evenimentul mouseover, stocarea lor in aceeasi imagine de tip sprite inseamna ca, atunci cand actiunea mouseover este initiata, nu exista nici un fel de intarziere deoarece imaginea asociata pentru mouseover a fost deja incarcata in imaginea sprite! Prin aceasta se poate imbunatati semnificativ timpul de incarcare perceput de utilizator si se poate crea un site ce pare ca reactioneaza mult mai rapid.

Nespecificarea dimensiuni lor imaginilor in tagurile <img /> este de asemenea un factor important in cresterea timpului de incarcare perceput pentru pagina web respectiva. Este un lucru obisnuit pentru dezvoltatori sa nu configureze explicit latimea si inaltimea imaginilor pe pagini. Din aceasta cauza, dimensiunea paginii poate creste in salturi pe masura ce fiecare imagine se incarca (partial), facand-o sa para lenta. Daca sunt configurate dimensiuni explicite, browserul poate rezerva spatiu pentru imagine pe masura ce se incarca, oprind modificarea dimensiunii paginii si, cateodata, imbunatatim semnificativ timpul de incarcare perceput de utilizator.

Deci ce mai putem face ca sa imbunatatim situatia? Descarcarea cu anticipatie este o astfel de caracteristica disponibila in HTMlS. Descarcarea cu anticipatie permite incarcarea paginilor si a resurselor inainte ca utilizatorul sa le fi cerut. Suportul pentru aceasta este limitat la momentul actual la Firefox si Chrome (cu o sintaxa alternativa). Totusi, usurinta implementarii si utilitatea la imbunatatirea timpului de incarcare perceput pentru pagina web sunt atat de nemaipomenite incat reprezinta un element pe care ati putea sa-I implementati.

Exista o diferenta de comportament intre descarcarea cu anticipatie si afisarea anticipata. Descarcarea cu anticipatie din Mozilla va incarca resursa de cel mai inalt nivel pentru un anumit URl, in mod obisnuit pagina HTMl propriu-zisa, iar acolo se opreste. Afisarea anticipata de la Google incarca si resursele descendente, iar dupa cum spune Google: “face toata munca necesara pentru a-i arata pagina utilizatorului, fara insa a o arata pana cand acesta nu face clic.”

 

Consideratii legate de descarcarea cu anticipatie si afisarea anticipata

Insa folosirea acestei caracteristici implica o serie de consideratii importante. Daca descarcati cu anticipatie/afisati anticipat prea multe resurse sau pagini, atunci s-ar putea sa aiba de suferit intreaga experienta de navigare a utilizatorului; daca aveti statistici pe partea serverului, acestea pot deveni foarte denaturate. Daca utilizatorul nu face clic pe resursa preincarcata si pleaca de pe site, solutia statistica s-ar putea sa considere vizita ca fiind doua pagini vizualizate, si nu doar pe cea efectiva. Acest lucru poate fi inselator pentru indicatori importanti, cum sunt ratele de respingere.
Functia de afisare anticipata din Chrome are alt avertisment de care dezvoltatorii trebuie sa fie constienti, prin aceea ca pagina afisata anticipat va executa cod JavaScript.

Functia de afisare anticipata va incarca pagina ca si cand utilizatorul ar fi facut clic pe linie Nici un fel de anteturi speciale HTTP nu sunt trimise de Chrome cu functia de incarcare anticipata; totusi, Page Visibility API va permite sa va dati seama daca pagina este incarcata anticipat. Acest lucru este extrem de important pentru orice script-uri de la terti pe care le folositi, cum sunt script-urile de reclama si cele statistice (Google Analytics deja foloseste Page Visibility API, prin urmare nu trebuie sa va faceti griji in privinta acestui lucru). Prin gestionarea necorespunzatoare a acestor resurse cu Page Visibility API riscati sa denaturati din nou indicatori importanti.

Folosirea functiilor de descarcare cu anticipatie si afisare anticipata pe continutul paginat este probabil o implementare sigura si utila – de exemplu, pe o pagina web cu tutoriale care este impartita in mai multe sectiuni. In special pentru continut cum sunt tutorialele este probabil important sa va mentineti in limitele “fluxului neintrerupt de gandire” creat de Nielsen.

De asemenea, Google Analytics poate oferi indicii valoroase despre paginile pe care s-ar putea sa doriti sa le descarcati cu anticipatie/afisati anticipat. Prin folosirea In-Page Analytics, puteti stabili pe ce link de pe pagina de start este cel mai probabil sa se faca clic. In anumite situatii, cu apeluri la actiune bine definite, acest procentaj s-ar putea sa fie extrem de mare – ceea ce il face un candidat excelent pentru afisarea anticipata. Atat descarcarea cu anticipatie, cat si afisarea anticipata functioneaza inter- domeniu – o atitudine liberala neobisnuita pentru browsere, care sunt de obicei extrem de stricte in privinta accesului inter-domeniu. Totusi, acest lucru s-ar putea sa fie in favoarea Google si Mozilla deoarece pot sa creeze o experienta mai rapida de navigare pentru utilizatorii lor in mai multe feluri, oferind un avantaj competitiv semnificativ fata de celelalte browsere care inca nu suporta astfel de functii.

Descarcarea cu anticipatie si in special afisarea anticipata sunt instrumente puternice care pot aduce imbunatatiri semnificative timpilor perceputi de incarcare a paginilor web. Insa este important sa intelegem cum functioneaza, astfel incat experienta de navigare a utilizatorului sa nu fie afectata direct si negativ.

Incarcarea continutului cu Ajax

Alta modalitate prin care puteti imbunatati timpii de incarcare este sa folositi Ajax pentru incarcarea continutului, in loc de reincarcarea intregii pagini – o solutie mai eficienta deoarece incarca doar modificarile, nu si sablonul care inconjoara continutul de fiecare data.

Problema cand Ajax este folosit intens este ca poate parea o experienta de navigare nefireasca. Daca nu este executat adecvat, butoanele de inainte si inapoi nu vor functiona asa cum se asteapta utilizatorul, iar realizarea unor actiuni precum marcarea cu semne de carte a paginilor sau reimprospatarea paginii se comporta de asemenea in moduri neobisnuite. Atunci cand creati site-uri, este recomandat sa nu modificati comportamente de baza cum este acesta – este foarte derutant si neprietenos pentru utilizatori. Un exemplu excelent ar fi eforturile pe care unele site-uri le depun ca sa dezactiveze clic dreapta pe paginile lor, ca o incercare zadarnica de a impiedica incalcarea drepturilor de autor.

Desi implementarea Ajax nu afecteaza functionarea browserului, cu aceeasi intentie de a dezactiva clic dreapta, efectele sunt asemanatoare.

HTMl5 se straduieste sa rezolve aceste probleme cu History API. Este bine suportat in browsere. Daca folosim HTMl5 History API, putem sa incarcam continut cu Ajax, simuland in acelasi timp o experienta “normala” de navigare pentru utilizatori. Atunci cand este folosit adecvat, butoanele de inainte si inapoi vor functiona conform asteptarilor. De asemenea, URl-ul din bara de adrese poate fi actualizat, ceea ce inseamna ca marcarea paginilor cu semne de carte functioneaza din nou adecvat. Daca este implementat corect, puteti elimina mare parte din incarcarea repetata a resurselor, precum si sa aveti solutii elegante de rezerva pentru browserele care au JavaScript dezactivat.

Exista totusi si un dezavantaj: in functie de complexitatea si de functia site-ului pe care incercati sa il creati, implementarea incarcarii continutului folosind Ajax impreuna cu History API intr-o modalitate invizibila pentru utilizator este un proces dificil. Daca site-ul foloseste si script-uri pe partea serverului, s-ar putea sa va treziti ca trebuie sa scrieti lucruri de doua ori: o data in Java- Script si din nou pe server – ceea ce poate provoca probleme de intretinere si inconsecvente. Poate fi dificil si necesita timp ca sa il perfectionati, insa daca functioneaza asa cum intentionati, puteti reduce semnificativ timpii de incarcare reali, precum si pe cei perceputi de utilizator.

Atunci cand incercati sa imbunatatiti viteza site-ului, s-ar putea sa va loviti de o serie de probleme de nerezolvat. Asa cum am mentionat la inceputul acestui articol, nu este nici un secret ca Google foloseste viteza paginii ca parametru pentru clasificare. Ar trebui sa reprezinte o motivatie semnificativa pentru a va imbunatati viteza site-ului. Totusi, s-ar putea sa remarcati ca, atunci cand folositi resurse precum rapoartele de viteza din Google Webmaster Tools. vor genera timpi mai lenti de incarcare decat v-ati astepta. Motivul poate fi reprezentat de script-uri de la terti, precum butoane like de pe Facebook sau butoane Tweet. Adesea, acestea pot avea timpi de asteptare de aproximativ sute de milisecunde, care pot trage in jos intregul timp de incarcare a site-ului in mod semnificativ.

Insa nu este nu argument in favoarea eliminarii acestor script-uri – probabil ca este mai important sa aveti butoanele social media pe site. De obicei, aceste butoane ocupa spatii relativ mici pe pagina, astfel ca nu vor afecta prea mult timpul de incarcare perceput de vizitator – lucru pe care ar trebui sa il avem in primul rand in vedere cand facem optimizari ale vitezei.

 

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>