Performancë
INP — vonesa deri te vizatimi pasues
Sa shpejt reagon faqja te ndërveprimet; metrika aktuale e reagimit, e vlerësuar këtu nga numërimi i trajtuesve.
Çfarë është
INP (*Interaction to Next Paint*) mat kohën nga një ndërveprim i përdoruesit deri kur ekrani përditësohet si përgjigje.
Ajo zëvendësoi FID-në në mars 2024 dhe e mat problemin më gjerë në dy mënyra. Së pari, merr parasysh të gjitha ndërveprimet gjatë vizitës, jo vetëm të parin. Së dyti, mat gjithë zinxhirin — vonesën para se trajtuesi të nisë, kohëzgjatjen e vetë trajtuesit, dhe kohën derisa ekrani të përditësohet.
Pragjet: deri 200 ms e mirë, deri 500 ms e përmirësueshme, mbi 500 ms e dobët.
Pse ka rëndësi
INP mat atë që përdoruesi ndien si "faqja është e ngadaltë" edhe pasi është ngarkuar. Një menu që hapet pas gjysmë sekonde, një fushë kërkimi që nuk shkruan menjëherë, një buton që nuk ndryshon pamje kur shtypet — të gjitha janë INP e keqe.
Shkaku zakonisht nuk është ngarkimi por kodi që xhiron në përgjigje të veprimit: një trajtues që bën punë të rëndë, një ndryshim i madh DOM-i që detyron rillogaritje layout-i, ose një kërkesë rrjeti pa asnjë shenjë pritjeje.
Në pajisje të lira dhe faqe të ngarkuara, INP është sot metrika ku dështojnë më shumë sajte.
Efekti te renditja është ai i Core Web Vitals — i vogël. Efekti te përdorimi është i drejtpërdrejtë: një formular që reagon ngadalë braktiset.
Si rregullohet
- Jep reagim të menjëhershëm. Ndrysho pamjen e butonit para se të nisësh punën e rëndë.
- Copëto detyrat e gjata: ``
js btn.addEventListener('click', async () => { shfaqPritjen(); // përditësim i menjëhershëm await scheduler.yield?.(); // lësho fillin që ekrani të vizatohet punaERende(); });`` - Mos bëj punë të rëndë brenda trajtuesve të `input` dhe `scroll`. Përdor kufizim ritmi.
- Ul numrin e ndryshimeve të DOM-it për një veprim; grumbulloji.
- Zhvendos llogaritjet te një Web Worker.
- Zvogëlo DOM-in — çdo rillogaritje layout-i kushton në raport me madhësinë e tij.
Si e mat ky mjet
CoreWebVitalsAnalyzer::estimateINP() (services/CoreWebVitalsAnalyzer.php:218) numëron sa herë shfaqen vargjet onclick, onchange, oninput dhe addEventListener brenda tekstit të plotë të HTML-së (:221–224), pastaj llogarit 50 ms + 10 × trajtues + 5 × addEventListener (:229–231), me tavan 1000 ms.
Klasifikimi te analyze() (:77): mbi 500 ms kritike me −15 pikë, mbi 200 ms paralajmërim me −8 pikë. Nën 200 ms nuk prodhohet asnjë konstatim — as pozitiv.
Çfarë NUK e mat
Ky numër është vlerësim heuristik, jo matje. Mjeti nuk e hap faqen në shfletues dhe nuk mat asnjë metrikë reale performance. Ai llogarit një numër nga tipare të HTML-së statike me koeficientë të shkruar në kod. Numërimi bëhet me kërkim nënvargu mbi HTML-në e papërpunuar. Kjo do të thotë se vargu onclick numërohet edhe kur shfaqet brenda një komenti, brenda një teksti, ose si pjesë e një fjale tjetër.
Më e rëndësishmja: skriptet e jashtme nuk lexohen fare. Një aplikacion modern që i regjistron të gjithë trajtuesit brenda një pakete .js merr numërim zero dhe vlerësim 50 ms — pra vlerësimin më të mirë të mundshëm — ndonëse mund të jetë pikërisht faqja me INP-në më të keqe.
Anasjelltas, një faqe e vjetër me njëzet atribute onclick që bëjnë punë të parëndësishme merr vlerësim të dobët.
Numri nuk duhet krahasuar me pragun zyrtar 200 ms. INP i vërtetë matet vetëm nga ndërveprime të vizitorëve realë.
Kodi që e kryen matjen
services/CoreWebVitalsAnalyzer.php:218— CoreWebVitalsAnalyzer::estimateINPservices/CoreWebVitalsAnalyzer.php:77— Poor INP