Weboldalak INP (Interaction to Next Paint) pontszámának javítása – Teljes útmutató

Hogyan javítható a weboldalak INP pontszáma? A rövid válasz: csökkentenie kell a fő szál azon terheléseit, amelyek késleltetik a felhasználó kattintása, érintése vagy billentyűzetes interakciója után megjelenő következő vizuális frissítést. Ehhez fel kell darabolni a hosszú JavaScript feladatokat, el kell távolítani a felesleges szkripteket, könnyíteni kell az eseményfigyelőkön, optimalizálni kell a renderelést blokkoló erőforrásokat, ellenőrizni kell a külső kódokat, és valós felhasználói adatok alapján kell méréseket végezni. A jó INP pontszám 200 ms vagy az alatti; a 200-500 ms közötti érték javítást igényel, az 500 ms feletti pedig gyenge felhasználói élményt jelez.

Az INP, azaz az Interaction to Next Paint, a 2026-os SEO és felhasználói élmény törekvések egyik kritikus Core Web Vitals mutatója. A Google számára ma már nem csupán az oldal gyors betöltődése számít, hanem az is, hogy a felhasználó milyen gördülékenyen tud interakcióba lépni a webhellyel az oldal megnyitása után. Amikor egy termékszűrőre kattintva lassan jelenik meg a menü, a kosárba gomb beragad, a mobilmenü késve reagál, vagy egy űrlapmező akadozik gépelés közben – ezek mind az INP problémák tipikus jelei.

Ebből az útmutatóból megtanulhatja az INP érték mérését, a rossz pontszámot okozó technikai szűk keresztmetszetek feltárását, valamint azokat a konkrét optimalizálási lépéseket, amelyeket fejlesztőként, weboldal-tulajdonosként vagy WordPress üzemeltetőként alkalmazhat. Emellett gyakorlati példákkal vizsgáljuk meg a tárhelyinfrastruktúra, a CDN-használat és a biztonságos kapcsolat teljesítményre gyakorolt közvetett hatásait is. Ha teljesítményorientált alapinfrastruktúrát keres, érdemes megfontolnia a Web hosting csomagok és WordPress-alapú projektek esetén a WordPress hosting lehetőségeket.

Mi az INP és miért fontos?

Az INP egy oldalon végrehajtott felhasználói interakciók általános válaszidejét méri. A felhasználó rákattint egy gombra, lapfület vált, menüt nyit meg, űrlapmezőbe ír, vagy mobilon megérint egy elemet. A böngésző feldolgozza ezt az interakciót, JavaScriptet futtat, stílus- és elrendezés-számításokat végez, majd egy új vizuális állapotot hoz létre a képernyőn. Az INP szempontjából az interakció és a vizuális frissítés között eltelt időt értékeljük.

A korábbi években a First Input Delay, azaz a FID volt a fontos mutató; a FID azonban kizárólag az első interakció késlekedésére összpontosított. Az INP ezzel szemben az oldal teljes életciklusa során bekövetkező interakciókat átfogóbban értékeli. Éppen ezért egy webáruház, blog, SaaS panel, céges weboldal vagy tagsági rendszer valós felhasználói élményét jobban reprezentálja.

A Google által javasolt küszöbértékek a következők:

Az INP nem csupán a SEO, hanem a konverziós arány szempontjából is kulcsfontosságú. Például ha egy mobil kategóriaoldalon a szűrőgomb 700 ms késéssel nyílik meg, a felhasználó azt hiheti, hogy a művelet nem működik, és újra rányomhat, vagy elhagyhatja az oldalt. Ezzel szemben a 150-180 ms alatt reagáló felületek megbízhatóbbnak, gyorsabbnak és professzionálisabbnak tűnnek.

Hogyan mérjük az INP pontszámot?

Mielőtt belevágnánk az INP optimalizálásába, pontos méréseket kell végezni. Ennek oka, hogy a laboratóriumi eszközök becsült problémákat mutatnak, míg a valós felhasználói adatok a terepen lévő eszközök, kapcsolatok és böngészők körülményeit tükrözik. A legegészségesebb megközelítés a két adattípus együttes használata.

1. Végezzen gyors ellenőrzést a PageSpeed Insights segítségével

A PageSpeed Insights megmutatja a valós felhasználói INP értéket, ha rendelkezésre áll Chrome User Experience Report adat. A mobil és asztali eredményeket külön vizsgálja meg. Különösen a mobiladatokat részesítse előnyben, mivel az alacsonyabb teljesítményű telefonokon a fő szál könnyebben telítődik. Ha az oldal INP értéke 200 ms felett van, jegyezze fel a lenti lehetőségek és diagnosztika szakaszok tartalmát.

2. Kövesse nyomon a Search Console Core Web Vitals jelentését

A Google Search Console Core Web Vitals jelentése URL-csoportok szerint listázza a problémákat. Itt egyetlen oldal helyett láthatja, hogy a hasonló sablonok problémásak-e. Ha például az összes termékrészlet-oldal rossz INP-t kap, a probléma nagy valószínűséggel a témában, a kosár szkriptben, egy hozzászólás-bővítményben vagy a termékváltozatok kódjában keresendő.

3. Használja a Chrome DevTools Teljesítmény panelt

A Chrome DevTools Teljesítmény panelje megmutatja, hogy egy kattintás pillanatában mely JavaScript függvények futnak, és mely feladatok képeznek 50 ms-nál hosszabb "long task"-et. Rögzítsen egy menü-kattintást, és vizsgálja meg a fő szálon a lila, sárga és zöld blokkokat. A hosszú szkriptfutások, az ismétlődő stílus-újraszámítások és az intenzív elrendezési feladatok kritikus jelzések az INP szempontjából.

4. Állítson be valós felhasználói monitorozást

Nagy forgalmú projekteknél a RUM, azaz a Real User Monitoring használata rendkívül értékes. A Web Vitals könyvtárral gyűjtheti az INP adatokat, és elemezheti azokat URL, eszköztípus, böngésző, ország és interakciós cél szerint. Az adatok például megmutathatják, hogy kizárólag az Android felhasználóknál 620 ms a mobilmenü megnyitása. Ez az információ lehetővé teszi, hogy általános optimalizálás helyett célzott javítást végezzen.

A rossz INP pontszám leggyakoribb okai

Az INP problémák nagy része nem a szerver válaszidejéből, hanem abból fakad, hogy a böngésző túl sok munkát végez a felhasználói interakció pillanatában. Ennek ellenére az infrastruktúra, a fájlkiszolgálás, a gyorsítótár és a külső függőségek közvetve növelhetik ezt a terhelést.

Nehéz JavaScript fájlok

A modern weboldalakon a téma, a csúszkák, az élő chat, a hirdetések, az analitika, az A/B tesztelés, a térképek és a közösségi média komponensek rengeteg JavaScript fájlt töltenek be. A fájlok nem csupán letöltődnek; a böngésző elemzi, lefordítja és futtatja őket. Ha ez a folyamat lefoglalja a fő szálat, a felhasználó kattintására késve érkezik válasz.

Hosszú feladatok (Long Tasks)

Az 50 ms-nál tovább tartó fő szálbeli munkák "long task"-nek minősülnek. Egyetlen 300 ms-ig futó feladat is várakoztathatja a felhasználó kattintását. Például ha egy szűrőgombra kattintva egy szkript kliensoldalon újraszámolja mind az 1000 terméket, az INP érték könnyedén 500 ms fölé ugorhat.

Bonyolult DOM és költséges elrendezési műveletek

A túl sok HTML csomópont, az egymásba ágyazott komponensek, a gyakori stílusváltások és az úgynevezett "layout thrashing" (ismételt méret-olvasási és írási hiba) tönkreteszik az INP-t. Különösen a mega menük, a terméklistázó oldalak és a hosszú egyoldalas alkalmazások hordozzák ezt a kockázatot.

Külső szkriptek

A hirdetési hálózatok, követőpixelek, hőtérkép eszközök, élő chat kódok és közösségi média beágyazások a webhely ellenőrzésén kívül eső kódokat futtatnak. Ha ezek a kódok az interakció pillanatában használják a fő szálat, akkor még az Ön által tisztán megírt felület is lassan reagálhat.

WordPress bővítmény- és téma-túlterheltség

A WordPress oldalakon minden bővítmény hozzáadhatja a saját CSS és JS fájljait. Ha egy kapcsolatfelvételi űrlap bővítmény szkriptje csak a kapcsolat oldalon lenne szükséges, mégis az egész webhelyen betöltődik, az felesleges terhelést okoz. Hasonlóképpen a vizuális szerkesztők, csúszkák és pop-up bővítmények negatívan befolyásolhatják a mobil INP pontszámot.

Hogyan javítható az INP pontszám? Lépésről lépésre megvalósítási terv

A "hogyan javítható az INP pontszám" kérdés gyakorlati válasza a mérj, izolálj, csökkents, darabolj fel és mérj újra megközelítés. Az alábbi lépések a technikai csapatok által valós projektekben alkalmazott prioritási sorrendben készültek.

1. Találja meg a legproblémásabb interakciót

Először határozza meg, melyik interakció produkál rossz INP-t. A mobilmenü, a kosárba gomb, a szűrőpanel, a keresőmező vagy az űrlapküldés? A DevTools Teljesítmény felvétel készítése közben ismételje meg az adott műveletet többször. A felvételen belül az Event Timing vagy Interaction szekcióban vizsgálja meg a kattintás célpontját és időtartamát.

Konkrét példa: Egy webáruházban a kategória szűrőgomb 740 ms INP-t produkált. A vizsgálat során kiderült, hogy a gomb megnyomásakor az összes termékkártya újrarenderelődött, és 1800 DOM csomópont frissült egyszerre. Miután a szűrőpanelt külön komponensbe szervezték, és a lista frissítését elhalasztották, az INP 190 ms szintre csökkent.

2. Csökkentse a JavaScript csomag méretét

A használaton kívüli kódok eltávolítása az egyik leghatékonyabb lépés az INP javítására. Használjon csomagelemzőt (bundle analyzer), hogy lássa, mely könyvtárak növelik a fájlméretet. Ahelyett, hogy egy teljes könyvtárat importálna, csak a szükséges modult húzza be. Például egy nagy dátumkezelő könyvtár helyett használhat könnyebb alternatívát vagy a natív Intl API-t.

• Kapcsolja ki a nem használt témafunkciókat.
• Ne töltse be azokat a csúszka, galéria és animációs szkripteket, amelyekre az adott oldalon nincs szükség.
• Használjon modern build eszközöket, amelyek támogatják a "tree shaking"-et.
• Ne küldje le a látogatói oldalra az admin panel kódjait.
• A régi polyfill fájlokat csak azoknak a böngészőknek szolgálja ki, amelyeknek valóban szükségük van rá.

3. Darabolja fel a hosszú feladatokat kisebb részekre

Ahhoz, hogy a böngésző válaszolni tudjon a felhasználói interakciókra, a fő szálnak rendszeres időközönként fel kell szabadulnia. A nagy számításokat ahelyett, hogy egy menetben végezné el, bontsa részekre. A setTimeout, scheduler.postTask, requestIdleCallback vagy a keretrendszerek időzítési funkciói használhatók erre a célra. A cél az, hogy egyetlen 300 ms-os feladat helyett 20-40 ms-os kisebb feladatokat hozzon létre.

Ha például egy 5000 soros táblázatot kell szűrni és újrarajzolni, először frissítse a felhasználó által látható első 50 sort, a többit pedig virtualizációval vagy háttérfeladatokkal dolgozza fel. Így a felhasználó gyorsan látja a kattintás eredményét, és a fennmaradó feldolgozás nem blokkolja az élményt.

4. Egyszerűsítse az eseményfigyelőket

Ha minden click, input, scroll és keydown eseményre nehéz függvények futnak, az tönkreteszi az INP-t. Különösen hibás megoldás, ha egy input mezőben minden egyes billentyűleütésre API kérést küld, vagy a teljes listát újraszámolja. Használjon "debounce" és "throttle" technikákat a műveletek gyakoriságának csökkentésére.

• A keresőmezőnél alkalmazzon 300 ms-os késleltetést.
• Scroll eseményeknél részesítse előnyben a passzív figyelőket.
• A több száz elemhez egyenként hozzáadott figyelők helyett használjon esemény-delegációt.
• Kattintás után először adjon vizuális visszajelzést, a nehéz munkát csak ezután indítsa el.

5. Adjon azonnali vizuális visszajelzést a felhasználónak

Mivel az INP a következő vizuális frissítéshez kapcsolódik, fontos, hogy a felhasználói interakció után azonnal, akár egy apró vizuális változást is létrehozzon. A gomb aktív állapotba váltása, egy betöltésjelző, egy skeleton képernyő vagy a panel megnyitásának első képkockája azt az érzetet kelti a felhasználóban, hogy a rendszer működik. Ahelyett, hogy megvárná a nehéz API választ, és egy csapásra megváltoztatná a teljes felületet, tervezzen gyors visszajelzést és fokozatos frissítést.

6. Csökkentse a renderelési és elrendezési költségeket

A JavaScript mellett a CSS és az elrendezés is hatással van az INP-re. Ha egy kattintás után sok elem méretét, pozícióját és stílusát változtatja meg, az költséges. A CSS animációknál a width, height, top és left helyett a transform és opacity használata általában jobb teljesítményt nyújt. Nagy listák esetén használjon virtualizációt; ne tartson a DOM-ban több száz olyan kártyát, amely nincs a képernyőn.

Kerülje a "layout thrashing" hibát. Tehát egy cikluson belül ne olvassa ki először egy elem szélességét, majd írjon stílust, majd olvasson újra. Csoportosítsa az olvasási és írási műveleteket. Ez az egyszerű átszervezés is tíz milliszekundumokat takaríthat meg bonyolult oldalakon.

7. Ellenőrizze a külső kódokat

Minden külső szkript esetében tegye fel a kérdést: Ez a kód közvetlenül hozzájárul a konverzióhoz? Ha alacsony a hozzájárulása, távolítsa el, késleltesse, vagy csak a szükséges oldalakon töltse be. Az élő chat kódját érdemes lehet a fizetési oldalon tartani, de nem biztos, hogy minden blogbejegyzésnél már az első betöltéskor futnia kell. A hirdetési és analitikai szkripteket lehetőség szerint defer vagy async attribútummal töltse be, hogy ne akadályozzák a kritikus interakciókat.

8. Helyezze át a nehéz számításokat Web Workerbe

Ha a termékszűrés, a nagy JSON feldolgozás, a titkosítás, az adatkonvertálás vagy a bonyolult számítások lefoglalják a fő szálat, használjon Web Workert. A Worker ezeket a feladatokat a háttérben végzi, miközben a fő szál továbbra is válaszol a felhasználói interakciókra. Nem kell minden feladatot Workerbe áthelyezni, de a 100 ms feletti CPU-időt fogyasztó műveleteknél komoly előnyt jelenthet.

9. Optimalizálja a keretrendszer és a hydration költségét

React, Vue, Angular, Next.js vagy Nuxt használata esetén az első betöltés utáni "hydration" költsége befolyásolhatja az INP-t. Ahelyett, hogy az egész oldalt interaktívvá tenné, fontolja meg a sziget architektúra, a részleges hydration vagy a szerver komponensek alkalmazását. Azokat a tartalmakat, amelyek nem igényelnek interakciót, hagyja statikusan. A modális ablakokat, a hozzászólás mezőt vagy az ajánló komponenseket akkor töltse be, amikor a felhasználónak szüksége van rájuk, ez jobb eredményt hoz.

10. WordPress oldalakon csökkentse a bővítmények terhelését

Ha WordPress-t használ, az INP optimalizáláshoz készítsen bővítményleltárt. Távolítsa el az ugyanazt a feladatot ellátó több bővítményt. Ellenőrizze, hogy az űrlap, galéria, csúszka és pop-up bővítmények minden oldalon töltenek-e be fájlokat. Használjon "asset unload" funkcióval rendelkező teljesítménybővítményeket, amelyekkel oldalanként kikapcsolhatja a felesleges CSS és JS fájlokat.

Gyakorlati példa: Egy céges WordPress webhely kezdőoldalának mobil INP értéke 560 ms volt. A csúszka bővítményt eltávolították, a hero szekciót könnyű HTML/CSS-sel építették újjá, a pop-up szkriptet 5 másodperccel késleltették, és a kapcsolatfelvételi űrlap JS fájlja csak a kapcsolat oldalon töltődött be. Ennek eredményeként a mobil INP 210 ms-ra, majd további apró módosításokkal 175 ms-ra csökkent.

Hogyan befolyásolja a tárhely és az infrastruktúra az INP pontszámot?

Az INP alapvetően egy kliensoldali válaszidő-metrika, vagyis a böngészőben lévő fő szál terhelése a meghatározó. A tárhelyinfrastruktúra azonban nem teljesen közömbös. A gyors szerverválasz, a megfelelő gyorsítótárazás, a modern PHP verzió, a HTTP/2 vagy HTTP/3 támogatás, a CDN és a tömörítés biztosítja a fájlok gyorsabb és rendezettebb kézbesítését. Ez különösen az első betöltés során segíti a fő szál kontrolláltabb működését.

Gyenge minőségű infrastruktúrán a magas TTFB, a késve érkező erőforrások, a rendszertelen gyorsítótár-viselkedés és a nagy szerverterhelés rontja a felhasználói élményt. Ha egy gyorsítótár nélküli WordPress webhely minden kérésnél nehéz PHP és adatbázis-műveleteket végez, az oldal később válik interakcióra készen. Ezért az INP munkálatokat nem szabad teljesen elválasztani az LCP és TTFB optimalizálásoktól.

• Használjon szerveroldali gyorsítótárazást.
• Válassza a PHP 8.x és a friss adatbázis verziókat.
• A statikus fájlokat CDN-en keresztül szolgálja ki.
• Engedélyezze a Brotli vagy Gzip tömörítést.
• Tartsa naprakészen az SSL/TLS konfigurációt; a biztonságos kapcsolathoz tekintse meg a SSL tanúsítvány oldalt.
• Ha új projektet vagy márkawebhelyet indít, a megfelelő domain név kiválasztásához használja a Domain ellenőrzés eszközt.

Prioritási táblázat az INP optimalizáláshoz

Az alábbi táblázat összefoglalja, hogy egy tipikus webhelyen melyik javítást mikor érdemes elvégezni. Az eredmények projektenként eltérhetnek, ezért a változtatások után mérjen újra a PageSpeed Insights, a Search Console és a valós felhasználói adatok segítségével.

Technikai ellenőrző lista fejlesztőknek

Az INP javítását a csapaton belül követhető ellenőrző listává kell alakítani. Ellenkező esetben az egyszeri sebességoptimalizálási munkálatok néhány hónap múlva az új bővítmények, kampánykódok és dizájnváltoztatások miatt tönkremehetnek.

• Minden kritikus sablon esetében a mobil INP célt 200 ms alatt kell meghatározni.
• A pull request folyamatok során ellenőrizni kell a csomagméret növekedését.
• Új külső szkript hozzáadása előtt tesztelni kell a teljesítményre gyakorolt hatást.
• A DevTools Teljesítmény felvétellel legalább a mobilmenü, keresés, űrlap és vásárlási interakciókat mérni kell.
• A hosszú feladatokat 50 ms alá kell csökkenteni; ha ez nem lehetséges, fel kell darabolni őket.
• Animációknál a transform és opacity használatát kell előnyben részesíteni.
• Nagy listák esetén lapozást, végtelen görgetést vagy virtualizációt kell használni.
• A RUM adatokat havonta jelenteni kell, és követni kell a Search Console figyelmeztetéseit.

Gyakori INP optimalizálási hibák

Kizárólag gyorsítótár bővítmény telepítése

A gyorsítótár fontos, de nem ez az egyetlen megoldás a rossz INP-re. A gyorsítótár segíthet az oldal gyorsabb kiszolgálásában, de nem javítja ki automatikusan a felhasználó kattintásakor futó nehéz JavaScript kódot. Ezért a gyorsítótárat a kódoptimalizálással együtt kell alkalmazni.

A laboratóriumi pontszám nézése és a valós felhasználó elfelejtése

A Lighthouse tesztek hasznosak, de önmagukban nem elegendőek. A valós felhasználók különböző eszközökkel, hálózatokkal és böngészőkkel érkeznek. Különösen az alacsony kategóriás Android eszközök fedhetnek fel olyan INP problémákat, amelyek az asztali tesztekben nem látszanak.

Az összes szkript véletlenszerű késleltetése

A defer és delay technikákat óvatosan kell alkalmazni. A helytelen konfiguráció tönkreteheti a menüt, a kosarat, az űrlapot vagy a fizetési folyamatot. A kritikus interakciós szkripteket védeni kell, a felesleges és külső kódokat pedig ellenőrzött módon késleltetni.

A vizuális teljesítményre összpontosítás és az interakció elhanyagolása

A képek tömörítése nagyon értékes az LCP szempontjából, de nem mindig oldja meg az INP problémát. Ha a probléma a kattintás után futó kódban van, a képoptimalizálás önmagában nem lesz elég. A Core Web Vitals mutatókat holisztikusan kell kezelni.

INP-központú SEO stratégia 2026-ra

A 2026-os SEO megközelítésben a technikai teljesítmény, a tartalom minősége és a megbízható infrastruktúra együttesen kerül értékelésre. A Google AI Overviews és fejlett keresési élményei hajlamosak előtérbe helyezni azokat az oldalakat, amelyek a leggyorsabb és legkielégítőbb választ nyújtják a felhasználónak. Ezért az INP optimalizálás nem csupán fejlesztői feladat, hanem a SEO, UX, tartalom és infrastruktúra csapatok közös felelőssége.

Egy blogbejegyzésben a tartalomjegyzék menünek, a kategória szűrőnek vagy a hozzászólás űrlapnak gyorsan kell működnie; egy webáruházban a méretválasztásnak, a variációcserének és a kosárba helyezésnek azonnal reagálnia kell. Céges webhelyeken az ajánlatkérő űrlap, a mobilmenü és a kapcsolatfelvételi gombok nem késlekedhetnek. Ha a felhasználó gyorsnak érzi a webhelyet, tovább marad, több oldalt néz meg, és nő a konverzió valószínűsége.

A Hostragons oldalán a teljesítményközpontú tárhely, a modern szervertechnológiák és a biztonságos infrastruktúra választásával szilárd alapot teremthet technikai SEO munkálataihoz. A domain, tárhely és biztonsági konfiguráció egy központból történő kezelése csökkenti az üzemeltetési terheket, így csapata jobban összpontosíthat a felhasználói élményre és a tartalom minőségére. A kapcsolódó megoldásokért tekintse meg a Vállalati Hosting, VPS szerver és SSL tanúsítvány oldalakat.

Összegzés

Az INP pontszám javításának lényege, hogy a felhasználói interakció pillanatában ne terhelje felesleges munkával a böngészőt. Először valós adatok alapján keresse meg a leglassabb interakciókat; majd csökkentse a JavaScript terhelést, darabolja fel a hosszú feladatokat, egyszerűsítse az eseményfigyelőket, csökkentse a renderelési költséget, és tartsa ellenőrzés alatt a külső kódokat. A tárhely, a gyorsítótár, a CDN és a naprakész biztonsági konfigurációk is erős alapot biztosítanak ennek a folyamatnak a támogatásához.

Ha webhelyét gyorsabbá, megbízhatóbbá és felhasználóbarátabbá szeretné tenni, kezdje egy apró méréssel: Ellenőrizze a legkritikusabb oldalának mobil INP értékét, és alkalmazza az útmutató első három lépését. Az infrastruktúra oldalán a teljesítményorientált induláshoz tekintse meg a Hostragons megoldásait, és nyugodtan, összehasonlító módon értékelje az igényeinek megfelelő tárhelycsomagot.

Gyakran Ismételt Kérdések

Mennyi legyen az INP pontszám?

A jó INP pontszám 200 ms vagy az alatti. A 200-500 ms közötti érték fejlesztendő területet, az 500 ms feletti pedig gyenge felhasználói élményt jelez. Különösen a mobil felhasználói adatokat kell előnyben részesíteni az értékelésnél.

Mi a különbség az INP és a FID között?

A FID csupán a felhasználó első interakciójának késlekedését méri, míg az INP az oldal életciklusa során végrehajtott interakciók válaszadási minőségét értékeli. Ezért az INP átfogóbban tükrözi a valós felhasználói élményt.

Miért rossz az INP a WordPress webhelyeken?

Általában a túl sok bővítmény, a nehéz téma, a minden oldalon betöltődő felesleges CSS/JS, a csúszkák, a pop-up szkriptek és a külső kódok miatt rossz. A bővítménytakarítás, az oldal alapú fájlletiltás és a könnyű téma használata jelentős javulást hozhat.

A tárhelycsere javítja az INP pontszámot?

A tárhely önmagában nem javítja ki a nehéz JavaScriptet vagy a hosszú feladatokat, azonban a gyors szerver, a jó gyorsítótár, a CDN, a friss PHP és a stabil erőforrás-kiszolgálás támogatja az INP optimalizálást. Hatása tehát közvetett, de különösen WordPress webhelyek esetében fontos.

Mennyi idő alatt hoz eredményt az INP optimalizálás?

A kód- és bővítményjavítások elvégzése után a laboratóriumi tesztekben azonnal látható az eredmény. A Search Console és a valós felhasználói adatok esetében a változás tükröződése általában néhány hetet vehet igénybe, mivel elegendő felhasználói adatnak kell összegyűlnie.