Articol publicat in: Calculatoare, Internet, Tehnologie
Cu 400 de milioane de utilizatori activi, facebook ajunge la mai mult de 8 miliarde de afişări zilnice. Aşadar, a economisi 10ms / cerere înseamnă a economisi 2 ani şi jumătate zilnic pentru alte cereri. Experimentele lor au arătat că reducerea timpului de afişare cu 600ms a mărit rata de click cu 5%.
Facebook produce software după metode Agile , având câte un realease săptămânal. Astfel, cu zeci de modificări zilnice, codul nu este niciodată stabil. Nu se pot opri din dezvoltare pentru a lucra la optimizarea siteului.
O altă caracteristică a facebook este deep integration – spre deosebire de Yahoo sau Google, unde fiecare pagină reprezintă o funcţionalitate, o pagina facebook înglobează un set de larg de funcţionlităţi. Astfel, dacă apare o regresie, este dificilă identificarea funcţiei care a introdus regresia.
A treia problemă cu care Facebook se confruntă adesea este adopţia virală – dacă o funcţionlitate este folosită astăzi de câţiva utilizatori, este posibil ca mâine să fie utilizată de milioane.
Cu asemenea provocări, facebook a reuşit, la sfârşitul anului trecut, să înjumătăţească timpul de redare a paginilor (calculat ca timpul mediu pentru 75% din utilizatori):
Mai întâi trebuie menţionat că timpul de redare este compus din:
- timpul de trasfer prin reţea – timpul în care pagina ajunge de la facebook la calculatorul utilizatorului – aprox. 25%
- timpul de generare a paginii – timpul în care serverul compune pagina pt a o trimite spre browser – aprox. 25%
- timpul de afişare a paginii – timpul în care browserul parsează HTML-ul, aplică CSS-ul şi aplică JavaScriptul (în ordinea aceasta) – aprox. 50%
Cei 3 timpi compun timpul de interacţiune – TtI - Time-to-Interact.
Facebook nu se supune regulilor YSlow care spun că Javascriptul ar trebui injectat la finalul paginii, după CSS, pentru că pe paginile facebook rulează în paralel bucăţi de cod Javascript neblocante (cu excepţia primeia, care le paralelizează pe celelalte).
Facebook monitorizează viteza zilnică a siteului. În momentul în care siteul este mai încet, se analizează modificarile aduse codului în ziua precedentă, se fac teste de regresie şi se găseşte locul problemei. Analizelor li se adaugă nişte loguri de tip YSlow sau Google Speed corespunzătoare unor utilizatori selectaţi – astfel se află motivul problemei.
Managementul resurselor statice este cunoscut sub numele de cod “Haste” (grabă, rapiditate).
Reguli de dezvoltare:
- Separarea declarării resurselor faţă de livrarea efectivă
- Cererea resurselor alături de HTML-ul în care sunt utilizate
- Optimizare globală la livrare
Explicaţie: Resursele necesare unui cod HTML unitar sunt declarate lângă acest cod. Includerea lor efectivă se realizează, în schimb, după HTML. Se observă, cu ajutorul logurilor YSlow şi Google Page Speed, cum sunt folosite resursele [imagini, js, css], iar cele folosite cel mai des împreună sunt compilate în pachete prin optimizarea adaptivă a performanţelor, care conţine:
- optimizarea pachetelor JS/CSS – în 6 luni, cantitatea de JS a crescut cu 60%, dar cantitatea de pachete a scăzut cu 50%
- indicaţii pentru realizarea sprite-urilor
- indicaţii pentru randare progresivă
Proiectele interne de la facebook destinate optimizării vitezei siteului:
- Quickling – transformarea facebook în site bazat majoritar pe Ajax . S-a observat comportamentul tipic al utilzatorului facebook – newsfeed > pagină de profil > albume > … > newsfeed din nou ş.a.m.d. Browserul nu stochează în cache decât resurse statice şi le descarca şi încarcă pe masura ce utilizatorul browsează. Dacă anumite bucăţi sunt încărcate prin site prin AJAX nu mai e nevoie de descărcarea şi reîncărcarea resurselor CSS sau JS. Se reduce munca redundantă a browserului prin AJAX. Apăsarea pe un link sau buton de back/forward se tratează cu AJAX. Întâi se descarcă resursele statice (doar daca nu au mai fost incarcate niciodata) şi apoi HTML-ul. 60% dintre cererile facebook sunt cereri Quickling, care este în producţie de la jumătatea lui 2008 şi reduce timpul de afişare ale celor mai populare pagini cu 40 – 50%.
- PageCache – cachingul client-side al paginilor vizitate. Motivaţie – paginile au localitate temporală – este posibil ca ele să fie revizitate în curând. De exemplu, homepageul este vizitat la fiecare 3-5 pagini. Este construit ca supliment al Quickling. Dacă pagina există în cache, Quickling nu o mai cere serverului. Aceasta trebuie să se întâmple în timp ce site-ul trebuie să afişeze permanent ultimele actualizări. Aşadar, se aplică actualizări incrementale paginilor din cache. În plus, site-ul trebuie să reţină şi operaţiile de scriere ale utilizatorului care browsează. Serverul trimite repetitiv clientului semnale de modificare a conţinutului. PageCache reduce timpul de afişare a homepageului facebook cu 75%.
- BigPipe – într-unul dintre următoarele articole.
Lecţii:
- Este importantă monitorizarea vitezei siteului: Ce merge încet? Cine cauzează mersul lent al paginii şi de ce?
- Pentru siteurile care se modifică rapid, este extrem de important managementul resurselor statice.
- Ajaxificarea siteului poate mări performanţele de viteză
- Cachingul paginilor client-side nu numai că măresc performanţa, ci reduc semnificativ costul de datacenter
