Viteza de incarcare a site-ului, parte a algoritmului de cautare Google

20 April 2010 la 10:14 19

Using site speed in web search ranking

You may have heard that here at Google we’re obsessed with speed, in our products and on the web. As part of that effort, today we’re including a new signal in our search ranking algorithms: site speed. Site speed reflects how quickly a website responds to web requests. (de aici)

Pentru a afla cat de rapid este site-ul tau, va trebui sa folosesti instrumentele pentru webmasteri si sa accesezi Labs / Performantele site-ului, unde vei da peste un mesaj de genul:

În medie, încărcarea paginilor de pe site-ul dvs. durează 7,5 (de) secunde (actualizat la data de 18.04.2010). Acest site este mai lent decât 88% dintre site-uri. Aceste estimări au un grad de acurateţe mediu (între 100 şi 1000 (de) puncte de date).

Diagrama de mai jos arată modul în care durata medie de încărcare a paginilor de pe site-ul dvs. s-a modificat în ultimele luni.

Pentru evidenţele dvs., este afişată şi valoarea centilei 20 rezultată din compararea tuturor site-urilor, delimitându-se site-urile cu încărcare lentă de cele cu încărcare rapidă.

Si noi acum ce facem? Ne intoarcem la hostingul din Statele Unite? Nu. Ne apucam sa eliminam toate mizeriile din cod. Iar paranoicii vor fi la fel de atenti cand fac site-uri, precum eram cu totii prin ’98-2000, pe vremea cand optimizam fiecare pagina pentru a se putea incarca pe dial-up :-).

Trimite prin email.

Despre autorul articolului

Constantin Cocioaba | Owner @ refresh.ro
Profil LinkedIn | Twitter | Blog personal

Autorul a scris 3767 articole. Vezi articolele scrise de Costin

Contact refresh.ro: contact@refresh.ro // 0764.22.53.77

Comentarii

19 Responses to “Viteza de incarcare a site-ului, parte a algoritmului de cautare Google”

1
geea Says:
April 20th, 2010 at 7:20 am
RT @eCostin: Viteza de incarcare a site-ului, parte a algoritmului de cautare Google http://sp2.ro/5b4b49 (refresh.ro)
via uberVU
2
Eugenia Cosinschi Says:
April 20th, 2010 at 7:20 am
RT @eCostin: Viteza de incarcare a site-ului, parte a algoritmului de cautare Google http://sp2.ro/5b4b49 (refresh.ro)
3
eCostin Says:
April 20th, 2010 at 9:42 am
Apar si solutii pentru modificarea algoritmului Google Search. :-) http://sp2.ro/61515d
via uberVU
4
danielbuca Says:
April 20th, 2010 at 9:45 am
solutii de adaptare ;) RT @eCostin: Apar si solutii pentru modificarea algoritmului Google Search. :-) http://sp2.ro/61515d
via uberVU
5
blogway Says:
April 20th, 2010 at 10:26 am
Si asa ne dam seama daca sa mai facem niste optimizari la site RT @eCostin: Modificarea algoritmului Google Search. :-) http://bit.ly/8XzRye
via uberVU
6
Daniel Buca Says:
April 20th, 2010 at 12:38 pm
Modificarea asta in algoritmul google face sens, problema este in curtea noastra :)
Ca pentru orice problema exista, insa, mai multe rezolvari.
Pe de o parte ai partea de optimizare la sange a codului (am scris recent un articol pe tema asta) dar, daca vrei mai mult, poti apela si la alte artificii. Unul din aceste artificii este mirror hosting in datacentere europene din nodurile mari + server bun de statice + replicare continut periodic de pe serverul real pe serverul de statice.

Daca este nevoie intru “mai adanc” in detalii ;)
7
andrei009 Says:
April 20th, 2010 at 12:39 pm
pt blog ai putea folosi amazon s3 ca host pt imagini, video, etc. daca transferul se face prin amazon cloudfront ar fi si mai bine. exista si un plugin pt wordpress care usureaza totul http://wordpress.org/extend/plugins/tantan-s3/
8
Adi Says:
April 20th, 2010 at 12:47 pm
Cel mai simplu e sa incepi cu un YSlow si sa rezolvi cat mai multe din problemele raportate. Pana ajungi la replicare si mirror hosting (inabordabil ca pret pentru multi) sunt multe altele de optimizat.
9
Daniel Buca Says:
April 20th, 2010 at 12:52 pm
@Adi:
In afirmatia mea am plecat de la presupunerea ca un programator bun, atunci cand face o aplicatie, se gandeste la toate optimizarile de cod necesare iar cand aplicatia intra in productie sunt rezolvate problemele de baza.
Solutia propusa de mine este pentru cei care au deja un site corect dpdv tehnic si acum au primit o penalizare si vor, totusi, un avans fata de concurenta.
Pentru acestia costurile implicate nu sunt o problema (vorbim de un server de statice, nu de vreo racheta).
10
sorin Says:
April 20th, 2010 at 1:07 pm
Un hosting in afara poate rezolva o parte din problema de viteza? Ma gandesc ca Germania sau Franta, Italia, Spania au o legatura mai buna cu DC_urile Google.
11
Daniel Buca Says:
April 20th, 2010 at 1:40 pm
Site-urile din .ro sunt crawl-uite din 3 locatii (us, eu si rusia). Discovery-ul este, in general, facut de serverele din us.
In rusia nu merita sa pui servere pt ca este un singur datacenter google, la moscova.
Cea mai buna solutie este Frankfurt din urmatoarele motive:
- viteza de la noi pana la ei este foarte buna (mai buna decat pana in us)
- viteza de la Fra pana in state este iarasi foarte buna adica response time-ul pana in us este foarte bun
- crawlere-le europene sunt in datacentere care ajung in nodul din Fra

O harta cu datacenterele google gasiti aici http://www.wayfaring.com/maps/show/48030 .

Nu mai stiu exact daca crawlere-le adsense vin doar din us sau si din europa. (importanta crawler adsense = un site pe care adsense-ul performeaza bine rezulta in ridicare in serp, asta e valabil pentru site-uri mici/medii)
12
Bogdan Gheorghe Says:
April 20th, 2010 at 4:36 pm
1. Pentru siteuri cu vizitatori romani, hostingul in Romania este de dorit in continuare, chiar daca Gooogle te arata slow. E de preferat un datacenter bine conectat ;)
2. Pentru trafic international exista tot la google un help excelent.
- optimizati JS-urile, macar cele asupra carora aveti acces.
- daca folositi Google Analytics, implementati codul asincron
- serviti contentul static de pe domenii cookieless
- daca aveti un trafic mare international, atunci mutati macar contentul static pe domenii cookieless hostate pe CDN.
3. Folositi gzip/deflate
4. Optimizati codul html, folositi css extern
13
Piticu21 Says:
April 20th, 2010 at 7:56 pm
@daniel crawlarele pentru piticu vin doar din state :)

din fericire (!!!) am 59 ms ping pana in serverul ala de pe piticu.ro :)
14
Daniel Buca Says:
April 20th, 2010 at 8:02 pm
@piticu: eu zic ca este un server special care se ocupa de piticu.ro si refresh.ro :) si s-au gandit sa-l tina in cel mai tare datacenter al lor care, bineinteles, este in state ;)

serios acum: 59ms e super tare
15
Marcel Says:
April 20th, 2010 at 8:57 pm
Ingineresc vorbind, daca imbunatatesti timpul de incarcare ai de castigat. Insa daca toata lumea lasa lucrurile asa cum sunt acum, atunci nu vor aparea modificari semnificative pentru ca nimeni nu va pierde nimic in raport cu ceilalti.

Sa fim seriosi: chiar este o solutie sa-mi pun imaginile pe alt server sau este o, solutie ca toate site-urile sa aiba mirror hosting? Astea sunt cazuri particulare :-)
16
A.Faith Says:
April 21st, 2010 at 12:22 am
sincer, eu văd o treabă excelentă din partea Google decizia asta! poate așa se mai gândesc și webmasterii români să nu mai includă nșpe mii de inutilități în site-uri și să facă încărcarea un chin chiar și pentru o conexiune broadband serioasă.

în plus, e chin să încarci un site mai mare de pe mobil și să aștepți chiar și câteva minute bune via 3G din cauza unor imagini și coduri neoptimizate. susțin cu 2 mâini ridicate sus inițiativa asta.
17
Dan Rades Says:
April 21st, 2010 at 10:04 pm
Comentariile de mai sus ma fac sa cred ca unii dintre voi n-au fost suficient de curiosi sa citeasca explicatiile date de Google cu privire la modalitatea de calcul a acestui indicator.
Keyphrase: It is collected directly from users who have installed the Google Toolbar and have enabled the optional PageRank feature. (explicatiile detaliate aici: http://www.google.com/support/webmasters/bin/answer.py?answer=158541&hl=en)

Deci nu are absolut nicio importanta din ce DC-uri vine botul, sau cat de mic e pingul catre acesta.

Problema cea mai mare cu acest mod de calcul este ca acesta e dependent de calitatea conexiunii la net a utilizatorului. Pagini care se genreaza sub 0.5 secunde ajung sa aiba un timp total de output (doar contentul html – fara imagini / flashuri etc) > 2-3 secunde. Va spun asta din teste facute in amanunt pe unele dintre cele mai importante siteuri din .ro

Cateva sfaturi pentru o performanta cat mai buna:
1. scripts at the bottom. Foarte usor o pagina poate sa ajunga sa contina mai mult de 10 scripturi, iar daca sunt puse in head blocheaza incarcarea continutului pana cand acestea sunt incarcate.
2. Pe cat posibil impachetati in 1-2 fisiere scripturile js, se pierde o gramada de timp facand atatea requesturi catre server.
3. Apache cu mod_gzip activat
4. Varnish sau alta solutie similara pentru continutul static (imagini/flash/js/css)
5. Daca punctul 4 este bifat: KeepAliveTimeout cat mai mic (sau chiar KeepAlive off). Daca nu este bifat atunci neaparat KeepAlive on si un KeepAliveTimeout decent
6. Decuplarea generarii cacheului de actiunile userilor intr-o masura cat mai mare. Generarati in background cat mai multor ‘bucati’ de pagina iar cele mai accesate pagini generati-le in totalitate
7. Folositi tooluri de profiling de la inceputul dezvoltarii aplicatiei, nu dupa ce aceasta gafaia cand e in productie.

Ar mai fi destule de zis, dar Googleul e mare si astfel de informatii pot fi gasite usor atata timp cat exista preocupare pentru asta.
18
ltaloi Says:
April 25th, 2010 at 8:39 am
Citesc/Reading: Viteza de incarcare a site-ului, parte a algoritmului de cautare Google: Using site speed in web s… http://bit.ly/c9sm5W
via uberVU
19
Liviu Taloi Says:
April 25th, 2010 at 8:39 am
Citesc/Reading: Viteza de incarcare a site-ului, parte a algoritmului de cautare Google: Using site speed in web s… http://bit.ly/c9sm5W