Optimizare INP: Ghid Complet 2026

De Ce INP Este Metrica Care Contează Cel Mai Mult în 2026

Hai să fim direcți: dacă administrați un site web în 2026 și nu v-ați familiarizat încă cu INP (Interaction to Next Paint), aveți o problemă serioasă. De când a înlocuit oficial FID (First Input Delay) în martie 2024, INP a devenit practic coloana vertebrală a responsivității în suita Core Web Vitals. Google folosește activ această metrică pentru clasamentul paginilor, iar diferența dintre un INP bun și unul slab se traduce direct în conversii pierdute sau câștigate.

Cifrele vorbesc de la sine. Site-urile care îndeplinesc pragurile Core Web Vitals înregistrează o creștere de 8-15% în vizibilitatea organică. Un exemplu concret: o pagină de e-commerce și-a îmbunătățit INP cu 73% (de la 450ms la 120ms), iar redBus a raportat o creștere de 7% a vânzărilor doar din optimizarea INP.

Și totuși, doar 47% din site-uri îndeplinesc aceste praguri. Gândiți-vă la asta — mai mult de jumătate din web pierde între 8-35% din conversii, clasamente și venituri, pur și simplu pentru că interfețele lor răspund prea lent.

Articolul anterior din clinica noastră de performanță a explorat Speculation Rules API pentru navigare instantanee. Acum completăm imaginea cu cealaltă jumătate a ecuației: ce se întâmplă după ce pagina s-a încărcat și utilizatorul începe să interacționeze cu ea. INP măsoară exact acest lucru — cât de repede răspunde pagina la click-uri, atingeri și apăsări de taste.

Ce Este INP și Cum Funcționează

Interaction to Next Paint (INP) măsoară latența celei mai lente interacțiuni a utilizatorului cu pagina pe durata întregii vizite. Spre deosebire de FID, care măsura doar prima interacțiune, INP monitorizează toate interacțiunile — click-uri pe butoane, scroll-uri, introducerea textului în formulare — și raportează o singură valoare care reprezintă responsivitatea generală.

Practic, e ca și cum FID era nota de la primul examen, iar INP e media pe tot semestrul.

Pragurile de Performanță

Google definește trei niveluri de performanță INP:

Bun (≤ 200ms): Pagina răspunde fluid, utilizatorul nu percepe nicio întârziere
Necesită îmbunătățire (200-500ms): Utilizatorul simte o ușoară ezitare, dar funcționalitatea nu e compromisă
Slab (> 500ms): Interfața pare „blocată" sau lentă — utilizatorii abandonează sau devin frustrați

Obiectivul vostru ar trebui să fie clar: INP sub 200ms pentru cel puțin 75% din vizite.

Cele Trei Componente ale INP

Fiecare interacțiune măsurată de INP are trei faze distincte. Înțelegerea lor e absolut esențială pentru optimizare:

Input Delay (Întârzierea de intrare): Timpul de la momentul interacțiunii până când event handler-ul începe să ruleze. Această întârziere apare când thread-ul principal este ocupat cu alte sarcini — evaluare JavaScript, parsing, și alte treburi de fundal.
Processing Duration (Durata procesării): Timpul necesar pentru executarea tuturor callback-urilor evenimentului. Aici rulează codul vostru — actualizări de stare, calcule, manipulări DOM.
Presentation Delay (Întârzierea prezentării): Timpul de la finalizarea procesării până când browser-ul afișează cadrul vizual actualizat. Include calcularea layout-ului, stilurilor și randarea pixelilor.

Optimizarea eficientă a INP necesită abordarea tuturor celor trei componente. Din experiența mea, mulți dezvoltatori se concentrează doar pe reducerea JavaScript-ului, ignorând complet input delay-ul cauzat de task-uri concurente sau presentation delay-ul cauzat de un DOM supradimensionat.

Diagnosticarea Problemelor de INP: Instrumente și Tehnici

Înainte de a optimiza, trebuie să înțelegeți unde sunt problemele. Abordarea aleatorie — „hai să minimizăm tot JavaScript-ul" — rareori dă rezultate bune. Aveți nevoie de date concrete, nu de intuiție.

Chrome DevTools: Performance Panel

Primul instrument la care ar trebui să apelați este panoul Performance din Chrome DevTools. Iată un flux de lucru care funcționează bine:

Deschideți DevTools (F12) și navigați la tab-ul Performance
Activați „CPU 4x slowdown" pentru a simula un dispozitiv mobil
Începeți înregistrarea și interacționați cu pagina — click-uri, scroll, input
Opriți înregistrarea și analizați flame chart-ul
Căutați blocurile galbene lungi (JavaScript) care se suprapun cu interacțiunile

Acordați atenție specială task-urilor care depășesc 50ms. Acestea sunt considerate „Long Tasks" și pot bloca thread-ul principal exact când utilizatorul încearcă să interacționeze cu pagina.

Long Animation Frames API (LoAF): Diagnosticare în Producție

Chrome DevTools funcționează excelent în dezvoltare, dar — și aici e partea frustrantă — problemele reale de INP apar adesea doar în producție, pe dispozitivele reale ale utilizatorilor. Aici intervine Long Animation Frames API (LoAF), o evoluție semnificativă față de vechiul Long Tasks API.

LoAF oferă informații detaliate despre ce scripturi contribuie la întârzierile de randare, inclusiv în momentul interacțiunilor. Iată cum să colectați date LoAF în producție:

// Observarea Long Animation Frames
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Filtrăm doar frame-urile care conțin interacțiuni
    if (entry.firstUIEventTimestamp > 0) {
      console.log('INP candidate detected:', {
        duration: entry.duration,
        blockingDuration: entry.blockingDuration,
        scripts: entry.scripts.map(s => ({
          name: s.name,
          sourceURL: s.sourceURL,
          duration: s.duration,
          executionStart: s.executionStart
        }))
      });
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Proprietatea scripts este deosebit de valoroasă — vă arată exact ce scripturi rulau în timpul frame-ului lent, permițându-vă să identificați rapid vinovatul, fie că e codul propriu sau un script terț.

Biblioteca web-vitals pentru Date de Teren

Google oferă biblioteca web-vitals care simplifică enorm colectarea metricilor în producție. Versiunea cu atribuire (attribution build) vă oferă context detaliat despre interacțiunea responsabilă de INP:

import { onINP } from 'web-vitals/attribution';

onINP((metric) => {
  const { value, attribution } = metric;
  const {
    interactionTarget,    // Elementul cu care s-a interacționat
    interactionType,      // 'pointer', 'keyboard', etc.
    inputDelay,           // Faza 1: Input Delay
    processingDuration,   // Faza 2: Processing Duration
    presentationDelay,    // Faza 3: Presentation Delay
    longAnimationFrameEntries  // Date LoAF asociate
  } = attribution;

  // Trimiteți datele la sistemul vostru de analytics
  sendToAnalytics({
    metric: 'INP',
    value,
    target: interactionTarget,
    type: interactionType,
    inputDelay,
    processingDuration,
    presentationDelay,
    scripts: longAnimationFrameEntries?.[0]?.scripts?.map(
      s => s.sourceURL
    )
  });
});

Cu această abordare, puteți construi un tablou de bord real cu datele INP ale utilizatorilor reali, segmentat pe tip de dispozitiv, pagină și tip de interacțiune. Sincer, e una dintre cele mai utile investiții de timp pe care le puteți face pentru performanță.

Strategia 1: Fragmentarea Task-urilor Lungi cu scheduler.yield()

Cea mai frecventă cauză a unui INP slab? Blocarea thread-ului principal de către task-uri JavaScript lungi. Când browser-ul execută un bloc mare de JavaScript, nu poate procesa interacțiunile utilizatorului până când acel bloc nu se termină. Rezultat: input delay crescut și o experiență frustrantă.

De la setTimeout la scheduler.yield()

Tehnica tradițională de fragmentare a task-urilor folosea setTimeout(fn, 0) pentru a ceda controlul thread-ului principal. Problema? Continuarea task-ului era plasată la sfârșitul cozii de task-uri, ceea ce însemna că alte scripturi (inclusiv cele terțe) puteau „sări" înaintea codului vostru. Rezultatul era o execuție imprevizibilă și, ironic, uneori mai lentă.

scheduler.yield() rezolvă elegant această problemă. Când cedați controlul cu această metodă, continuarea codului vostru primește prioritate ridicată în coada de task-uri — browser-ul procesează interacțiunile utilizatorului, apoi revine imediat la codul vostru, fără a lăsa alte scripturi să intervină.

// ÎNAINTE: O funcție lungă care blochează thread-ul principal
async function processLargeDataset(items) {
  const results = [];
  for (const item of items) {
    // Procesare intensivă pentru fiecare element
    const result = heavyComputation(item);
    results.push(result);
  }
  updateUI(results);
  return results;
}

// DUPĂ: Aceeași funcție, fragmentată cu scheduler.yield()
async function processLargeDataset(items) {
  const results = [];
  for (let i = 0; i < items.length; i++) {
    const result = heavyComputation(items[i]);
    results.push(result);

    // Cedăm controlul la fiecare 5 elemente
    if (i % 5 === 4) {
      await scheduler.yield();
    }
  }
  updateUI(results);
  return results;
}

Implementare cu Fallback Cross-Browser

Deoarece scheduler.yield() este disponibil doar în browserele bazate pe Chromium (deocamdată), aveți nevoie de un fallback pentru Firefox și Safari:

// Funcție utilitară cu fallback
function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  // Fallback: setTimeout cu durata 0
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Utilizare în cod
async function processFormSubmission(formData) {
  // Pasul 1: Validare
  const validationResult = validateForm(formData);
  await yieldToMain();

  // Pasul 2: Transformare date
  const transformedData = transformPayload(validationResult);
  await yieldToMain();

  // Pasul 3: Trimitere la server
  const response = await submitToAPI(transformedData);
  await yieldToMain();

  // Pasul 4: Actualizare UI
  updateFormState(response);
}

Observați cum fiecare pas logic al procesării este separat de un await yieldToMain(). Acest pattern oferă browser-ului oportunitatea de a procesa interacțiunile utilizatorului între pași, reducând dramatic input delay-ul.

Strategia 2: Reducerea Dimensiunii DOM-ului

Un DOM supradimensionat afectează INP în mod direct — și asta e ceva ce mulți dezvoltatori subestimează. Cu cât sunt mai multe noduri, cu atât browser-ul are nevoie de mai mult timp pentru a recalcula layout-ul și stilurile după fiecare interacțiune. Aceasta crește presentation delay, a treia componentă a INP, care e adesea ignorată.

Câte Noduri Sunt Prea Multe?

Lighthouse recomandă:

Sub 1.400 noduri DOM în total
Adâncime maximă de 32 niveluri
Maxim 60 de copii pentru un singur nod părinte

Dar, în practică, multe aplicații moderne depășesc cu ușurință aceste praguri. O pagină de categorie pe un site e-commerce poate avea 3.000-5.000+ noduri DOM fără prea mult efort. Am văzut chiar și pagini cu peste 10.000 de noduri, unde simpla apăsare a unui buton dura aproape o secundă.

Virtualizarea Listelor

Dacă afișați liste lungi (produse, comentarii, feed-uri), virtualizarea este esențială. Ideea e simplă: în loc să randați toate elementele, randați doar cele vizibile în viewport:

// Exemplu simplificat de virtualizare
class VirtualList {
  constructor(container, items, itemHeight) {
    this.container = container;
    this.items = items;
    this.itemHeight = itemHeight;
    this.visibleCount = Math.ceil(
      container.clientHeight / itemHeight
    ) + 2; // buffer

    this.container.style.position = 'relative';
    this.container.style.overflow = 'auto';
    this.container.style.height = '100%';

    // Spacer pentru scroll total
    this.spacer = document.createElement('div');
    this.spacer.style.height =
      `${items.length * itemHeight}px`;
    this.container.appendChild(this.spacer);

    this.container.addEventListener(
      'scroll',
      this.onScroll.bind(this),
      { passive: true }
    );
    this.render();
  }

  onScroll() {
    requestAnimationFrame(() => this.render());
  }

  render() {
    const scrollTop = this.container.scrollTop;
    const startIndex = Math.floor(
      scrollTop / this.itemHeight
    );
    const endIndex = Math.min(
      startIndex + this.visibleCount,
      this.items.length
    );

    // Eliminăm elementele vechi
    this.spacer.querySelectorAll('.virtual-item')
      .forEach(el => el.remove());

    // Randăm doar elementele vizibile
    for (let i = startIndex; i < endIndex; i++) {
      const el = document.createElement('div');
      el.className = 'virtual-item';
      el.style.position = 'absolute';
      el.style.top = `${i * this.itemHeight}px`;
      el.style.height = `${this.itemHeight}px`;
      el.textContent = this.items[i];
      this.spacer.appendChild(el);
    }
  }
}

Pentru aplicații React, bibliotecile react-window și @tanstack/react-virtual oferă soluții robuste și testate. Aceste biblioteci pot reduce numărul de noduri DOM de la mii la zeci, cu un impact dramatic asupra INP.

Utilizarea content-visibility: auto

CSS-ul modern ne oferă o soluție elegantă pentru secțiunile care nu sunt vizibile inițial — și e surprinzător de simplă de implementat:

/* Secțiunile sub fold nu vor fi randate
   până când nu sunt aproape de viewport */
.section-below-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

/* Exemplu practic pentru un feed de articole */
.article-card {
  content-visibility: auto;
  contain-intrinsic-size: auto 320px;
}

/* Footer-ul și secțiunile auxiliare */
footer,
.related-articles,
.comments-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 400px;
}

Proprietatea content-visibility: auto instruiește browser-ul să omită randarea elementelor care nu sunt în viewport. Când utilizatorul scrollează spre ele, browser-ul le randează on-demand. Iar contain-intrinsic-size previne jump-urile de layout oferind o dimensiune estimată înainte de randare.

Strategia 3: Optimizarea Event Handler-elor

Event handler-ele ineficiente sunt o cauză directă a unui processing duration ridicat. Să vedem cele mai frecvente probleme și cum le rezolvăm.

Debouncing și Throttling Inteligent

Nu toate interacțiunile necesită procesare imediată. Evenimentele de input, scroll și resize pot fi declanșate de sute de ori pe secundă, și dacă fiecare declanșează o operație costisitoare... ei bine, aveți o problemă:

// PROBLEMĂ: Handler de input care rulează la fiecare tastă
searchInput.addEventListener('input', (e) => {
  // Aceasta rulează la FIECARE caracter tastat
  const results = searchDatabase(e.target.value); // 50-200ms
  renderResults(results);                          // 30-100ms
});

// SOLUȚIE: Debounce cu feedback vizual imediat
searchInput.addEventListener('input', (e) => {
  // Feedback vizual imediat (sub 5ms)
  showSearchingIndicator();

  // Procesarea reală e amânată
  clearTimeout(searchTimeout);
  searchTimeout = setTimeout(async () => {
    const results = await searchDatabase(e.target.value);
    await scheduler.yield?.();
    renderResults(results);
    hideSearchingIndicator();
  }, 300);
});

Observați pattern-ul: oferim feedback vizual imediat (indicatorul de căutare) pentru a comunica utilizatorului că interacțiunea a fost recepționată, apoi amânăm procesarea costisitoare. Aceasta reduce dramatic INP deoarece browser-ul poate afișa cadrul cu feedback-ul vizual rapid, chiar dacă procesarea completă durează mai mult.

E un truc simplu, dar face o diferență enormă în percepția utilizatorului.

Event Delegation în Loc de Listeners Multipli

Dacă aveți zeci sau sute de elemente interactive, atașarea unui event listener la fiecare e ineficientă (și destul de inelegantă, sincer):

// PROBLEMĂ: 100 de listeners individuali
document.querySelectorAll('.product-card').forEach(card => {
  card.addEventListener('click', handleProductClick);
});

// SOLUȚIE: Un singur listener delegat
document.querySelector('.products-grid')
  .addEventListener('click', (e) => {
    const card = e.target.closest('.product-card');
    if (card) {
      handleProductClick(card);
    }
  });

Event delegation reduce memoria utilizată și simplifică managementul listeners-ilor, mai ales în aplicațiile cu conținut dinamic.

Listeners Pasivi pentru Scroll

Dacă aveți listeners pe evenimente de scroll sau touch, marcați-le ca pasive atunci când nu apelați preventDefault():

// PROBLEMĂ: Browser-ul așteaptă să vadă dacă preventDefault() e apelat
window.addEventListener('scroll', onScroll);

// SOLUȚIE: Browser-ul știe că nu va fi blocat
window.addEventListener('scroll', onScroll, { passive: true });

// Același lucru pentru touch events
element.addEventListener('touchmove', onTouchMove, {
  passive: true
});

Listeners pasivi permit browser-ului să proceseze scroll-ul și interacțiunile tactile fără a aștepta răspunsul JavaScript-ului. E o schimbare mică, dar elimină o sursă frecventă de jank.

Strategia 4: Controlul Scripturilor Terțe

Scripturile terțe — analytics, reclame, chatbot-uri, tracking — sunt adesea cel mai mare dușman al INP. Serios, un singur script de analytics prost optimizat poate bloca thread-ul principal mai mult decât toate imaginile de pe pagină combinate.

Auditarea Impactului

Primul pas e măsurarea. Folosiți LoAF pentru a identifica ce scripturi terțe contribuie la INP:

// Identificarea scripturilor terțe problematice
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 100) {
      const thirdPartyScripts = entry.scripts.filter(
        s => !s.sourceURL.includes(location.hostname)
      );
      if (thirdPartyScripts.length > 0) {
        console.warn(
          'Third-party scripts in slow frame:',
          thirdPartyScripts.map(s => ({
            url: s.sourceURL,
            duration: Math.round(s.duration) + 'ms'
          }))
        );
      }
    }
  }
});

observer.observe({
  type: 'long-animation-frame',
  buffered: true
});

Strategii de Încărcare Amânată

Odată identificate scripturile problematice, aplicați strategii de încărcare inteligentă:

<!-- PROBLEMĂ: Scripturile se încarcă și execută imediat -->
<script src="https://analytics.example.com/track.js">
</script>
<script src="https://chat.example.com/widget.js">
</script>

<!-- SOLUȚIE 1: Defer - se execută după parsing-ul HTML -->
<script defer
  src="https://analytics.example.com/track.js">
</script>

<!-- SOLUȚIE 2: Încărcare la idle sau după interacțiune -->
<script>
  // Chat widget-ul se încarcă doar la prima interacțiune
  function loadChatWidget() {
    if (document.querySelector('#chat-script')) return;
    const script = document.createElement('script');
    script.id = 'chat-script';
    script.src = 'https://chat.example.com/widget.js';
    document.body.appendChild(script);
  }

  // Încărcare la prima interacțiune cu pagina
  ['click', 'scroll', 'keydown', 'touchstart'].forEach(
    event => {
      window.addEventListener(event, loadChatWidget, {
        once: true,
        passive: true
      });
    }
  );

  // Sau la idle, dacă utilizatorul nu interacționează
  if ('requestIdleCallback' in window) {
    requestIdleCallback(loadChatWidget, {
      timeout: 5000
    });
  }
</script>

Partiționarea prin Web Workers

Pentru scripturile terțe care execută calcule intensive (analytics complex, A/B testing cu evaluare pe client), mutarea într-un Web Worker izolează complet impactul asupra thread-ului principal:

// analytics-worker.js — rulează într-un thread separat
self.addEventListener('message', (event) => {
  const { type, data } = event.data;

  if (type === 'track-event') {
    // Procesare complexă care NU blochează UI-ul
    const enrichedData = enrichWithSessionData(data);
    const payload = compressPayload(enrichedData);

    // Trimitere directă din worker
    fetch('/api/analytics', {
      method: 'POST',
      body: payload,
      keepalive: true
    });
  }
});

// main.js — codul din pagină
const analyticsWorker = new Worker(
  '/analytics-worker.js'
);

// Tracking fără impact asupra INP
function trackEvent(eventName, eventData) {
  analyticsWorker.postMessage({
    type: 'track-event',
    data: { name: eventName, ...eventData }
  });
}

Avantajul principal: chiar dacă procesarea analytics-ului durează 100ms+, aceasta rulează într-un thread complet separat și nu afectează deloc responsivitatea paginii. Zero impact pe INP.

Strategia 5: Optimizări Specifice pentru Framework-uri

Framework-urile moderne — React, Vue, Angular — vin cu propriile provocări pentru INP. Re-randarea componentelor, reconcilierea DOM-ului virtual și managementul stării pot cauza processing duration și presentation delay semnificative. Vestea bună e că aceste framework-uri oferă și soluții native.

React: Memoizare și startTransition

React oferă instrumente native pentru a preveni re-randările inutile și a prioritiza interacțiunile utilizatorului:

import {
  memo, useMemo, useCallback,
  useTransition, startTransition
} from 'react';

// 1. Memoizare componente — previne re-randarea inutilă
const ProductCard = memo(function ProductCard({
  product, onAddToCart
}) {
  return (
    <div className="product-card">
      <h3>{product.name}</h3>
      <p>{product.price} lei</p>
      <button onClick={() => onAddToCart(product.id)}>
        Adaugă în coș
      </button>
    </div>
  );
});

// 2. useTransition — marchează actualizările non-urgente
function SearchableProductList({ products }) {
  const [query, setQuery] = useState('');
  const [filteredProducts, setFilteredProducts] =
    useState(products);
  const [isPending, startTransition] = useTransition();

  function handleSearch(e) {
    // Actualizare urgentă: input-ul se actualizează imediat
    setQuery(e.target.value);

    // Actualizare non-urgentă: filtrarea se face
    // fără a bloca input-ul
    startTransition(() => {
      const filtered = products.filter(p =>
        p.name.toLowerCase()
          .includes(e.target.value.toLowerCase())
      );
      setFilteredProducts(filtered);
    });
  }

  return (
    <div>
      <input
        value={query}
        onChange={handleSearch}
        placeholder="Caută produse..."
      />
      {isPending && <div className="spinner" />}
      <div className="products-grid">
        {filteredProducts.map(p =>
          <ProductCard key={p.id} product={p} />
        )}
      </div>
    </div>
  );
}

startTransition spune React-ului că actualizarea listei nu este urgentă — dacă utilizatorul continuă să tasteze, React va abandona randarea în curs pentru a procesa noua interacțiune. Aceasta reduce dramatic INP în scenariile de căutare și filtrare, care sunt exact locurile unde utilizatorii se așteaptă la răspuns instantaneu.

Vue: computed și watch cu Debounce

<script setup>
import { ref, computed, watch } from 'vue';

const searchQuery = ref('');
const allProducts = ref([]);
const debouncedQuery = ref('');

// Debounce pe query
let timeout;
watch(searchQuery, (newVal) => {
  clearTimeout(timeout);
  timeout = setTimeout(() => {
    debouncedQuery.value = newVal;
  }, 250);
});

// Computed se recalculează doar când debouncedQuery
// se schimbă
const filteredProducts = computed(() => {
  if (!debouncedQuery.value) return allProducts.value;
  return allProducts.value.filter(p =>
    p.name.toLowerCase()
      .includes(debouncedQuery.value.toLowerCase())
  );
});
</script>

<template>
  <input v-model="searchQuery"
    placeholder="Caută produse..." />
  <div class="products-grid">
    <ProductCard
      v-for="product in filteredProducts"
      :key="product.id"
      :product="product"
    />
  </div>
</template>

Strategia 6: Optimizarea Specifică pentru Dispozitive Mobile

Peste 60% din traficul web global vine de pe dispozitive mobile, iar acestea sunt de obicei de 3-5 ori mai lente decât un laptop de dezvoltare. Un INP de 100ms pe laptop-ul vostru poate deveni ușor 400-500ms pe un telefon de buget. E o diferență uriașă.

Adaptive Loading

Adaptați complexitatea interfeței la capacitățile reale ale dispozitivului:

// Detectare capacitate dispozitiv
function getDeviceCapability() {
  const cores = navigator.hardwareConcurrency || 2;
  const memory = navigator.deviceMemory || 2; // GB
  const connection =
    navigator.connection?.effectiveType || '4g';

  if (cores <= 2 || memory <= 2 ||
      connection === 'slow-2g' ||
      connection === '2g') {
    return 'low';
  }
  if (cores <= 4 || memory <= 4 ||
      connection === '3g') {
    return 'medium';
  }
  return 'high';
}

// Adaptare funcționalitate
const capability = getDeviceCapability();

if (capability === 'low') {
  // Dezactivare animații complexe
  document.documentElement.classList.add(
    'reduce-motion'
  );
  // Reducerea elementelor din liste
  ITEMS_PER_PAGE = 10;
  // Skip non-essential features
  ENABLE_CHAT_WIDGET = false;
} else if (capability === 'medium') {
  ITEMS_PER_PAGE = 20;
  ENABLE_CHAT_WIDGET = true;
  CHAT_LOAD_DELAY = 5000;
}

Touch Target-uri Adecvate

Un aspect adesea neglijat (dar super important): butoanele prea mici pe mobil duc la interacțiuni repetate — tap-uri greșite urmate de zoom și re-tap — fiecare generând o măsurătoare INP. Asigurați-vă că toate elementele interactive au minimum 48x48 pixeli:

/* Asigurarea target-urilor tactile adecvate */
button, a, [role="button"],
input, select, textarea {
  min-height: 48px;
  min-width: 48px;
}

/* Spațiere între elemente interactive */
.button-group button + button {
  margin-left: 8px;
}

/* Zone de tap extinse fără a modifica vizual */
.nav-link {
  position: relative;
  padding: 12px 16px;
}

.nav-link::after {
  content: '';
  position: absolute;
  inset: -8px;
}

Monitorizare Continuă și Alerte

Optimizarea INP nu este un proiect pe care îl bifați și gata — este un proces continuu. Noile funcționalități, actualizările de dependințe și scripturile terțe noi pot degrada performanța în orice moment.

Integrarea cu CI/CD

Adăugați verificări de performanță în pipeline-ul vostru de CI/CD folosind Lighthouse CI:

# .github/workflows/performance.yml
name: Performance Audit
on: [pull_request]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          urls: |
            https://staging.example.com/
            https://staging.example.com/products
          budgetPath: ./performance-budget.json
          uploadArtifacts: true

# performance-budget.json
{
  "timings": [
    {
      "metric": "interactive",
      "budget": 3000
    },
    {
      "metric": "total-blocking-time",
      "budget": 200
    }
  ],
  "resourceSizes": [
    {
      "resourceType": "script",
      "budget": 300
    },
    {
      "resourceType": "total",
      "budget": 800
    }
  ]
}

Dashboard RUM (Real User Monitoring)

Pentru monitorizarea în producție, configurați alerte pe praguri INP:

// Sistem simplu de alertare INP
import { onINP } from 'web-vitals';

onINP((metric) => {
  // Trimiteți toate valorile la analytics
  sendToAnalytics('inp', metric.value);

  // Alertare pentru valori critice
  if (metric.value > 500) {
    sendAlert({
      severity: 'critical',
      metric: 'INP',
      value: metric.value,
      page: location.pathname,
      userAgent: navigator.userAgent
    });
  }
});

Plan de Acțiune: De la Diagnostic la Rezultate

Deci, să sintetizăm totul într-un plan de acțiune concret. Iată cum puteți implementa progresiv aceste optimizări:

Săptămâna 1 — Măsurare: Implementați colectarea datelor INP cu web-vitals și LoAF. Identificați paginile și interacțiunile cu cel mai slab INP. Stabiliți o linie de bază — fără ea, nu veți ști dacă eforturile voastre dau roade.
Săptămâna 2 — Quick Wins: Adăugați content-visibility: auto pe secțiunile sub fold. Convertiți scroll/touch listeners la pasive. Aplicați event delegation unde e posibil. Amânați încărcarea scripturilor terțe non-critice.
Săptămâna 3 — Optimizare JavaScript: Implementați scheduler.yield() în funcțiile lungi. Folosiți startTransition (React) sau debounce (vanilla/Vue) pentru actualizările non-urgente. Mutați procesarea intensivă în Web Workers.
Săptămâna 4 — Reducere DOM: Implementați virtualizare pentru liste lungi. Auditați și eliminați elementele DOM inutile. Optimizați structura HTML pentru a reduce adâncimea și complexitatea.
Continuu — Monitorizare: Configurați alerte pe praguri INP. Adăugați verificări de performanță în CI/CD. Auditați periodic scripturile terțe și impactul lor.

Concluzie: INP Nu Este Opțional

În peisajul web al anului 2026, INP nu mai este o metrică „nice to have" — este un factor direct de clasament în Google și un indicator critic al experienței utilizatorilor. Studiile de caz pe care le-am discutat demonstrează că optimizările pot fi dramatice: reduceri de 73-90% ale INP, creșteri de 7% ale vânzărilor, și îmbunătățiri de 8-15% în vizibilitatea organică.

Cheia nu constă într-o singură tehnică magică, ci într-o abordare sistematică: măsurați cu instrumente adecvate (LoAF, web-vitals), diagnosticați cele trei componente ale INP separat, optimizați progresiv, și monitorizați continuu pentru a preveni regresiile.

Combinat cu tehnicile de navigare instantanee din articolul nostru anterior despre Speculation Rules API, aveți acum o imagine completă a performanței web moderne: pagini care se încarcă instantaneu și răspund fluid la fiecare interacțiune. Asta înseamnă o experiență web de top în 2026 — și, sincer, asta ar trebui să fie standardul, nu excepția.