În ziua lansării, majoritatea site-urilor sunt mai rapide decât vor fi vreodată. Conținutul e aerisit, imaginile sunt cele alese de designeri, codul e proaspăt, și toată lumea tocmai a petrecut săptămâni întregi cu ochii pe viteză. Apoi începe viața reală. Conținutul crește, se adaugă funcționalități, se încorporează un instrument de marketing, iar optsprezece luni mai târziu cineva observă că site-ul pare mai greoi decât era, fără să poată spune exact ce anume s-a schimbat.
Nimic nu a mers prost în povestea asta. Pur și simplu asta se întâmplă cu un site viu, la fel cum o grădină nu rămâne plivită doar pentru că a fost plivită temeinic o dată. Site-urile care rămân rapide nu sunt cele cu cea mai eroică optimizare la lansare. Sunt cele la care cineva continuă să fie atent și după. Așa că noi tratăm performanța ca pe un obicei, o practică recurentă, parte din felul în care e îngrijit un site, nu ca pe un proiect cu dată de final. Iată în ce constă de fapt obiceiul ăsta, lună de lună.
De ce se erodează viteza, chiar și când nimeni nu greșește
Merită înțeles mecanismul, pentru că nu e vina nimănui și e complet previzibil. Conținutul se acumulează: mai multe pagini, mai multe elemente de meniu, mai multe imagini încărcate de mai mulți oameni, nu toate la dimensiunile pe care le presupunea direcția artistică inițială. Funcționalitățile se acumulează: fiecare modul sau integrare nouă e rezonabilă luată separat, dar toate la un loc apasă. Scripturile terților se acumulează cel mai repede, pentru că vin din afara procesului de dezvoltare; un fragment de analytics aici, un widget de chat dincolo, fiecare lipit în pagină dintr-un motiv întemeiat și fiecare încărcându-și propriul cod de pe propriile servere la fiecare afișare de pagină.
Fiecare e o decizie mică și perfect justificabilă. Viteza se pierde în grame, nu în kilograme, și tocmai de aceea nimeni nu observă pe moment, iar un efort de optimizare făcut doar la lansare nu poate fi întregul răspuns. Întrebarea care contează nu e cât de rapid era site-ul la lansare, ci cine îl urmărește acum.
Scanări continue, ca încetinirea să nu aibă unde se ascunde
Răspunsul nostru la întrebarea asta începe cu automatizarea. Site-urile pe care le avem în grijă sunt scanate pentru performanță regulat, după un calendar fix, cu același tip de măsurători de care le pasă motoarelor de căutare: cât de repede devine vizibilă o pagină, cât de curând răspunde la interacțiune, cât de stabil rămâne aspectul în timpul încărcării. Scanările rulează indiferent dacă e cineva îngrijorat sau nu, și tocmai ăsta e rostul lor. Încetinirea nu se anunță singură, așa că trebuie să stea ceva la pândă.
Scanările ne dau o tendință, nu un instantaneu. O singură măsurătoare nu îți spune aproape nimic; paginile au zile rapide și zile lente. Un istoric îți spune adevărul: șablonul ăsta se îngreunează treptat de trei luni încoace, sau pagina aia a încetinit brusc în săptămâna în care a intrat un embed nou. Cu o tendință în față, discuțiile despre performanță nu mai sunt impresii vagi, ci întrebări concrete, cu răspunsuri care se pot găsi. Și pentru că scanările urmăresc site-ul continuu, purtăm de obicei discuțiile astea cât schimbarea e încă mică, adică exact atunci când remedierile sunt ieftine.
O privire la fiecare lansare
A doua parte a obiceiului e legată de schimbarea însăși. La fiecare lansare pe un site pe care îl întreținem ne uităm și la amprenta ei de performanță, la fel cum ne uităm la funcționalitate. Aduce noua funcționalitate scripturi sau stiluri care se încarcă peste tot, dar sunt necesare pe o singură pagină? Au noile imagini dimensiuni potrivite și formate moderne? Rezistă noua pagină de listare atunci când conținutul din spatele ei e bogat, nu doar cu mâna de elemente de test cu care a fost construită?
Prinse la lansare, problemele astea costă minute. Prinse un an mai târziu, încâlcite cu tot ce a mai intrat live între timp, costă o investigație. Asta e economia discretă a obiceiului: investește puțină atenție la început ca să evite multă arheologie mai târziu. Și ține vie o cultură utilă în echipă: când fiecare lansare trece prin verificarea asta, viteza rămâne parte din ce înseamnă "gata", nu un efort special pentru care trebuie să pledeze cineva.
Cache-ul se întreține, nu doar se instalează
Cache-ul merită propria secțiune, pentru că e stratul pe care oamenii îl tratează cel mai des ca pe ceva ce setezi și uiți. Un site Drupal bine pus la punct are mai multe niveluri de cache: pagini servite întregi vizitatorilor anonimi, fragmente refolosite între pagini, interogări și calcule reținute în loc să fie repetate. Făcut bine, totul e invizibil și extrem de eficient, iar Drupal-ul modern e cu adevărat priceput la asta.
Dar un cache e un set de presupuneri despre ce poate fi refolosit și pentru cât timp, iar site-ul pentru care s-au făcut presupunerile se schimbă întruna. Tipuri noi de conținut, blocuri noi, funcționalități noi pentru utilizatorii autentificați: fiecare poate schimba pe nesimțite ce anume poate fi pus în cache. Și poate da greș în ambele direcții. Pui prea puțin în cache și site-ul încetinește; pui prea mult și cineva vede conținut expirat, iar reparația făcută în grabă e de obicei să pui și mai puțin în cache. Așa că revenim asupra straturilor de cache pe măsură ce site-ul evoluează, verificând că paginile care ar trebui servite din cache chiar sunt servite de acolo și că vizitatorii chiar merg pe traseul rapid pe care credem noi că merg. Un cache verificat rămâne un atu. Un cache în care doar te încrezi devine un zvon.
Obiceiuri de conținut, pentru că și editorii influențează viteza
Performanța nu stă toată în cod. O parte însemnată se decide în interfața de administrare, de către oamenii care publică conținut, motiv pentru care obiceiul se extinde și la ei. Site-ul însuși ar trebui să ducă greul: imaginile încărcate la orice dimensiune sunt redimensionate și comprimate automat, iar embed-urile ar trebui construite să se încarce fără să încurce restul paginii. Dar ne asigurăm și că echipele editoriale cunosc puținele lucruri care chiar contează, de pildă ce se întâmplă când o pagină adună o duzină de embed-uri grele, și preferăm să construim protecții în sistem decât să împărțim reguli. Când calea rapidă e și cea comodă, editorii păstrează site-ul iute fără să se gândească vreodată la asta, exact cum ar trebui să fie.
Cum arată, concret, o lună obișnuită
Pus cap la cap, obiceiul nu are nimic spectaculos, și tocmai asta e virtutea lui. Scanările rulează după calendarul lor, iar liniile de tendință sunt citite de cineva care cunoaște site-ul. Lansările pleacă cu amprenta verificată. Cache-ul e reverificat când site-ul își schimbă forma. Scripturile terților sunt trecute în revistă din când în când, pentru că cel mai rapid cod e cel pe care îl elimini, iar embed-urile au obiceiul să supraviețuiască campaniilor care le-au justificat. Niciunul dintre pașii ăștia nu e dramatic, și nicio lună luată separat nu arată impresionant. Rezultatul se vede doar în ani: un site care în a treia lui iarnă se simte la fel ca în prima lui săptămână.
Dacă și site-ul tău a căpătat senzația aia de greutate, vestea încurajatoare e că drumul se poate face la fel de bine și în sens invers. Aceeași practică ce ține un site rapid poate readuce pe drumul bun un site încetinit, de obicei în pași de mărimea întreținerii obișnuite, nu printr-o reconstrucție. Ne uităm cu plăcere, îți spunem deschis pe unde s-a strecurat greutatea și punem pe picioare obiceiul care o împiedică să se strecoare înapoi. Prima discuție e din partea noastră, așa a fost mereu și așa va rămâne.