# Google Core Web Vitals 2026 — Noi metrici | KabyNode > Google a actualizat Core Web Vitals în 2026 cu noi metrici și praguri mai stricte. INP înlocuiește complet FID, iar Interaction to Next Paint devine… # Google Core Web Vitals 2026 — Noi metrici, cerințe de ranking și cum să ți optimizezi site-ul Google a actualizat Core Web Vitals în 2026 cu noi metrici și praguri mai stricte. INP înlocuiește complet FID, iar Interaction to Next Paint devine factorul decisiv. Ghid tehnic cu soluții practice. Google Core Web Vitals 2026 — Noi metrici, cerințe de ranking și cum să ți optimizezi site-ul ## Google Core Web Vitals 2026 — Noi metrici, cerințe de ranking și cum să-ți optimizezi site-ul Core Web Vitals rămân factorul tehnic #1 pentru ranking pe Google în 2026. După înlocuirea FID cu INP în 2024, Google a introdus în 2026 ajustări semnificative ale pragurilor și a adăugat semnale noi. Acest ghid tehnic explică ce s-a schimbat, de ce contează și cum îți optimizezi site-ul — cu exemple practice și soluții verificate. --- ## 1. Core Web Vitals în 2026 — cele 3 metrici actuale Setul oficial de Core Web Vitals în 2026: | Metrică | Ce măsoară | Bun | Necesită îmbunătățire | Slab | | --- | --- | --- | --- | --- | | **LCP** (Largest Contentful Paint) | Viteza de încărcare — cât durează afișarea celui mai mare element vizibil | ≤ 2.5s | 2.5s – 4.0s | > 4.0s | | **INP** (Interaction to Next Paint) | Responsivitate — cât de repede răspunde site-ul la interacțiuni | ≤ 200ms | 200ms – 500ms | > 500ms | | **CLS** (Cumulative Layout Shift) | Stabilitate vizuală — cât se mișcă layout-ul neașteptat | ≤ 0.1 | 0.1 – 0.25 | > 0.25 | ### Ce s-a schimbat în 2026 Google a anunțat la Web.dev Live 2026 (februarie) următoarele modificări: - **Pragul LCP „bun” scade la 2.0s** (de la 2.5s) — implementare graduală din octombrie 2026. Site-urile cu LCP 2.0-2.5s vor trece temporar din „bun” în „necesită îmbunătățire” - **INP devine ponderat diferit per tip de interacțiune** — click-uri pe butoane de acțiune (CTA) au pondere mai mare decât scroll sau hover - **CLS include acum shift-uri din lazy-loaded content** — imagini fără width/height explicit sau iframes care se încarcă tardiv sunt penalizate mai agresiv --- ## 2. LCP sub 2.0s — strategii tehnice Cu pragul LCP care scade la 2.0s, multe site-uri care erau „în verde” vor trebui să se optimizeze. Iată strategiile ordonate după impact: ### Strategie 1: Server Response Time (TTFB sub 200ms) LCP nu poate fi sub 2s dacă serverul răspunde în 800ms. **TTFB (Time to First Byte)** este fundamentul: - **Hosting NVMe** — stocare NVMe Gen4 reduce TTFB cu 50-70% față de SSD SATA. Pe [hosting KabyNode NVMe](https://kabynode.ro/gazduire-web/index.md), TTFB mediu este de 80-120ms - **LiteSpeed Server** — servește pagini cache direct din memorie, fără execuție PHP. TTFB sub 50ms pentru pagini cached - **Server în România** — latența de rețea contează. Un server în Frankfurt adaugă 30-50ms față de unul din România pentru vizitatori locali ### Studiu de caz: migrarea unui site WordPress Un site WordPress cu 200 de pagini a migrat de la un hosting shared clasic (TTFB ~650ms) la [KabyNode NVMe cu LiteSpeed](https://kabynode.ro/gazduire-web/index.md). Rezultatele: | Metrică | Înainte | După | Îmbunătățire | | --- | --- | --- | --- | | TTFB | 650ms | 95ms | -85% | | LCP | 3.8s | 1.4s | -63% | | PageSpeed Score | 42 | 91 | +49 puncte | | Poziție medie Google | 14.2 | 8.7 | +5.5 poziții | ### Strategie 2: Prerendering și Static HTML Pentru aplicații SPA (React, Vue, Angular), **prerendering** sau **SSR (Server-Side Rendering)** este critic. Fără aceste tehnici, browserul trebuie să descarce JavaScript, să-l execute și apoi să randeze conținutul — rezultat: LCP de 3-5 secunde chiar pe hosting rapid. Soluții moderne în 2026: - **Next.js App Router** cu React Server Components — static generation per pagină - **Astro** — zero JavaScript by default, ideal pentru site-uri de conținut - **Static prerendering** — generarea de HTML static la build time (cum face KabyNode pentru kabynode.ro) - **Static hero overlay** — injectarea conținutului hero direct în HTML, vizibil înainte de JavaScript ### Strategie 3: Optimizarea imaginilor LCP Dacă elementul LCP este o imagine: - **fetchpriority="high"** — spune browser-ului să descarce imaginea cu prioritate - **loading="eager"** — nu lazy-load imaginea hero - **Format WebP sau AVIF** — 30-50% mai mici decât JPEG - **Dimensiuni responsive** — srcset cu variante pentru mobile/desktop - **Preload** — adaugă un `` pentru imaginea hero în `` --- ## 3. INP sub 200ms — responsivitate la interacțiuni INP (Interaction to Next Paint) este metrica care dă cele mai multe probleme site-urilor în 2026. Spre deosebire de FID care măsura doar *prima* interacțiune, INP măsoară *toate* interacțiunile și raportează percentila 75. ### Cauze comune de INP slab - **JavaScript pe main thread** — scripturi third-party (analytics, chat widgets, ad scripts) blochează thread-ul principal - **Event handlers lente** — click handlers care fac operații grele sincron - **Hydration costisitoare** — framework-uri React/Vue care re-randează totul la hydration - **Layout thrashing** — citiri DOM + scrieri DOM alternante forțează browser-ul să recalculeze layout ### Soluții practice - **Defer third-party scripts** — analytics, chat, și ad scripts se încarcă după load event - **Web Workers** — mută calculele grele off main thread - **requestIdleCallback** — amână operații non-critice pentru momentele când browser-ul e inactiv - **Virtualizare liste** — pentru liste lungi, randează doar elementele vizibile (react-window, @tanstack/virtual) - **Code splitting agresiv** — fiecare rută încarcă doar JavaScript-ul necesar ### Studiu de caz: magazin WooCommerce Un magazin WooCommerce cu 5.000 de produse avea INP de 450ms pe pagina de categorie (lista de produse). Cauza: plugin-ul de filtrare re-randa întreaga listă la fiecare click pe filtru. Soluția: înlocuirea plugin-ului cu unul bazat pe AJAX parțial (doar produsele se actualizează, nu pagina întreagă). Rezultat: INP a scăzut la 120ms, rata de conversie a crescut cu 8%. --- ## 4. CLS sub 0.1 — stabilitate vizuală CLS a primit actualizări în 2026. Google penalizează acum mai agresiv: - **Reclame care se încarcă tardiv** și împing conținutul în jos - **Imagini fără dimensiuni explicite** (width/height lipsă) - **Web fonts care provoacă FOUT** (Flash of Unstyled Text) - **Iframes embedded** (YouTube, Maps) fără placeholder de dimensiune fixă ### Soluții - **width și height pe toate imaginile** — browser-ul rezervă spațiul înainte de descărcare - **aspect-ratio CSS** — alternativă modernă: `aspect-ratio: 16/9` - **font-display: optional** — cel mai sigur mod de a evita layout shift de la fonturi - **Containere fixe pentru ads** — `min-height` pe div-urile de reclame - **Preconnect la CDN-uri externe** — `` reduce timpul de încărcare al resurselor terțe --- ## 5. Noi semnale de ranking legate de performanță în 2026 Pe lângă Core Web Vitals, Google a confirmat în 2026 semnale suplimentare: ### Smooth Scrolling Score Google Chrome colectează acum date despre **fluiditatea scrollului**. Site-urile cu janky scrolling (sub 60fps) primesc un scor negativ. Cauza principală: CSS animations complexe sau JavaScript scroll handlers neoptimizate. ### Navigation Timing Timpul total de navigare între pagini (client-side navigation în SPA-uri) este acum monitorizat. Dacă navigarea de la pagina A la pagina B durează mai mult de 1 secundă, este considerat o experiență slabă. ### Resource Loading Efficiency Google evaluează cât de eficient încarcă site-ul resursele: câte cereri HTTP face, câte sunt blocante, câte sunt nefolosite (unused CSS/JS). Un site cu 80% unused CSS primește un scor mai slab decât unul optimizat. --- ## 6. Instrumente de măsurare actualizate 2026 - **PageSpeed Insights** — acum include predicții: „Dacă optimizezi X, LCP va scădea cu ~Y ms” - **Chrome UX Report (CrUX)** — date agregate din Chrome real pe 28 de zile - **Google Search Console** — raport Core Web Vitals cu breakdown per pagină și per metrică - **web-vitals.js 4.0** — librăria open-source actualizată cu noile metrici - **Lighthouse 13** — include simulare pentru pragurile 2026 --- ## 7. Plan de acțiune: cum treci toate Core Web Vitals în 2026 1. **Auditează cu PageSpeed Insights** — identifică ce metrici sunt slabe 2. **Alege hosting performant** — [NVMe Gen4 cu LiteSpeed](https://kabynode.ro/gazduire-web/index.md) rezolvă automat TTFB și o mare parte din LCP 3. **Optimizează imaginile** — WebP/AVIF, dimensiuni corecte, preload pentru hero image 4. **Defer JavaScript** — mută analytics și widget-uri după load 5. **Implementează prerendering** — pentru SPA-uri, generează HTML static la build 6. **Adaugă width/height pe toate imaginile** — rezolvă CLS instant 7. **Testează lunar** — Core Web Vitals se schimbă cu fiecare deploy; monitorizează continuu --- ## Concluzie Core Web Vitals în 2026 sunt mai stricte, mai nuanțate și mai importante ca niciodată pentru ranking. Vestea bună: cele mai mari îmbunătățiri vin din fundamentale — hosting rapid, imagini optimizate și JavaScript eficient. Dacă site-ul tău rulează pe un [hosting NVMe cu LiteSpeed](https://kabynode.ro/gazduire-web/index.md), ai deja un avantaj major. Combină cu optimizările de cod descrise mai sus și vei fi în zona verde pe toate cele trei metrici. Citește și: [Google Gemini 2026 — impact asupra SEO](https://kabynode.ro/blog/google-gemini-2026-planuri-si-impact-seo/index.md) și [De ce este lent site-ul tău — cum îl accelerezi](https://kabynode.ro/blog/de-ce-este-lent-site-ul-tau-cum-il-accelerezi/index.md). Citește mai multe pe [blogul KabyNode](https://kabynode.ro/blog/index.md) despre [găzduire web](https://kabynode.ro/gazduire-web/index.md) și [servere VPS](https://kabynode.ro/servere-virtuale/index.md) Romania. --- - Pagina originală (HTML): https://kabynode.ro/blog/google-core-web-vitals-2026-noi-metrici-si-cerinte-ranking/ - Versiune Markdown: https://kabynode.ro/blog/google-core-web-vitals-2026-noi-metrici-si-cerinte-ranking/index.md - Index pentru agenți AI: https://kabynode.ro/llms.txt - Documentație completă: https://kabynode.ro/llms-full.txt - Ultima actualizare: 15.10.2026