Ce mai citesc
Analysis of Sources of Latency in Downloading Web Pages
Posted by Bogdan Nedelcu on Fri, 16 Oct 2009 08:24:38 -0500 in Web Performance
Un research excelent legat de componentele ce determina timpii de incarcare a paginilor web.
Pdf Source
Pdf Source
Vanity, Lungimea Domeniului si Marimea Fisierului
Posted by Bogdan Nedelcu on Thu, 08 Oct 2009 15:29:56 -0500 in Web Performance
Vreau sa pun toate imaginile unui site pe un CDN,
respectiv pe un alt domeniu. Dar ce nume sa aleg?
Well, cred ca decizia se poate lua in functie de 2 criterii: lungimea domeniului si denumirea in sine.
Dar care dintre criteriile acestea valoreaza mai mult?
Mai putine caractere intr-un domeniu conduce catre o reducere a fisierului html si css, respectiv creste viteza de incarcare a site-ului.
Un nume de domeniu care foloseste acronimul site-ului principal arata mai profesional. Ex: youtube.com foloseste ytimg.com iar facebook.com - fbcdn.net.
Am facut un test in care sa vad cat de mult influenteaza lungimea domeniului marimea paginii. Pentru ca tot am scris intr-un post anterior de rebuild-ul siteului Shopzilla, am zis sa il iau ca si element de studiu.
In prezentarea respectiva, cei de la Shopzilla au ales sa puna toate imaginile si fisierele statice pe un domeniu separat. Logica acestei mutari este data de faptul ca se reduce traficul de date cu un 1KB, datorita faptului ca imaginile livrate de pe alt domeniu nu mai trimit si cookies.
Amuzant este faptul ca, dupa ce am facut testul, am observat ca acel 1KB se anuleaza, datorita alegerii unui domeniu cu o lungime mult prea mare, chiar si pentru un vanity domain. Au ales sa puna imaginile pe img01.shopzilla-images.com. In mod normal, ar fi trebuit sa aleaga un domeniu de tipul s.simg.com.
La realizarea testului am luat o medie de 90 de componente(js/css/img).
Rezultatul:
Dar pentru a face si pe avocatul diavolului, trebuie totusi sa fac o precizare. Daca pagina este trimisa prin compresie, atunci aceasta diferenta se reduce considerabil, din cauza ca principalul algoritm al oricarei metode de compresie este data de inlocuirea unor siruri similare cu indecsi de lungime mai mica. Pe de alta parte ... :) dar gata, nu mai bat campii. Intrebarea ramane.
Well, cred ca decizia se poate lua in functie de 2 criterii: lungimea domeniului si denumirea in sine.
Dar care dintre criteriile acestea valoreaza mai mult?
Mai putine caractere intr-un domeniu conduce catre o reducere a fisierului html si css, respectiv creste viteza de incarcare a site-ului.
Un nume de domeniu care foloseste acronimul site-ului principal arata mai profesional. Ex: youtube.com foloseste ytimg.com iar facebook.com - fbcdn.net.
Am facut un test in care sa vad cat de mult influenteaza lungimea domeniului marimea paginii. Pentru ca tot am scris intr-un post anterior de rebuild-ul siteului Shopzilla, am zis sa il iau ca si element de studiu.
In prezentarea respectiva, cei de la Shopzilla au ales sa puna toate imaginile si fisierele statice pe un domeniu separat. Logica acestei mutari este data de faptul ca se reduce traficul de date cu un 1KB, datorita faptului ca imaginile livrate de pe alt domeniu nu mai trimit si cookies.
Amuzant este faptul ca, dupa ce am facut testul, am observat ca acel 1KB se anuleaza, datorita alegerii unui domeniu cu o lungime mult prea mare, chiar si pentru un vanity domain. Au ales sa puna imaginile pe img01.shopzilla-images.com. In mod normal, ar fi trebuit sa aleaga un domeniu de tipul s.simg.com.
La realizarea testului am luat o medie de 90 de componente(js/css/img).
Rezultatul:
| img01.shopzilla-images.com | 2.45KB |
| s.simg.com | 1.05KB |
Dar pentru a face si pe avocatul diavolului, trebuie totusi sa fac o precizare. Daca pagina este trimisa prin compresie, atunci aceasta diferenta se reduce considerabil, din cauza ca principalul algoritm al oricarei metode de compresie este data de inlocuirea unor siruri similare cu indecsi de lungime mai mica. Pe de alta parte ... :) dar gata, nu mai bat campii. Intrebarea ramane.
Shopzilla - You Get What You Measure
Posted by Bogdan Nedelcu on Sat, 03 Oct 2009 10:02:42 -0500 in Web Performance
Philip Dixon, a avut o prezentare interesanta in acest an la Velocity Conference, legata de rebuild-ul site-ului Shopzilla.
Din cate am observat din prezentare, refacerea site-ului a constat atat in modificari tehnologice cat si in ceea ce priveste optimizarea site-ului din perspectiva vitezei de incarcare.
In prezentarea de fata, responsabilul cu redo-ul siteului a dat share la niste cifre interesante legate de trafic si conversii in raport direct cu viteza de incarcare a site-ului.
Chiar daca prezentarea s-a concentrat aproape in totalitate pe partea de front-end optimization, am totusi convingerea ca rebuild-ul site-ului s-a concentrat mai mult pe o structurare mai eficienta a platformei, indeosebi a gradului de independenta a diverselor module din site. Spun asta pentru ca, din urma analizei pe care am facut-o eu asupra siteului, nu am intalnit prea multe tweak-uri de optimizare pe partea de browser side.
Cateva concluzii din acest video:
- servirea imaginilor de pe alt server, fara cookies, a crescut profiturile Shopzilla cu 0.5% (datorata reducerii cu 400ms a vitezei de incarcare la utilizatorii de DIAL-UP);
- rata conversiei a crescut cu 7-12%;
- performanta in Google Adwords a crescut cu 120% (testat pe bizrate.co.uk);
- numarul de pagini vizitate a crescut cu 25%;
- SEM sessions au crescut cu 8 procente.
Din cate am observat din prezentare, refacerea site-ului a constat atat in modificari tehnologice cat si in ceea ce priveste optimizarea site-ului din perspectiva vitezei de incarcare.
In prezentarea de fata, responsabilul cu redo-ul siteului a dat share la niste cifre interesante legate de trafic si conversii in raport direct cu viteza de incarcare a site-ului.
Chiar daca prezentarea s-a concentrat aproape in totalitate pe partea de front-end optimization, am totusi convingerea ca rebuild-ul site-ului s-a concentrat mai mult pe o structurare mai eficienta a platformei, indeosebi a gradului de independenta a diverselor module din site. Spun asta pentru ca, din urma analizei pe care am facut-o eu asupra siteului, nu am intalnit prea multe tweak-uri de optimizare pe partea de browser side.
Cateva concluzii din acest video:
- servirea imaginilor de pe alt server, fara cookies, a crescut profiturile Shopzilla cu 0.5% (datorata reducerii cu 400ms a vitezei de incarcare la utilizatorii de DIAL-UP);
- rata conversiei a crescut cu 7-12%;
- performanta in Google Adwords a crescut cu 120% (testat pe bizrate.co.uk);
- numarul de pagini vizitate a crescut cu 25%;
- SEM sessions au crescut cu 8 procente.
Amazon CloudFront - concluzia unui utilizator
Posted by Bogdan Nedelcu on Thu, 01 Oct 2009 15:47:13 -0500 in Web Performance
Citeam mai devreme postul unui blogger legat de CDN-uri, si in mod special legat de Amazon CloudFront.
Dupa ce autorul articolului a facut o descriere in detaliu a ceea ce inseamna CDN, avantajele pe care acest sistem de distributie le ofera si o enumerare a principalelor oferte din piata, incheie articolul cu o concluzie legata de CDN-ul Amazon, pe care il si utilizeaza de altfel. Pe mine m-a amuzat, mai ales sinceritatea cu care a pus problema, fapt pentru care il redau si aici:
Intrebarea ramane: cand este momentul si cand este rentabil sa apelezi la un Content Delivery Network?
My biggest concern is that I'll take a bath in service charges if my usage spikes for some reason---such as getting an Instalaunch or Slashdotted or a high rating on Digg. In theory, the additional traffic will eventually convert to more regular readers and therefore more ad revenue, but that takes a while, whereas my Cloudfront bill is due immediately.
The real questions are, does this make my site any faster? And does that higher speed encourage more people to visit? And do the extra visitors translate to more revenue?
The truth is, although the site feels like it loads faster, I haven't actually benchmarked it, and I don't track my conversion numbers, so I have no way of knowing how much money this is making me. I just did it because I thought it was cool.
Intrebarea ramane: cand este momentul si cand este rentabil sa apelezi la un Content Delivery Network?
Front End Optimization - FavIcon Size
Posted by Bogdan Nedelcu on Tue, 15 Sep 2009 12:09:11 -0500 in Web Performance
Am obiceiul ca, atunci cand intru mai des pe anumite site-uri, sa ma uit si prin codul sursa al paginii. De multe ori dai peste un cod impecabil iar de alte multe ori intalnesti si situatii amuzante ce pot tine de: comentariile in cod, lungimea si denumirea class-urilor si asa mai departe.
La un moment dat am intrat pe site-ul celor de la nod32 unde mi-a sarit in evidenta marimea favicon-ului. Daca in mod normal o astfel de imagine are fix 1.1K, in cazul de fata este de 104.4K.Adica era mai mare decat suma dintre documentul HTML(21.3K), 3 fisiere javascript(36.1K) si fisierul CSS de 26.9K.
Ce inseamna 104.4K pentru un vizitator care are un abonament de Internet Mobil si care a depasit limita de trafic lunar?
Marea majoritate a providerilor de internet mobil, dupa un anumit consum, limiteaza automat viteza de download la 128kbs, adica 16KB/s. In cazul de fata, vizitatorul care intra pe site-ul eset.ro, ii vor trebui 6.5 secunde numai pentru a incarca favicon-ul, stiti voi, iconita aceea care apare langa URL.
Mai sunt si alte site-uri care au favicon-uri neoptimizate. As mai putea da ca exemplu si bestjobs.ro, cu un favicon de 28K. Daca mai aveti si voi alte exemple, introduceti un comentariu.
La un moment dat am intrat pe site-ul celor de la nod32 unde mi-a sarit in evidenta marimea favicon-ului. Daca in mod normal o astfel de imagine are fix 1.1K, in cazul de fata este de 104.4K.Adica era mai mare decat suma dintre documentul HTML(21.3K), 3 fisiere javascript(36.1K) si fisierul CSS de 26.9K.
Ce inseamna 104.4K pentru un vizitator care are un abonament de Internet Mobil si care a depasit limita de trafic lunar?
Marea majoritate a providerilor de internet mobil, dupa un anumit consum, limiteaza automat viteza de download la 128kbs, adica 16KB/s. In cazul de fata, vizitatorul care intra pe site-ul eset.ro, ii vor trebui 6.5 secunde numai pentru a incarca favicon-ul, stiti voi, iconita aceea care apare langa URL.
Mai sunt si alte site-uri care au favicon-uri neoptimizate. As mai putea da ca exemplu si bestjobs.ro, cu un favicon de 28K. Daca mai aveti si voi alte exemple, introduceti un comentariu.
Pagini web mai rapide, exit rate-uri mai mici
Posted by Bogdan Nedelcu on Thu, 06 Aug 2009 09:54:12 -0500 in Web Performance
Acum 2 saptamani, in San Jose California s-a desfasurat editia din 2009 a OSCON, conventie ce aduna peste 3000 de expertii si vizionari pentru a discuta ultimele trenduri si tehnologii din lumea open-source, urmarind domenii de interes
precum Linux, PHP, Perl, Python, Ruby, Java, Mobile, Databases, Desktop Applications, Web Applications, Administration, Security, People, Business si alte domenii emergente.
Una dintre prezentari, cea a lui Artur Bergman, VP of Engineering la Wikia, a avut o tractiune puternica la cei interesati de optimizarea si viteza de incarcare a site-urilor web. Prezentarea acestuia - "Varnish - A State of the Art High-Performance Reverse Proxy", a fost legata de proxy-ul open-source Varnish, asa cum de altfel o spune si titlul. Ce a atras cel mai mult atentia, cel putin la nivel general, a fost acest slide:
Wikia a analizat legatura dintre viteza de incarcare a paginii si exit rate. Daca luam 3 puncte pe acest grafic putem genera urmatorul tabel:
Dupa cum se vede, dorinta de a avea un site cat mai rapid nu poate fi pus doar pe seama unei simple ambitii webmastericesti sau a unei demonstratii de forta. Viteza de incarcare are un impact puternic asupra business-ului in general, gandindu-ma aici la user retention , cresterea vanzarilor, a castigurilor din publicitate(CPM) sau indirect, prin prisma unor punctaje mai bune in algoritmi precum cei implementari in Google Adwords Quality Score.
Una dintre prezentari, cea a lui Artur Bergman, VP of Engineering la Wikia, a avut o tractiune puternica la cei interesati de optimizarea si viteza de incarcare a site-urilor web. Prezentarea acestuia - "Varnish - A State of the Art High-Performance Reverse Proxy", a fost legata de proxy-ul open-source Varnish, asa cum de altfel o spune si titlul. Ce a atras cel mai mult atentia, cel putin la nivel general, a fost acest slide:
Wikia a analizat legatura dintre viteza de incarcare a paginii si exit rate. Daca luam 3 puncte pe acest grafic putem genera urmatorul tabel:
| Viteza de incarcare(s) | Exit rate(%) |
| 3s | 20% |
| 2s | 15% |
| 1s | 10% |
Dupa cum se vede, dorinta de a avea un site cat mai rapid nu poate fi pus doar pe seama unei simple ambitii webmastericesti sau a unei demonstratii de forta. Viteza de incarcare are un impact puternic asupra business-ului in general, gandindu-ma aici la user retention , cresterea vanzarilor, a castigurilor din publicitate(CPM) sau indirect, prin prisma unor punctaje mai bune in algoritmi precum cei implementari in Google Adwords Quality Score.
Traffic Spike: gsp.ro+prosport.ro=Praf
Posted by Bogdan Nedelcu on Wed, 10 Jun 2009 14:20:54 -0500 in Web Performance
In timpul si la sfarsitul meciurilor din ultima etapa a Ligii I de fotbal am intrat pe principalele site-uri de stiri fotbalistice (stirile din alte sporturi tind catre 0).
Concluzia?
prosport.ro si gsp.ro sunt praf in fata spike-urilor de trafic. Presupun ca nu exista niciun fel de optimizare a celor doua site-uri. Dupa ce isi vor reveni un pic, chiar sunt curios sa le analizez pe partea de front-end.
Dar pana la urma ce sa ne mai miram de versiunile online ale celor 2 publicatii, cand avem un exemplu chiar in difuzarea meciului Urziceni-Steaua pe tv: prima repriza s-a terminat 0-0. Vine pauza, intra reclame, se termina reclamele, reincepe difuzarea in direct la scorul de 0-1.
Concluzia?
prosport.ro si gsp.ro sunt praf in fata spike-urilor de trafic. Presupun ca nu exista niciun fel de optimizare a celor doua site-uri. Dupa ce isi vor reveni un pic, chiar sunt curios sa le analizez pe partea de front-end.
Dar pana la urma ce sa ne mai miram de versiunile online ale celor 2 publicatii, cand avem un exemplu chiar in difuzarea meciului Urziceni-Steaua pe tv: prima repriza s-a terminat 0-0. Vine pauza, intra reclame, se termina reclamele, reincepe difuzarea in direct la scorul de 0-1.
BogdanNedelcu.com
© 2007, All rights Reserved.
© 2007, All rights Reserved.