Un site Drupal lent pornește aproape de fiecare dată aceeași discuție.
Pagina principală apare după câteva secunde. Echipele interne încep să se întrebe dacă găzduirea e de vină, dacă designul e prea greu sau dacă toată platforma trebuie înlocuită. După un timp, "poate că Drupal e problema" devine explicația comodă.
De cele mai multe ori, e și cea greșită.
Site-urile Drupal lente nu sunt lente, de regulă, pentru că sunt Drupal. Sunt lente din cauza unor straturi de balast tehnic pe care nimeni nu a avut timpul, mandatul sau priceperea să le curețe cum trebuie.
Lentoarea e un simptom, nu un diagnostic
Problemele de performanță vin rareori dintr-o singură cauză dramatică. Mai des vin din câteva mai mici, adunate una peste alta: imagini supradimensionate, cache slab configurat, module inutile, interogări neoptimizate și decizii de frontend care păreau inofensive luate separat.
De aceea site-urile devin adesea mai lente cu timpul. Se tot adaugă funcționalități, dar nimeni nu curăță balastul care se strânge dedesubt.
Așa că, înainte să se gândească cineva la o reconstrucție, e bine să știi ce găsim de fapt când deschidem un site lent și ne uităm cu atenție. Din experiența noastră, cauza e aproape întotdeauna una dintr-un set restrâns de probleme concrete și rezolvabile, și niciuna nu cere să o iei de la zero.
Cache configurat greșit, nu inexistent
Fiecare site Drupal are cache. Întrebarea e dacă e configurat corect. Găsim frecvent site-uri în care un strat de cache își face treaba, iar altul e oprit pe tăcute, sau în care un singur bloc forțează reconstruirea întregii pagini la fiecare cerere, sau în care un modul contrib dezactivează cache-ul pe fiecare pagină pe care apare, fără să observe nimeni.
Soluția nu e "pornește cache-ul". E să verifici fiecare strat pe rând (page cache, render cache și cache-ul CDN) și să găsești configurarea greșită care rupe lanțul. Drupal poate fi rapid, dar are nevoie ca straturile lui de cache să fie puse la punct. Vedem adesea site-uri în care cache-ul există pe hârtie, dar aproape niciodată nu aduce câștigul pe care ar trebui să îl aducă. De cele mai multe ori, remedierea e o modificare de configurare, nu de cod.
O bază de date care face muncă inutilă la fiecare cerere
Stratul de abstractizare a bazei de date din Drupal e excelent pentru corectitudine, dar nu se optimizează singur pentru performanță. O pagină care listează multe elemente, fiecare cu mai multe câmpuri, poate genera un număr mare de interogări. Dacă interogările nu sunt optimizate, cu indexuri lipsă sau cu tipare care scanează mai multe date decât e nevoie, timpii de răspuns cresc odată cu volumul de conținut.
De aceea site-urile care păreau cândva rapide devin lente după un an de publicare. Codul nu s-a schimbat. Cantitatea de date, da. Interogările care mergeau repede pe puțin conținut devin o povară pe mult conținut.
Remedierea e de obicei nespectaculoasă: adaugi indexurile care lipsesc, rescrii view-urile și interogările care scanează tabele întregi și pui în cache entitățile citite cel mai des. Interogările fără cache, repetate la fiecare cerere, se adună, iar când dispar, tot site-ul respiră mai ușor.
Imagini servite la dimensiunea originală
E una dintre cele mai frecvente probleme de performanță și una dintre cele mai ușor de rezolvat. Un editor încarcă o fotografie direct din aparat. Drupal păstrează originalul și îl servește ca atare. Browserul descarcă fișierul întreg și abia apoi îl micșorează pe ecran. Fiecare vizitator plătește costul acelei descărcări, iar pe o conexiune mobilă diferența se vede imediat.
Drupal are stiluri de imagine care redimensionează și comprimă imaginile automat, dar ele ajută doar dacă sunt configurate pentru fiecare câmp de imagine și fiecare mod de afișare. Pe site-urile pe care le audităm, aproape întotdeauna găsim măcar un câmp de imagine care servește încă originale.
Remedierea e să configurezi stiluri de imagine responsive cu un format modern, comprimat, să amâni încărcarea imaginilor de sub zona vizibilă și să setezi corect atributele de lățime și înălțime, ca pagina să nu sară pe măsură ce sosesc imaginile. Efectul combinat e de obicei o pagină vizibil mai ușoară, fără nicio pierdere de calitate vizuală.
Prea multe module care fac prea puțin
Un site Drupal tipic adună de-a lungul vieții un număr mare de module contrib. Fiecare înregistrează hook-uri, poate adăuga tabele în baza de date și își poate injecta propriul CSS și JavaScript. O bună parte dintre ele sunt adesea activate, dar nefolosite: rămășițe ale unor funcționalități explorate și abandonate sau dependențe ale unor module eliminate între timp.
Fiecare modul nefolosit consumă câte puțin. Destule la un loc, și consumul devine măsurabil. Audităm utilizarea modulelor și dezactivăm tot ce nu mai e necesar. E una dintre cele mai banale remedieri și una dintre cele mai sigure.
Un CDN lipsă sau configurat greșit
O rețea de livrare a conținutului servește resursele tale statice (CSS, JavaScript și imagini) de pe servere apropiate de vizitatori. Fără una, fiecare resursă pleacă dintr-o singură locație, cea a furnizorului de găzduire, ceea ce adaugă latență de rețea pentru vizitatorii aflați departe, o latență pe care nicio optimizare de cod nu o poate elimina.
Majoritatea serviciilor moderne de găzduire includ integrare cu un CDN, așa că problema nu e de obicei lipsa lui, ci felul în care e configurat: ce căi intră în cache, pentru cât timp, ce se întâmplă cu utilizatorii autentificați și cum se invalidează cache-ul când se schimbă conținutul. Un CDN configurat greșit poate fi mai rău decât niciunul, pentru că poate servi conținut vechi sau poate ocoli complet cache-ul. Configurarea corectă contează la fel de mult ca existența CDN-ului.
Cum abordăm un site Drupal lent
Începem cu măsurători, nu cu presupuneri.
Asta înseamnă să ne uităm la comportamentul real al vizitatorilor, la Core Web Vitals, la șabloanele de pagină, la tiparele de cereri și la cele mai lente părți ale experienței, în loc să ne bazăm pe un singur scor sintetic.
De acolo, împărțim de obicei munca în trei straturi.
Remedieri din primul val. Problemele evidente, dar cu câștig mare: gestionarea imaginilor, problemele de cache, greutatea inutilă adusă de scripturi terțe, cele mai proaste interogări și cele mai simple câștiguri tehnice.
Remedieri structurale. Ce îmbunătățește, pe lângă viteză, și stabilitatea pe termen lung: înlocuirea modulelor problematice, îmbunătățirea infrastructurii, simplificarea căilor de randare sau regândirea felului în care e livrat frontend-ul.
Protecție continuă. Performanța nu e ceva ce un site obține o dată și păstrează pentru totdeauna. Rămâne sănătoasă când cineva o urmărește, o măsoară și oprește regresiile evitabile înainte să se adune din nou.
Când o reconstrucție chiar e justificată
Uneori o reconstrucție chiar e răspunsul corect. Dar de obicei pentru că platforma are probleme structurale mai adânci, nu pentru că pagina principală e lentă.
O reconstrucție devine mai rezonabilă când site-ul e și greu de modificat, greu de lansat, prost modelat, fragil în operare și trage după el decizii de arhitectură care nu mai au sens. Performanța e atunci un simptom al unei probleme mai largi.
Greșeala e să sari la concluzia asta înainte să măsori ce e de fapt în neregulă.
De ce contează asta pentru afacere
Paginile lente costă atenție, încredere și conversii. Dar creează și balast intern. Echipele ajung să se teamă să atingă site-ul, fiecare schimbare pare riscantă, iar discuțiile despre îmbunătățiri alunecă spre înlocuirea totală, pentru că nimeni nu mai are încredere în platforma actuală.
Când problema reală e balastul tehnic, nu platforma, o intervenție de performanță bine țintită e de obicei mai rapidă, mai ieftină și dă mult mai puțin peste cap activitatea decât o reconstrucție. Niciuna dintre remedierile de mai sus nu cere un redesign. Cer o trecere sistematică prin cache, interogări, resurse, module și infrastructură, cu îmbunătățiri măsurabile, care continuă să dea roade pe măsură ce conținutul crește.
Întrebarea mai bună de la care să pornești
În loc să întrebi "Avem nevoie de un site nou?", întrebarea mai bună e de obicei "Ce anume îl face pe ăsta lent?"
La întrebarea asta se răspunde mai ieftin, și de multe ori răspunsul schimbă complet direcția deciziei.
Dacă site-ul tău Drupal pare lent, primul pas util nu e un brief de redesign. E o analiză tehnică clară: unde sunt blocajele, ce câștiguri sunt la îndemână și dacă platforma în sine e într-adevăr ce ține site-ul pe loc.