In aprilie 2010, Google a decis sa includa viteza site-ului Web in algoritmul de cautare. Viteza a fost intotdeauna importanta din punct de vedere al utilizatorilor, asa ca aceasta optiune este conforma cu misiunea continua a companiei Google de a promova cele mai folositoare si mai prietenoase site-uri Web. Nici un proprietar de site nu-si poate permite sa ignore aceasta schimbare de politica.

Bineinteles, viteza a fost intotdeauna un factor major in felul in care multa lume este predispusa sa va viziteze site-ul. Prima impresie a potentialului dumneavoastra vizitator este deseori felul cum apare site-ul intre rezultatele de cautare. Este domeniul tehnicilor SEO traditionale: numele site-ului, titlurile, cuvintele cheie, continutul. Insa, a doua impresie este cat de repede se incarca odata ce a facut click pe el. Veti fi putut crea cea mai atragatoare schema de culori, o imagine de fundal senzationala si logoul perfect. Insa, daca trec 5,6 secunde pana se incarca, utilizatorii se pot plictisi si pot da click pe urmatorul rezultat al cautarii, ajungand, in schimb pe un site simplu, dar rapid.

Acest articol acopera cateva sfaturi usoare (si cateva mai dificile, totusi) pentru accelerarea site-ului dumneavoastra. Cel mai important este ca cele mai multe dintre ele nu necesita vreun sacrificiu din punct de vedere al continutului sau al design-ului – un pic de rearanjare si reconfigurare. Totul pentru ca s-ar putea sa nu mai aveti sansa unei a treia impresii.

Pragul de 1,5 secunde al lui Google

Pragul impus de Goolge ca sa considere un site ca fiind rapid este de aproximativ 1,5 secunde. Pentru a verifica acest lucru pentru site-ul dumneavoastra, aveti nevoie de un cont Google. Autentificati-va, dati click pe adresa de e-mail din coltul din dreapta sus si alegeti Account Settings. La sectiunea Products, alegeti Webmaster Tools. S-ar putea sa fiti nevoiti sa adaugati un site si sa-l supuneti verificarii – prin descarcarea unui fisier de verificare care trebuie stocat pe site sau prin adaugarea unui meta tag paginii de index a site-ului. Click pe numele site-ului pentru a ajunge la Dashboard. Pe partea stanga dati click pe Labs, iar apoi pe Site performance.

Aceasta pagina va va prezenta in mod vizual cat de rapid a fost site-ul dumneavoastra pe parcursul ultimelor luni si va afisa numarul de secunde necesare pentru incarcarea unui esantion din paginile site-ului. Google considera ca un site este rapid cand se situeaza intre primele 20 de procente din toate site-urile pe care le-a monitorizat. La momentul scrierii materialului, era vorba de aproximativ 1,5 secunde.

In Google Analytics exista o facilitate denumita Site speed, care detecteaza timpii de incarcare pentru toate paginile site-ului. Pentru a il utiliza, va trebui sa adaugati un apel la functia trackPageLoadTime() in codul JavaScript asociat serviciului Google Analytics. Odata ce au fost colectate niste cantitati de date, autentificati-va, dati click pe New version din coltul din dreapta-sus si regasiti analiza Site Speed in zona Content din stanga.

Viteza este doar unul din cei peste 200 de factori (semnale) care contribuie la clasarea unei pagini in lista cu rezultatele cautarii. Nu prea exista indici despre detaliile felului in care actioneaza acest semnal in mod particular si nici despre cat de important este in comparativ cu alti factori – ci doar ca este mai important decat era. Asadar, cea mai buna cale de urmat este sa incercati sa faceti fiecare pagina din site cat mai rapida si mai supla cu putinta.

Analiza vitezei de incarcare a paginii

Exista cateva instrumente gratuite cu care puteti analiza viteza site-ului. Daca folositi Google Chrome, faceti click pe meniul cu cheia din coltul dreapta-sus al ferestrei, navigate la Tools, iar apoi la Developer Tools (sau Ctrl+Shift+I). Click pe Resources si actualizati pagina. Zona va incepe sa se umple pe masura ce Google Chrome descarca fisierele necesare pentru a afisa pagina Web. In zona Network, va aparea un grafic cronologic in care este prezentat timpul in care a fost descarcata fiecare resursa-pagina in sine, fisiere de stiluri, JavaScript sau imagini. Cate o linie vertical albastra si poate si rosie vor aparea pentru a indica atingerea anumitor etape in procesarea JavaScript, iar dedesubt este prezentat timpul total de incarcare. La trecerea cursorului peste fiecare dintre capsulele reprezentand resursele, sunt prezentate detaliile traficului generat.

Pentru si mai multe informatii, puteti accesa serviciul WebPagetest si introduce URL-ul site-ului testat. Alegeti un server localizat geografic cat mai aproape si apasati pe Start Test. Vizualizarea in cascada este similara cu cea oferita de Chrome, insa analiza include si un scor, o lista de posibile optimizari pentru fiecare resursa in parte si o repetare cronometrata a accesarii paginii.

Micsorarea paginilor si cresterea vitezei lor nu inseamna rescrierea continutului paginilor, ci subtierea si rearanjarea fisierelor HTML, CSS si JavaScript dependente, precum si optimizarea configuratiei serverului atunci cand acest lucru este posibil. Urmatoarele sectiuni vor aborda aceste lucruri, pe masura ce vom explica si diferitele vizualizari din serviciul WebPagetest. Spre sfarsitul articolului, vom discuta si despre modalitatile in care poate fi marita viteza si in cazul vizualizarilor repetate.

Combinarea fisierelor JavaScript si CSS

WebPagetest prezinta un numar de 77 de fisiere care compun pagina cu vremea de la BBC. Vizualizarea cascada prezinta cat timp ii ia browserului sa proceseze fiecare fisier. Pentru fiecare fisier exista un dreptunghi multicolor si un timp in milisecunde. Culorile prezinta timpul relativ necesar pentru executarea diferitelor operatiuni. Aceasta pagina foloseste fisiere stocate pe diferite servere.

Cand primul fisier de pe oricare server nou este cerut, vor trece cateva milisecunde pentru a executa o operatiune de cautare in serverul DNS, prezentata in culoarea gri, si vor trece ceva milisecunde pana la crearea conexiunii, prezentata in portocaliu (daca toate fiserele prezinta o secventa de inceput portocalie, citit cu atentie sectiunea despre Keep-Alive). Apoi, toate fisierele includ un anumit timp necesar pana soseste primul byte al fisierului, afisat cu verde, iar dupa aceea, timpul necesar descarcarii totale a fisierului, cu albastru (acesta din urma este uneori atat de mic incat abia este vizibil). Primul element al listei este URL-ul introdus, cu caracterul liniuta oblica la sfarsit. In timp ce descarca codul HTML al acestei pagini, browserul a intalnit o referinta la un fisier denumit main.css si a cerut imediat fisierul, inainte sa fi primit tot codul HTML. Urmatoarele 20 de fisiere sunt in marea lor parte fisiere JavaScript si mai toate secventiale – ceea ce inseamna ca IE7 a trebuit sa astepte pana s-a incarcat unul dintre ele pentru a efectua cererea pentru urmatorul si a petrecut aproape trei secunde facand acest lucru. Cel mai mult timp nu a fost petrecut descarcand fisiere, ci asteptand pentru ele. La o adunare aproximativa a secventelor cu verde – cam 60 de milisecunde pentru fiecare dintre cele 15 fisiere JavaScript – se ajunge la aproape o secunda de asteptare! Asadar, unul dintre primele mele sfaturi de optimizare este combinarea tuturor fisierelor JavaScript intr-unul singur, la fel si pentru CSS. Astfel browserul va avea de asteptat doar de doua ori.

Caching pentru un continut static

In WebPagetest, vizualizarea pentru repetarile efectuate ar fi normal sa dureze mult mai putin pentru ca, in mod normal, testul ar trebui sa profite de catchingul din browser. Mare parte din continutul unui site Web este static si se schimba rareori – fisierele HTML statice, fisierele JavaScript si CSS si imaginile. In general, browserul le va stoca in cahe-ul sau si, cand sunt cerute din nou, va determina daca sunt recente sau expirate, bazandu-se pe data oferita de parametrul Last Modified al fisierului. Daca sunt expirate, browserul va cere serverului Web sa valideze fisierul – sa confirme daca exista sau nu o versiune mai noua a fisierului.

Aceasta validare necesita comunicare suplimentara si o intarziere inerenta intre browser si server chiar daca serverul raspunde cu “da,poti folosi versiunea din cache”. Aceasta situatie poate fi evitata daca, la transmiterea continutului static, este adaugat headerul Expires sau valoarea max-age pentru headerul CacheControl – care recomanda browserului sa pastreze in mod sigur fisierul in cache pentru o ora, o zi, o saptamana sau atata timp cat doriti – fara a pune intrebari.

Adaugarea sectiunii de mai jos la fisierul de configurare al Apache sau intr-un fisier .htaccess va face acest lucru – ii va spune browserului sa pastreze fisierele care se termina in html/xml/css/etc. pentru sapte zile, adica 604800 de secunde:


FilesMatch”\.(htmlǀxmlǀcssǀjsǀgifǀpngǀjpeg$
Header set Cache-Control”max-age=604800”
/FileMatch

Alternativ puteti transmite headerul Expires folosind directive mai prietenoase cu cititorul lor. Acest exemplu include o verificare pentru a ne asigura dinainte ca Apache are instalat modul necesar, pentru a-l impiedica sa afiseze mesajul Internet Server Error daca nu este disponibil:


IfModule mod_expires.c
ExpiresActive On
ExpiresByType text/css “access plus 1 week”
/IfModule

Singurul dezavantaj este, daca fisierul se va schimba intre timp, va trebui sa-l redenumiti pentru a va asigura ca noua versiune este vazuta de toata lumea.

Reduceti marimea imaginilor

Imaginile sunt o mare parte din marimea totala a fiserelor pentru multe site-uri. Reducerea impactului acestora poate lua timp, insa tehnic, este relativ usor de realizat.

Imagini miniaturale

Multe site-uri afiseaza versiuni miniaturale ale imaginilor, pe care, dupa aceea, se poate face click pentru a le mari. Uneori este disponibila doar versiunea mare a imaginii, astfel incat, imaginea mare este descarcata si browserul o redimensioneaza pentru o afisare la mici dimensiuni. Insa este mult mai eficienta oferirea in prealabil a unei versiuni separate, miniaturale, redimensionate anterior.

Situatia apare deseori pe site-urile intretinute de proprietar, unde aceasta incarca pe site fotografii de produse de 10 megapixeli direct de pe camera digitala sau din scanner si trebuie descarcate multiple imagini pentru a afisa cateva miniature de 100x100pixeli. Pentru a elimina situatia, dezvoltatorii de solutii CMS ar putea redimensiona automat imaginile la incarcarea pe site, producand miniaturile in mod automat.

Formate

Atunci cand reduceti marimea fisierelor, concentrati-va in primul rand asupra celor de dimensiuni mari si care sunt folosite des(cum sunt imaginile de fundal). Principalele formate suportate de browsere sunt JPEG (in principal fotografii), PNG si GIF (pentru logouri si elemente grafice cu transparenta si/sau zone mari de culoare uniforma). Atunci cand salvati un fisier JPEG in Photoshop, Gimp sau alt program de editare a imaginilor, aveti optiunea de a alege calitatea. Cea implicita este la 80-90%, insa s-ar putea sa aveti posibilitatea sa mergeti pana la 50% fara a aparea diferente sesizabile, mai ales in cazul fisierelor JPEG de dimensiuni mici si care nu contin text, iar astfel veti reduce marimea fisierului la jumatate sau o tremie din cea orioginala. Fisierele GIF si PNG pot fi salvate folosind mai putine culori pentru a le reduce marimea. Exista o sumedenie de intrumente online pentru a executa aceste operatiuni, multe dintre ele oferind prelucrare in bloc : cautati dupa “optimize images”.

Reducerea marimii fisierelor

Dupa reducerea numarului de fisiere care trebuie descarcate, va puteti concentra pe reducerea dimensiunilor fiecaruia dintre ele.

Pagini HTML : puteti reduce marimea codului HTML prin eliminarea comentariilor si a spatiilor goale redundante. Daca in HTML se gasesc si secvente JavaScript sau CSS repetate pe mai multe pagini, ele ar trebui mutate intr-un fisier extern. In acest caz, vor fi descarcate o singura data si stocate in cache-ul browserului. O cunoastere buna a limbajelor HTML si CSS va poate de asemenea fi de ajutor in procesul de subtiere a fisierelor.

JavaScript si CSS : unul dintre avantajele Developer Tools din Chrome fata de WebPagetest este ca puteti vedea rapid rezultatele in browser. Daca dati click pe tabul Network, iar apoi pe coloana Size, va va fi prezentata o sortare dupa marimea fisierelor si veti vedea ca cele JavaScript su CSS detin o buna parte din multe pagini Web modern (pentru a vedea aceasta sortare in WEbPagetest, dati click pe linkul Content Breakdown din mijlocul celei de-a doua bare negre de navigare). Asadar, minimizarea acestor fisiere este foarte importanta si exista multe instrumente online care pot face acest lucru. Acestea extrag comentariile, spatiile si semnele de punctuatie inutile si va odera un fisier subtirel, insa care nu poate fi citit, posibil la jumatate din dimensiunea originala.

Efectuati o cautare dupa termenii “minify” JavaScript care va permite sa introduceti codul JavaScript brut iar apoi sa primiti o versiune redusa in dimensiuni. Intotdeauna, insa, pastrati o copie a versiunii originale.

Imagini : reducerea dimensiunilor fisierelor cu imagini este o operatiune simpla, insa consumatoare de timp deoarece pot exista multe astfel de fisiere. Vedeti caseta “Reduceti marimea imaginilor” pentru sfaturi despre cum puteti “servi” utilizatorilor imagini corecte, dimensionate optim.

Caching pentru continut dinamic

Si fisierele generate dinamic pot beneficia de caching. De exemplu, aveti o baza de date cu 5000 de produse, dintre care numai pentru unele dintre ele s-a modificat pretul sau descrierea. Desi paginile de vizualizare a acestor extrag in mod dinamic informatii din baza de date, la randul lor pot fi determinate sa foloseasca cache-ul browserului, prin utilizarea headerului Last-Modified. Functia PHP va transmite browserului headerele adecvate, in baza datelor calendaristice folosite.

Scriptul transmite o data de expirare in trecut pentru a se asigura ca browserul se bazeaza pe data ultimei modificari si nu incearca cachingul prea entuziast (spre deosebire de resursele statice, unde data expirarii este stabilita in viitor pentru a incuraja cachingul).

Sau daca pagina de index se schimba frecvent, puteti cere browserului pur si simplu sa stocheze in cache pagina cate 10 minute. Un utilizator care se reintoarce pe pagina pentru a urmari alte elemente ale ei va beneficia de o experienta dinamica.

In Firefox, puteti da click dreapta pe pagina si alege optiunea View page info pentru a verifica daca Last Modified Date este configurata corect. Si, intotdeauna, puteti apasa Shift+Refresh/Reload pentru a forta browserul sa afiseze cea mai recenta versiune a paginii.

Rulati codul JavaSCript la incarcarea paginii

Rezultatul obtinut de pagina BBC-ului pe WebPagetest da trei rezultate diferite : inceperea afisarii la 2,889secunde, document complet/timp de incarcare la 5,391 secunde si incarcat complet la 6,667 secunde. Acesta din urma este timpul in care pagina s-a incarcat si afisat si evenimentul JavaScript onload a fost declansat si este (propabil) timpul pe care il foloseste Google pentru a masura viteza paginii.

Asadar, pe cat posibil, este de ajutor rularea codului JavaScript neesential dupa ce pagina s-a incarcat. De exemplu, daca pagina include o prezentare cu 10 imagini create in JavaScript, nu este necesara descarcarea celor 10 imagini inca de la inceput. Trebuie descarcata doar prima, pentru ca utilizatorul sa aiba in fata o pagina completa. Probabil ca nu va afecta timpul total de incarcare in WebPagetest, insa va scurta perioada in care documentul este complet.

Configuratia serverului

In partea de sus a fiecarui rezultat de la WebPagetest se afla un set de scoruri. Sectiunile precedente s-au ocupat de doua dintre scoruri, pentru compresia imaginilor, unde BBC a iesit bine, si pentru combinarea fisierelor JavaScript si CSS, unde rezultatul a fost prost. Urmatoarea sectiune se ocupa de Keep-Alive si compresia textului. Cachingul continutului static sau dinamic este tratat in casete dedicate. Acronimul CDN provine de la Content Delivery (sau Distribution) Network si reprezinta folosirea mai multor servere pentru a distribui incarcarea, fie dupa un criteriu geografic, fie dupa tipul de continut (de exemplu un server separat pentru imagini) – operatiune potential scumpa si in consecinta de prioritate mai mica.

Keep-Alive

In primul paragraf cascada pentru pagina meteo a BBC, doar cateva dintre fisiere au avut conexiunea initiala de culoare portocalie. Acest lucru s-a intamplat datorita faptului ca browserul a fost capabil sa mentina activa conexiunea si sa o refoloseasca pentru a cere mai multe fisiere. Acest lucru se numeste Keep-Alive sau conexiune persistenta si este o optiune de configurare a serverului. Fara ea, browserul ar trebui sa se reconecteze la server pentru fiecare cerere de fisier.

Din fericire, Keep-Alive este usor de activat. Din nefericire, trebuie sa aveti acces la optiunile de configurare ale serverului. Pentru Apache, optiunile necesare se gasesc in httpd.conf sau in apache2.conf.

Sfat pentru viteza

Afacerea companiei Google consta in ale oferi oamenilor posibilitatea de a ajunge la informatia cautata cat mai repede posibil, asadar merita sa fiti atenti la cercetarile lor in acesta zona. Pe blogul Official Google Webmaster Central cautati dupa “site speed” si derulati in aprilie 2010 pentru a vedea anuntul referitor la viteza site-urilor. In articol poate fi gasit un link la un studio intern al Google publicat in iunie 2009. Google a experimentat incetinind pagina de rezultate si masurand cum afecteaza acest comportament utilizarea motorului de cautare. Rezultatele au fost relevatoare. Compania a determinat ca, intr-o perioada de trei saptamani, utilizatorii au efectuat cu 0,22% mai putine cautari daca paginile de rezultate ii lua cu 200 de milisecunde in plus sa incarce. Si mai mult, efectul s-a inrautatit in urmatoarele trei saptamani si a fost masurabil si dupa incetarea experimentului.

Doua zecimi de secunda sunt o mica perioada de timp, de doua ori mai mult decat un clipit de ochi. Lectia pentru administratorii de site-uri este ca si micile cresteri in viteza site-ului pot duce la vizite mai lungi si mai mare probabilitate a repetarii vizitelor.

Keepalive On. MaxKeepAliveRequests100. KeepAliveTimeout 3

Aceste optiuni activeaza caracteristica, stabilesc numarul maxim de cereri per conexiune persistenta si stabilesc cat de mult va dura conexiunea, de obicei recomandata o perioada scurta. Va trebui sa reporniti serverul dupa efectuarea modificarilor. Va mari putin incarcarea serverului, insa va accelera puternic remiterea paginilor.

Compresia textului

Pe langa sfaturile de compresie de mai devreme, ii puteti spune serverului sa compreseze fisierele si sa le trimita browserului. Acesta le va decomprima inainte de a le afisa. Fisierelor HTML, JavaScript si CSS le poate fi redusa dimensiunea cu peste 50 de procente.

Pentru Apache, optiunea se poate activa adaugand un rand suplimentar fisierului de configurare sau, in directoarele stabilite, folosind un fisier .htaccess:


AddOutputFilterByType DEFLATE text/plain
Text/html text/xml

Cautati dupa mod_deflate pentru a vedea un exemplu in care totul este compresat, mai putin imaginile, doar pentru acele browsere care suporta acest lucru. Imaginile sunt deseori excluse din operatiune deoarece sunt deja puternic comprimate si nu se economiseste latime de banda. Si in acest caz, serverul cunoaste o incarcare suplimentara.

Viteza serverului si a paginii

In final, s-ar putea ca serverul sau baza de date sa fie incite sau sa se chinuie la incarcare mare.

In WebPagetest, daca timpul, de culoare verde deschis, scurs pana la primul byte al paginii este neobisnuit de lung (PHP-ul sau ASP-ul care genereaza dinamic HTML-ul) si relativ scurt pentru restul resurselor statice, s-ar putea ca baza de date “sa rasneasca” prea mult, cautand intre mii de lucruri inainte ca ceva sa-i fie trimis browserului.

In acest caz, puteti forta serverul Web sa trimita neintarziat elementul "head" al paginii, urmand ca dupa aceea sa fie efectuate procesarile de durata. In acest fel, browserul poate detecta fisierele CSS si JavaScript necesare, le poate cere si descarca asteptand in rastimp dupa restul paginii. In PHP acest lucru poate fi facut printr-un apel la functia Flush.

Similar, daca sectiunea albastra de descarcare a continutului este straniu de lunga, serverul s-ar putea sa fi trimis jumatate din pagina si munceste din greu sa trimita cealalta jumatate.

In acest caz, puteti face cateva imbunatatiri rapide pentru a mari viteza bazei de date prin indexarea regulate a coloanelor folosite, optimizarea tabelelor si folosind la maximum cachingul interogarilor. Puteti sa va adanciti mai adanc in cod, incercand sa reduceti numarul interogarilor sau sa creati pe server zone cache pentru partile intensive din site. De asemenea, consultati-va cu furnizorul de hosting pentru a va asigura ca serverul dispune de o cantitate suficienta de memorie RAM si ca variabilele de configurare sunt adecvate.

Concluzie

Acest articol a prezentat catva sfaturi la indemana oricui pentru accelerarea site-urilor care, speram, vor da un impuls in rankinguri si o experienta mai placuta pentru utilizatori.