Nu am pornit cu PageSpeed Insights. E util, dar sintetic, un test dintr-o locație, un moment din zi, o configurație de device. Am pornit cu date reale de la utilizatori. Site-ul avea Google Analytics 4, deci aveam deja Core Web Vitals raportate din trafic real (Field Data), plus am configurat rapid un dashboard în CrUX (Chrome UX Report) filtrat pe origine.

Rezultatele pe 28 de zile, mobile:

• LCP (Largest Contentful Paint): p75 = 4.8s (Google vrea < 2.5s)
• INP (Interaction to Next Paint): p75 = 380ms (target < 200ms)
• CLS (Cumulative Layout Shift): p75 = 0.28 (target < 0.1)

Toate trei metricile în roșu. Pe desktop era doar LCP problemă (~3.1s), restul OK. Deci focus principal: mobile + LCP.

Am rulat un waterfall real cu WebPageTest.org, locație Frankfurt, profil “Moto G4 + 4G Slow” (profilul default pentru Core Web Vitals). Ce a ieșit:

TTFB:          1.42s    <-- server-side, foarte lent
Start Render:  3.10s
LCP element:   4.85s    (imagine hero 480KB, unoptimized)
Total Blocking Time: 620ms
Requests:      147
Total bytes:   3.8 MB

Trei probleme mari: TTFB de 1.4 secunde (backend), imagine hero neoptimizată (WebP salvează 60%), și un banner de cookies care schimba layout-ul la ~2s (CLS).

Am atacat pe cele trei axe, în ordinea impactului:

1. TTFB — infra + caching. Site-ul rula pe un VPS OVH modest, WordPress + WooCommerce, fără caching serios. Am făcut trei modificări: (a) am pus Cloudflare în față cu APO (Automatic Platform Optimization) activat pentru WordPress, care servește pagini pre-renderate din edge; (b) am configurat un Redis local pentru object cache și persistent transients; (c) am pus PHP-FPM cu OPcache dimensionat corect (256MB) și am tăiat pluginurile heartbeat gen “activity log” care făceau AJAX la fiecare 15s. TTFB a scăzut la 340ms pe pagini cache-uite din CF, ~680ms pe cele dinamice (cart, checkout).

2. LCP — imaginile. Cloudflare Polish + Mirage pornit, plus un plugin de conversion la WebP/AVIF automat. Hero image a scăzut de la 480KB la 78KB. Am adăugat fetchpriority="high" pe img-ul principal și loading="lazy" pe restul. Un preload în head:

<link rel="preload"
      as="image"
      href="/hero.webp"
      fetchpriority="high"
      imagesrcset="/hero-480.webp 480w, /hero-960.webp 960w"
      imagesizes="100vw">

3. CLS — bannerul de cookies. Cel mai rapid fix: am rezervat spațiu fix pentru banner cu min-height pe container-ul lui, chiar dacă apare la 2s. Nu mai împinge nimic. Plus, am eliminat un slider care se hidrata târziu și făcea shift pe elementele de sub el.

După două săptămâni de re-measurement în CrUX:

• LCP p75 mobile: 4.8s → 2.1s
• INP p75: 380ms → 165ms
• CLS p75: 0.28 → 0.04

Toate trei în verde. Quality Score mediu pe cuvintele cheie principale a urcat de la 4 la 7 în ~3 săptămâni (Google recalculează treptat). CPC mediu a scăzut de la 0.71 EUR înapoi la ~0.45 EUR. Cu același buget, clientul a obținut cu ~35% mai multe click-uri și cu ~22% mai multe conversii în luna următoare.

Multă lume separă rigid “SEO/Ads = marketing” și “infrastructură = IT”. Cazul ăsta arată exact opusul: dacă TTFB-ul e 1.5s și LCP-ul 5s, poți să ai cea mai bună strategie de bidding din lume, tot ai plăti scump. Google recompensează la propriu paginile rapide, iar diferența dintre un LCP de 2.1s și unul de 4.8s se vede direct în factură.

Trei lecții pe care le-am tras:

• Prima, măsoară cu Field Data, nu doar Lab Data. PageSpeed îți spune o poveste, CrUX îți spune adevărul. Google folosește Field Data pentru Quality Score, nu ce vezi tu în DevTools.
• A doua, Cloudflare APO pentru WordPress e cel mai bun 5 EUR/lună pe care îl poți cheltui într-un SMB e-commerce. Nu întotdeauna e suficient, dar rezolvă 70% din problemele de TTFB fără să atingi codul.
• A treia, partea de infra și partea de campanii trebuie discutate împreună. Dacă lucrezi doar pe una fără să te uiți la cealaltă, lași bani pe masă. La proiectul ăsta am făcut partea de tuning tehnic, dar pentru partea de campanii, copy și structură de conturi Google Ads am lucrat împreună cu SignalForge, agenția care se ocupă de partea de web development + growth pe Google Ads.
• Combinația celor două discipline — DevOps pe pagină și optimizare pe cont — a dus la rezultatul final. Dacă ai un magazin online și simți că plătești prea mult pe click fără să știi de ce, verifică ambele părți înainte să dai vina pe piață.