Odemknutí výkonu webu: Hloubkový ponor do API Performance Observer

V dnešním uspěchaném digitálním světě není výkon webu luxus; je to nutnost. Pomalý nebo nereagující web může vést k frustraci uživatelů, vyšší míře okamžitého opuštění stránek a přímému negativnímu dopadu na obchodní cíle, ať už jde o prodej, příjmy z reklam nebo zapojení uživatelů. Po léta se vývojáři spoléhali na nástroje, které měří výkon v jednom časovém bodě, obvykle během počátečního načítání stránky. I když je to užitečné, tento přístup postrádá kritickou část příběhu: celkovou zkušenost uživatele při interakci se stránkou. Zde přichází na řadu monitorování výkonu za běhu a jeho nejvýkonnějším nástrojem je API Performance Observer.

Tradiční metody často zahrnují dotazování na výkonová data pomocí funkcí jako performance.getEntries(). To může být neefektivní, náchylné k zameškání klíčových událostí, které se dějí mezi dotazy, a může dokonce zvyšovat výkonovou režii, kterou se snaží měřit. API Performance Observer revolučním způsobem mění tento proces tím, že poskytuje asynchronní mechanismus s nízkou režií pro odběr událostí výkonu, jak se dějí. Tento průvodce vás provede hloubkovým ponorem do tohoto základního API a ukáže vám, jak využít jeho sílu pro monitorování Core Web Vitals, identifikaci úzkých míst a v konečném důsledku vytváření rychlejších a příjemnějších webových zážitků pro globální publikum.

Co je Performance Observer API?

V jádru je Performance Observer API rozhraní, které poskytuje způsob, jak pozorovat a shromažďovat události měření výkonu, známé jako výkonové položky. Představte si to jako vyhrazený naslouchač pro aktivity související s výkonem v prohlížeči. Místo toho, abyste se aktivně ptali prohlížeče: „Stalo se už něco?“, prohlížeč vám proaktivně říká: „Právě došlo k nové výkonnostní události! Zde jsou podrobnosti.“

Toho se dosahuje prostřednictvím vzoru observer. Vytvoříte instanci observeru, řeknete jí, jaké typy výkonnostních událostí vás zajímají (např. velké malování, uživatelské vstupy, posuny rozvržení) a poskytnete funkci zpětného volání. Kdykoli je v časové ose výkonu prohlížeče zaznamenána nová událost určitého typu, je vaše funkce zpětného volání vyvolána se seznamem nových položek. Tento asynchronní model založený na push je mnohem efektivnější a spolehlivější než starší model založený na pull opakovaného volání performance.getEntries().

Starý způsob vs. nový způsob

Abychom ocenili inovaci Performance Observer, porovnejme tyto dva přístupy:

• Starý způsob (Polling): Možná použijete setTimeout nebo requestAnimationFrame k periodickému volání performance.getEntriesByName('my-metric'), abyste zjistili, zda byla vaše metrika zaznamenána. To je problematické, protože můžete kontrolovat příliš pozdě a zmeškat událost, nebo kontrolovat příliš často a plýtvat cykly CPU. Riskujete také zaplnění výkonové vyrovnávací paměti prohlížeče, pokud položky pravidelně nevymazáváte.
• Nový způsob (Pozorování): Nastavíte PerformanceObserver jednou. Tiše sedí na pozadí a spotřebovává minimální prostředky. Jakmile je zaznamenána relevantní výkonnostní položka – ať už je to jednu milisekundu po načtení stránky, nebo deset minut do relace uživatele – je váš kód okamžitě upozorněn. To zajišťuje, že nikdy nezmeškáte událost a váš monitorovací kód je co nejefektivnější.

Proč byste měli používat Performance Observer

Integrace API Performance Observer do vašeho vývojového workflow nabízí množství výhod, které jsou kritické pro moderní webové aplikace zaměřené na globální dosah.

• Nenápadné monitorování: Zpětné volání observeru se obvykle provádí během nečinných období, což zajišťuje, že váš monitorovací kód výkonu nebude zasahovat do uživatelského zážitku ani blokovat hlavní vlákno. Je navržen tak, aby byl lehký a měl zanedbatelný dopad na výkon.
• Komplexní data za běhu: Web je dynamický. Problémy s výkonem se nedějí jen při načítání. Uživatel může spustit složitou animaci, načíst více obsahu posouváním nebo interagovat s těžkou součástí dlouho poté, co se stránka načetla. Performance Observer zachycuje tyto runtime události a poskytuje vám kompletní obrázek celé uživatelské relace.
• Budoucnost a standardizace: Je to standard doporučený W3C pro shromažďování výkonnostních dat. Nové metriky výkonu a rozhraní API jsou navrženy tak, aby se s ním integrovaly, což z něj činí udržitelnou a perspektivní volbu pro vaše projekty.
• Základ Real User Monitoring (RUM): Chcete-li skutečně pochopit, jak si vaše stránky vedou pro uživatele v různých zemích, zařízeních a síťových podmínkách, potřebujete data ze skutečných relací. Performance Observer je ideální nástroj pro vytváření robustního RUM řešení, které vám umožní shromažďovat důležité metriky a odesílat je do analytické služby pro agregaci a analýzu.
• Eliminuje závodní podmínky: Pomocí dotazování se můžete pokusit o přístup k položce výkonu, než byla zaznamenána. Model observer zcela eliminuje tuto závodní podmínku, protože váš kód běží až poté, co je položka k dispozici.

Začínáme: Základy Performance Observer

Použití API je jednoduché. Proces zahrnuje tři hlavní kroky: vytvoření observeru, definování zpětného volání a sdělení observeru, co má sledovat.

1. Vytvoření observeru se zpětným voláním

Nejprve vytvoříte instanci objektu PerformanceObserver a předáte mu funkci zpětného volání. Tato funkce se spustí při zjištění nových položek.

const observer = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log('Typ položky:', entry.entryType); console.log('Název položky:', entry.name); console.log('Doba spuštění:', entry.startTime); console.log('Trvání:', entry.duration); } });

Zpětné volání obdrží objekt PerformanceObserverEntryList. Můžete volat metodu getEntries() na tomto seznamu a získat tak pole všech nově pozorovaných položek výkonu.

2. Pozorování konkrétních typů položek

Observer nedělá nic, dokud mu neřeknete, co má sledovat. Děláte to pomocí metody .observe(). Tato metoda bere objekt s vlastností entryTypes (nebo v některých moderních případech pouze type pro jeden typ), což je pole řetězců představujících typy položek výkonu, které vás zajímají.

// Začněte pozorovat dva typy položek observer.observe({ entryTypes: ['mark', 'measure'] });

Mezi nejběžnější typy položek patří:

• 'resource': Podrobnosti o síťových požadavcích na zdroje, jako jsou skripty, obrázky a styly.
• 'paint': Časování pro first-paint a first-contentful-paint.
• 'largest-contentful-paint': Metrika Core Web Vital pro vnímanou rychlost načítání.
• 'layout-shift': Metrika Core Web Vital pro vizuální stabilitu.
• 'first-input': Informace o první interakci uživatele, používané pro First Input Delay Core Web Vital.
• 'longtask': Identifikuje úkoly na hlavním vlákně, které trvají déle než 50 milisekund, což může způsobit nereagování.
• 'mark' & 'measure': Vlastní značky a měření, které definujete ve vlastním kódu pomocí API User Timing.

3. Zastavení observeru

Když již nepotřebujete shromažďovat data, je dobrou praxí odpojit observer, abyste uvolnili prostředky.

observer.disconnect();

Praktické případy použití: Monitorování Core Web Vitals

Core Web Vitals jsou souborem specifických faktorů, které Google považuje za důležité pro celkový uživatelský zážitek na webové stránce. Jejich monitorování je jednou z nejvýkonnějších aplikací API Performance Observer. Podívejme se, jak měřit každý z nich.

Monitorování Largest Contentful Paint (LCP)

LCP měří výkon načítání. Označuje bod v časové ose načítání stránky, kdy se pravděpodobně načetl hlavní obsah. Dobré skóre LCP je 2,5 sekundy nebo méně.

Prvek LCP se může měnit při načítání stránky. Zpočátku může být prvek LCP nadpis, ale později se může načíst větší obrázek a stát se novým prvkem LCP. To je důvod, proč je Performance Observer dokonalý – upozorní vás na každého potenciálního kandidáta LCP, jak se vykresluje.

// Sledovat LCP a protokolovat konečnou hodnotu let lcpValue = 0; const lcpObserver = new PerformanceObserver((entryList) => { const entries = entryList.getEntries(); // Poslední položka je nejaktuálnější kandidát LCP const lastEntry = entries[entries.length - 1]; lcpValue = lastEntry.startTime; console.log(`LCP aktualizováno: ${lcpValue.toFixed(2)}ms`, lastEntry.element); }); lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true }); // Je dobrou praxí odpojit observer po interakci uživatele, // protože interakce mohou zastavit odesílání nových kandidátů LCP. // window.addEventListener('beforeunload', () => lcpObserver.disconnect());

Všimněte si použití buffered: true. Toto je zásadní možnost, která instruuje observer, aby zahrnul položky, které byly zaznamenány *před* voláním metody observe(). Tím zabráníte zmeškání události LCP z počátku.

Monitorování First Input Delay (FID) a Interaction to Next Paint (INP)

Tyto metriky měří interaktivitu. Kvantifikují uživatelskou zkušenost, když se poprvé pokusí interagovat se stránkou.

First Input Delay (FID) měří čas od chvíle, kdy uživatel poprvé interaguje se stránkou (např. klikne na tlačítko) do doby, kdy prohlížeč skutečně může začít zpracovávat obslužné rutiny událostí v reakci na tuto interakci. Dobré FID je 100 milisekund nebo méně.

Interaction to Next Paint (INP) je novější, komplexnější metrika, která nahradila FID jako Core Web Vital v březnu 2024. Zatímco FID měří pouze *zpoždění* *první* interakce, INP posuzuje *celkovou latenci* *všech* uživatelských interakcí v průběhu životního cyklu stránky a hlásí tu nejhorší. To poskytuje lepší představu o celkové odezvě. Dobré INP je 200 milisekund nebo méně.

FID můžete monitorovat pomocí typu položky 'first-input':

// Sledovat FID const fidObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { const fid = entry.processingStart - entry.startTime; console.log(`FID: ${fid.toFixed(2)}ms`); // Odpojit po nahlášení prvního vstupu fidObserver.disconnect(); } }); fidObserver.observe({ type: 'first-input', buffered: true });

Monitorování INP je o něco složitější, protože se dívá na celkovou dobu trvání události. Sledujete typ položky 'event' a vypočítáte trvání a sledujete tu nejdelší.

// Zjednodušený příklad monitorování INP let worstInp = 0; const inpObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // INP je trvání události const inp = entry.duration; // Zajímají nás pouze interakce delší než aktuální nejhorší if (inp > worstInp) { worstInp = inp; console.log(`Nové nejhorší INP: ${worstInp.toFixed(2)}ms`); } } }); inpObserver.observe({ type: 'event', durationThreshold: 16, buffered: true }); // durationThreshold pomáhá filtrovat velmi krátké, pravděpodobně nevýznamné události.

Monitorování Cumulative Layout Shift (CLS)

CLS měří vizuální stabilitu. Pomáhá kvantifikovat, jak často uživatelé zažívají neočekávané posuny rozvržení – frustrující zážitek, kdy se obsah na stránce pohybuje bez varování. Dobré skóre CLS je 0,1 nebo méně.

Skóre je agregace všech jednotlivých skóre posunu rozvržení. Zde je Performance Observer zásadní, protože hlásí každý posun, jak se děje.

// Pozorujte a vypočítejte celkové skóre CLS let clsScore = 0; const clsObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // Nechceme počítat posuny, které byly způsobeny vstupem uživatele if (!entry.hadRecentInput) { clsScore += entry.value; console.log(`Aktuální skóre CLS: ${clsScore.toFixed(4)}`); } } }); clsObserver.observe({ type: 'layout-shift', buffered: true });

Vlastnost hadRecentInput je důležitá. Pomáhá filtrovat legitimní posuny rozvržení, které se vyskytují v reakci na akci uživatele (například kliknutí na tlačítko, které rozbalí nabídku), které by se neměly započítávat do skóre CLS.

Kromě Core Web Vitals: Další výkonné typy položek

Zatímco Core Web Vitals jsou skvělým výchozím bodem, Performance Observer dokáže monitorovat mnohem více. Zde je několik dalších neuvěřitelně užitečných typů položek.

Sledování dlouhých úkolů (`longtask`)

API Long Tasks zveřejňuje úkoly, které zabírají hlavní vlákno po dobu 50 milisekund nebo déle. Ty jsou problematické, protože zatímco je hlavní vlákno zaneprázdněno, stránka nemůže reagovat na uživatelský vstup, což vede k pomalému nebo zmrazenému zážitku. Identifikace těchto úkolů je klíčová pro zlepšení INP.

// Sledovat dlouhé úkoly const longTaskObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log(`Detekován dlouhý úkol: ${entry.duration.toFixed(2)}ms`); // Vlastnost 'attribution' vám může někdy říct, co způsobilo dlouhý úkol console.log('Atribuci:', entry.attribution); } }); longTaskObserver.observe({ type: 'longtask', buffered: true });

Analýza časování zdrojů (`resource`)

Pochopení toho, jak se vaše zdroje načítají, je zásadní pro ladění výkonu. Typ položky 'resource' vám poskytuje podrobná data o časování sítě pro každý zdroj na vaší stránce, včetně vyhledávání DNS, připojení TCP a doby stahování obsahu.

// Sledovat časování zdrojů const resourceObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // Najděme pomalu se načítající obrázky if (entry.initiatorType === 'img' && entry.duration > 500) { console.warn(`Detekován pomalý obrázek: ${entry.name}`, `Trvání: ${entry.duration.toFixed(2)}ms`); } } }); // Použití 'buffered: true' je téměř vždy nezbytné pro časování zdrojů // zachytit aktiva, která se načetla před spuštěním tohoto skriptu. resourceObserver.observe({ type: 'resource', buffered: true });

Měření vlastních výkonnostních značek (`mark` a `measure`)

Někdy potřebujete změřit výkon logiky specifické pro aplikaci. API User Timing umožňuje vytvářet vlastní časová razítka a měřit dobu trvání mezi nimi.

• performance.mark('start-operation'): Vytvoří časové razítko s názvem 'start-operation'.
• performance.mark('end-operation'): Vytvoří další časové razítko.
• performance.measure('my-operation', 'start-operation', 'end-operation'): Vytvoří měření mezi dvěma značkami.

Performance Observer může naslouchat těmto vlastním položkám 'mark' a 'measure', což je ideální pro shromažďování dat o časování věcí, jako jsou časy vykreslování komponent v JavaScriptovém frameworku nebo doba trvání kritického volání API a následného zpracování dat.

// Ve vašem aplikačním kódu: performance.mark('start-data-processing'); // ... nějaké složité zpracování dat ... performance.mark('end-data-processing'); performance.measure('data-processing-duration', 'start-data-processing', 'end-data-processing'); // Ve vašem monitorovacím skriptu: const customObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntriesByName('data-processing-duration')) { console.log(`Vlastní měření '${entry.name}': ${entry.duration.toFixed(2)}ms`); } }); customObserver.observe({ entryTypes: ['measure'] });

Pokročilé koncepty a osvědčené postupy

Chcete-li efektivně používat API Performance Observer v profesionálním produkčním prostředí, zvažte tyto osvědčené postupy.

• Vždy zvažte `buffered: true`: Pro typy položek, které se mohou vyskytnout brzy při načítání stránky (jako 'resource', 'paint' nebo 'largest-contentful-paint'), je použití příznaku buffered zásadní, aby vám neunikly.
• Zkontrolujte podporu prohlížeče: I když je široce podporováno v moderních prohlížečích, je vždy moudré zkontrolovat jeho existenci před jeho použitím. Můžete také zkontrolovat, které typy položek jsou podporovány konkrétním prohlížečem.
if ('PerformanceObserver' in window && PerformanceObserver.supportedEntryTypes.includes('longtask')) { // PerformanceObserver je bezpečné používat pro dlouhé úkoly }
• Odesílejte data do analytické služby: Protokolování dat do konzole je skvělé pro vývoj, ale pro monitorování v reálném světě musíte tato data agregovat. Nejlepší způsob, jak odeslat tuto telemetrii z klienta, je použití API navigator.sendBeacon(). Je to neblokovací mechanismus určený pro odesílání malých množství dat na server a funguje spolehlivě i při odpojování stránky.
• Seskupujte observatory podle zájmu: I když můžete použít jeden observer pro více typů položek, je často přehlednější vytvořit samostatné observatory pro různé zájmy (např. jeden pro Core Web Vitals, jeden pro časování zdrojů, jeden pro vlastní metriky). Tím se zlepší čitelnost a udržovatelnost kódu.
• Pochopte režii výkonu: API je navrženo tak, aby mělo velmi nízkou režii. Velmi složitá funkce zpětného volání, která provádí složité výpočty, by však mohla potenciálně ovlivnit výkon. Udržujte zpětná volání vašeho observeru štíhlá a efektivní. Odložte jakékoli složité zpracování na web worker nebo odešlete nezpracovaná data do svého backendu, kde se zpracovávají.

Závěr: Budování kultury zaměřené na výkon

API Performance Observer je víc než jen další nástroj; je to zásadní posun v tom, jak přistupujeme k výkonu webu. Přesouvá nás od reaktivních, jednorázových měření k proaktivnímu, nepřetržitému monitorování, které odráží skutečnou, dynamickou zkušenost našich uživatelů po celém světě. Tím, že poskytuje spolehlivý a efektivní způsob, jak zachytit Core Web Vitals, dlouhé úkoly, časování zdrojů a vlastní metriky, umožňuje vývojářům identifikovat a řešit úzká hrdla výkonu dříve, než ovlivní významný počet uživatelů.

Přijetí API Performance Observer je kritickým krokem k budování kultury zaměřené na výkon v jakémkoli vývojovém týmu. Když můžete měřit to, na čem záleží, můžete zlepšit to, na čem záleží. Začněte integrovat tyto observatory do svých projektů ještě dnes. Vaši uživatelé – ať už jsou kdekoli na světě – vám poděkují za rychlejší, plynulejší a příjemnější zážitek.