Dog艂臋bna analiza Web Performance API, od tradycyjnych pomiar贸w czasu po nowoczesne metryki Core Web Vitals i jak je 艂膮czy膰 dla pe艂nego obrazu wydajno艣ci.
Wi臋cej ni偶 zegar: Jak po艂膮czy膰 Web Performance API z realnym do艣wiadczeniem u偶ytkownika
W gospodarce cyfrowej szybko艣膰 to nie tylko funkcja; to fundament do艣wiadczenia u偶ytkownika. Wolna strona internetowa mo偶e prowadzi膰 do frustracji u偶ytkownik贸w, wy偶szych wska藕nik贸w odrzuce艅 i mie膰 bezpo艣redni wp艂yw na przychody. Przez lata deweloperzy polegali na metrykach czasowych, takich jak window.onload, aby oceni膰 wydajno艣膰. Ale czy szybki czas 艂adowania naprawd臋 oznacza zadowolonego u偶ytkownika? Odpowied藕 cz臋sto brzmi: nie.
Strona mo偶e zako艅czy膰 艂adowanie wszystkich swoich technicznych zasob贸w w mniej ni偶 sekund臋, a mimo to wydawa膰 si臋 powolna i niefunkcjonalna dla prawdziwej osoby pr贸buj膮cej z ni膮 wej艣膰 w interakcj臋. Ta rozbie偶no艣膰 podkre艣la kluczow膮 ewolucj臋 w tworzeniu stron internetowych: przej艣cie od mierzenia technicznych czas贸w do kwantyfikacji ludzkiego do艣wiadczenia. Nowoczesna wydajno艣膰 internetowa to opowie艣膰 o dw贸ch perspektywach: szczeg贸艂owych danych niskiego poziomu dostarczanych przez Web Performance API oraz wysokopoziomowych, skoncentrowanych na u偶ytkowniku metrykach, takich jak Core Web Vitals od Google.
Ten kompleksowy przewodnik wype艂ni t臋 luk臋. Zbadamy pot臋偶ny zestaw Web Performance API, kt贸re dzia艂aj膮 jak nasze narz臋dzia diagnostyczne. Nast臋pnie zag艂臋bimy si臋 w nowoczesne metryki do艣wiadczenia u偶ytkownika, kt贸re m贸wi膮 nam, jak wydajno艣膰 jest *odczuwana*. Co najwa偶niejsze, po艂膮czymy kropki, pokazuj膮c, jak wykorzysta膰 niskopoziomowe dane czasowe do diagnozowania i naprawiania pierwotnych przyczyn z艂ego do艣wiadczenia u偶ytkownika dla Twojej globalnej publiczno艣ci.
Podstawa: Zrozumienie Web Performance API
Web Performance API to zestaw standardowych interfejs贸w przegl膮darki, kt贸re daj膮 deweloperom dost臋p do bardzo szczeg贸艂owych i dok艂adnych danych czasowych zwi膮zanych z nawigacj膮 i renderowaniem strony internetowej. Stanowi膮 one fundament pomiaru wydajno艣ci, pozwalaj膮c nam wyj艣膰 poza proste stopery i zrozumie膰 skomplikowany taniec 偶膮da艅 sieciowych, parsowania i renderowania.
Navigation Timing API: Podr贸偶 strony
Navigation Timing API dostarcza szczeg贸艂owego rozbicia czasu potrzebnego na za艂adowanie g艂贸wnego dokumentu. Rejestruje kamienie milowe od momentu zainicjowania nawigacji przez u偶ytkownika (np. klikni臋cia linku) do momentu pe艂nego za艂adowania strony. To nasz pierwszy i najbardziej fundamentalny wgl膮d w proces 艂adowania strony.
Mo偶esz uzyska膰 dost臋p do tych danych za pomoc膮 prostego wywo艂ania JavaScript:
const navigationEntry = performance.getEntriesByType('navigation')[0];
console.log(navigationEntry.toJSON());
Zwraca to obiekt pe艂en znacznik贸w czasu. Niekt贸re kluczowe w艂a艣ciwo艣ci to:
- fetchStart: Kiedy przegl膮darka zaczyna pobiera膰 dokument.
- responseStart: Kiedy przegl膮darka otrzymuje pierwszy bajt odpowiedzi z serwera. Czas mi臋dzy
fetchStartaresponseStartjest cz臋sto nazywany Time to First Byte (TTFB). - domContentLoadedEventEnd: Kiedy pocz膮tkowy dokument HTML zosta艂 w pe艂ni za艂adowany i sparsowany, bez oczekiwania na za艂adowanie arkuszy styl贸w, obraz贸w i podrz臋dnych ramek.
- loadEventEnd: Kiedy wszystkie zasoby strony (w tym obrazy, CSS itp.) zosta艂y w pe艂ni za艂adowane.
Przez d艂ugi czas loadEventEnd by艂 z艂otym standardem. Jednak jego ograniczenie jest powa偶ne: nie m贸wi nic o tym, kiedy u偶ytkownik *widzi* znacz膮c膮 tre艣膰 ani kiedy mo偶e *interaktowa膰* ze stron膮. To kamie艅 milowy techniczny, a nie ludzki.
Resource Timing API: Dekonstrukcja komponent贸w
Strona internetowa rzadko jest pojedynczym plikiem. To zbi贸r HTML, CSS, JavaScript, obraz贸w, czcionek i wywo艂a艅 API. Resource Timing API pozwala na inspekcj臋 czas贸w sieciowych dla ka偶dego z tych indywidualnych zasob贸w.
Jest to niezwykle pot臋偶ne narz臋dzie do identyfikacji w膮skich garde艂. Czy du偶y, niezoptymalizowany obraz 'hero' z sieci dostarczania tre艣ci (CDN) na innym kontynencie spowalnia pocz膮tkowe renderowanie? Czy skrypt analityczny strony trzeciej blokuje g艂贸wny w膮tek? Resource Timing pomaga odpowiedzie膰 na te pytania.
Mo偶esz uzyska膰 list臋 wszystkich zasob贸w w ten spos贸b:
const resourceEntries = performance.getEntriesByType('resource');
resourceEntries.forEach(resource => {
if (resource.duration > 200) { // Znajd藕 zasoby, kt贸re 艂adowa艂y si臋 d艂u偶ej ni偶 200ms
console.log(`Wolny zas贸b: ${resource.name}, Czas trwania: ${resource.duration}ms`);
}
});
Kluczowe w艂a艣ciwo艣ci to name (URL zasobu), initiatorType (co spowodowa艂o za艂adowanie zasobu, np. 'img', 'script') oraz duration (ca艂kowity czas potrzebny na jego pobranie).
User Timing API: Mierzenie logiki Twojej aplikacji
Czasami w膮skie gard艂o wydajno艣ci nie le偶y w 艂adowaniu zasob贸w, ale w samym kodzie po stronie klienta. Ile czasu zajmuje Twojej aplikacji jednostronicowej (SPA) wyrenderowanie z艂o偶onego komponentu po otrzymaniu danych z API? User Timing API pozwala na tworzenie niestandardowych, specyficznych dla aplikacji pomiar贸w.
Dzia艂a ono za pomoc膮 dw贸ch g艂贸wnych metod:
- performance.mark(name): Tworzy nazwany znacznik czasu w buforze wydajno艣ci.
- performance.measure(name, startMark, endMark): Oblicza czas trwania mi臋dzy dwoma znacznikami i tworzy nazwany pomiar.
Przyk艂ad: Pomiar czasu renderowania komponentu listy produkt贸w.
// Kiedy zaczynasz pobiera膰 dane
performance.mark('product-list-fetch-start');
fetch('/api/products')
.then(response => response.json())
.then(data => {
// Po pobraniu, przed renderowaniem
performance.mark('product-list-render-start');
renderProductList(data);
// Bezpo艣rednio po zako艅czeniu renderowania
performance.mark('product-list-render-end');
// Utw贸rz pomiar
performance.measure(
'Czas renderowania listy produkt贸w',
'product-list-render-start',
'product-list-render-end'
);
});
Daje to precyzyjn膮 kontrol臋 nad mierzeniem tych cz臋艣ci aplikacji, kt贸re s膮 najbardziej krytyczne dla przep艂ywu pracy u偶ytkownika.
PerformanceObserver: Nowoczesne i wydajne podej艣cie
Ci膮g艂e odpytywanie `performance.getEntriesByType()` jest nieefektywne. `PerformanceObserver` API zapewnia znacznie lepszy spos贸b nas艂uchiwania na wpisy dotycz膮ce wydajno艣ci. Subskrybujesz okre艣lone typy wpis贸w, a przegl膮darka asynchronicznie powiadamia Twoj膮 funkcj臋 zwrotn膮, gdy zostan膮 one zarejestrowane. Jest to zalecany spos贸b zbierania danych o wydajno艣ci bez dodawania narzutu do aplikacji.
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log(`Typ wpisu: ${entry.entryType}, Nazwa: ${entry.name}`);
}
});
observer.observe({ entryTypes: ['resource', 'navigation', 'mark', 'measure'] });
Ten obserwator jest kluczem do zbierania nie tylko tradycyjnych metryk wymienionych powy偶ej, ale tak偶e nowoczesnych, skoncentrowanych na u偶ytkowniku metryk, kt贸re om贸wimy w nast臋pnej kolejno艣ci.
Przej艣cie na podej艣cie zorientowane na u偶ytkownika: Core Web Vitals
Wiedza, 偶e strona za艂adowa艂a si臋 w 2 sekundy, jest u偶yteczna, ale nie odpowiada na kluczowe pytania: Czy u偶ytkownik patrzy艂 na pusty ekran przez te 2 sekundy? Czy m贸g艂 wej艣膰 w interakcj臋 ze stron膮, czy by艂a ona zamro偶ona? Czy tre艣膰 niespodziewanie przeskakiwa艂a, gdy pr贸bowa艂 j膮 czyta膰?
Aby rozwi膮za膰 ten problem, Google wprowadzi艂o Core Web Vitals (CWV), zestaw metryk zaprojektowanych do mierzenia rzeczywistego do艣wiadczenia u偶ytkownika na stronie w trzech kluczowych wymiarach: 艂adowania, interaktywno艣ci i stabilno艣ci wizualnej.
Largest Contentful Paint (LCP): Mierzenie postrzeganego 艂adowania
LCP mierzy czas renderowania najwi臋kszego obrazu lub bloku tekstu widocznego w obr臋bie rzutni (viewport). Jest to doskona艂y wska藕nik tego, kiedy u偶ytkownik czuje, 偶e g艂贸wna zawarto艣膰 strony zosta艂a za艂adowana. Bezpo艣rednio odpowiada na pytanie u偶ytkownika: "Czy ta strona jest ju偶 u偶yteczna?"
- Dobry: Poni偶ej 2.5 sekundy
- Wymaga poprawy: Mi臋dzy 2.5s a 4.0s
- S艂aby: Powy偶ej 4.0 sekundy
W przeciwie艅stwie do `loadEventEnd`, LCP koncentruje si臋 na tym, co u偶ytkownik widzi jako pierwsze, co czyni go znacznie dok艂adniejszym odzwierciedleniem postrzeganej pr臋dko艣ci 艂adowania.
Interaction to Next Paint (INP): Mierzenie responsywno艣ci
INP jest nast臋pc膮 First Input Delay (FID) i sta艂 si臋 oficjalnym Core Web Vital w marcu 2024 roku. Podczas gdy FID mierzy艂 tylko op贸藕nienie *pierwszej* interakcji, INP mierzy op贸藕nienie *wszystkich* interakcji u偶ytkownika (klikni臋膰, dotkni臋膰, naci艣ni臋膰 klawiszy) w ca艂ym cyklu 偶ycia strony. Raportuje najd艂u偶sz膮 interakcj臋, skutecznie identyfikuj膮c najgorszy przypadek responsywno艣ci, jakiego do艣wiadcza u偶ytkownik.
INP mierzy ca艂y czas od momentu wprowadzenia danych przez u偶ytkownika do namalowania nast臋pnej klatki, odzwierciedlaj膮c wizualn膮 informacj臋 zwrotn膮. Odpowiada na pytanie u偶ytkownika: "Kiedy klikam ten przycisk, czy strona reaguje szybko?"
- Dobry: Poni偶ej 200 milisekund
- Wymaga poprawy: Mi臋dzy 200ms a 500ms
- S艂aby: Powy偶ej 500ms
Wysoki INP jest zwykle spowodowany zaj臋tym g艂贸wnym w膮tkiem, gdzie d艂ugo dzia艂aj膮ce zadania JavaScript uniemo偶liwiaj膮 przegl膮darce reagowanie na dane wej艣ciowe u偶ytkownika.
Cumulative Layout Shift (CLS): Mierzenie stabilno艣ci wizualnej
CLS mierzy stabilno艣膰 wizualn膮 strony. Kwantyfikuje, jak bardzo tre艣膰 niespodziewanie przesuwa si臋 na ekranie podczas procesu 艂adowania. Wysoki wynik CLS jest cz臋stym 藕r贸d艂em frustracji u偶ytkownika, na przyk艂ad gdy pr贸bujesz klikn膮膰 przycisk, ale nad nim 艂aduje si臋 reklama, przesuwaj膮c przycisk w d贸艂 i powoduj膮c, 偶e zamiast tego klikasz reklam臋.
CLS odpowiada na pytanie u偶ytkownika: "Czy mog臋 korzysta膰 z tej strony bez element贸w skacz膮cych po ca艂ym ekranie?"
- Dobry: Poni偶ej 0.1
- Wymaga poprawy: Mi臋dzy 0.1 a 0.25
- S艂aby: Powy偶ej 0.25
Cz臋stymi przyczynami wysokiego CLS s膮 obrazy lub ramki iframe bez wymiar贸w, p贸藕ne 艂adowanie czcionek internetowych lub dynamiczne wstrzykiwanie tre艣ci na stron臋 bez zarezerwowania dla niej miejsca.
Wype艂nianie luki: U偶ywanie API do diagnozowania z艂ego do艣wiadczenia u偶ytkownika
To jest moment, w kt贸rym wszystko si臋 艂膮czy. Core Web Vitals m贸wi膮 nam, *co* do艣wiadczy艂 u偶ytkownik (np. wolne LCP). Web Performance API m贸wi膮 nam, *dlaczego* tak si臋 sta艂o. 艁膮cz膮c je, przechodzimy od prostego obserwowania wydajno艣ci do aktywnego jej diagnozowania i naprawiania.
Diagnozowanie wolnego LCP
Wyobra藕 sobie, 偶e Twoje narz臋dzie do monitorowania rzeczywistych u偶ytkownik贸w (RUM) zg艂asza s艂aby LCP wynosz膮cy 4,5 sekundy dla u偶ytkownik贸w w okre艣lonym regionie. Jak to naprawi膰? Musisz rozbi膰 czas LCP na jego cz臋艣ci sk艂adowe.
- Time to First Byte (TTFB): Czy serwer wolno odpowiada? U偶yj Navigation Timing API. Czas trwania `responseStart - requestStart` daje precyzyjny TTFB. Je艣li jest wysoki, problem le偶y po stronie Twojego backendu, konfiguracji serwera lub bazy danych, a nie frontendu.
- Op贸藕nienie i czas 艂adowania zasobu: Czy sam element LCP wolno si臋 艂aduje? Najpierw zidentyfikuj element LCP (np. obraz 'hero'). Mo偶esz u偶y膰 `PerformanceObserver` dla `'largest-contentful-paint'`, aby uzyska膰 sam element. Nast臋pnie u偶yj Resource Timing API, aby znale藕膰 wpis dla adresu URL tego elementu. Przeanalizuj jego o艣 czasu: Czy wyst膮pi艂o d艂ugie op贸藕nienie od `connectStart` do `connectEnd` (wolna sie膰)? Czy czas od `responseStart` do `responseEnd` by艂 d艂ugi (ogromny rozmiar pliku)? Czy jego `fetchStart` zosta艂 op贸藕niony, poniewa偶 by艂 blokowany przez inne zasoby blokuj膮ce renderowanie, takie jak CSS lub JavaScript?
- Op贸藕nienie renderowania elementu: Jest to czas od zako艅czenia 艂adowania zasobu do momentu, gdy zostanie on faktycznie namalowany na ekranie. Mo偶e to by膰 spowodowane tym, 偶e g艂贸wny w膮tek jest zaj臋ty innymi zadaniami, takimi jak wykonywanie du偶ego pakietu JavaScript.
U偶ywaj膮c Navigation i Resource Timing, mo偶esz dok艂adnie okre艣li膰, czy wolne LCP jest spowodowane powolnym serwerem, skryptem blokuj膮cym renderowanie, czy te偶 ogromnym, niezoptymalizowanym obrazem.
Badanie s艂abego INP
Twoi u偶ytkownicy skar偶膮 si臋, 偶e klikni臋cie przycisku "Dodaj do koszyka" wydaje si臋 op贸藕nione. Twoja metryka INP jest w zakresie "S艂aby". To prawie zawsze jest problem z g艂贸wnym w膮tkiem.
- Identyfikuj d艂ugie zadania (Long Tasks): Long Tasks API jest tutaj Twoim g艂贸wnym narz臋dziem. Raportuje ka偶de zadanie w g艂贸wnym w膮tku, kt贸re trwa d艂u偶ej ni偶 50 ms, poniewa偶 wszystko, co trwa d艂u偶ej, grozi zauwa偶alnym op贸藕nieniem dla u偶ytkownika. Skonfiguruj `PerformanceObserver`, aby nas艂uchiwa艂 na wpisy `'longtask'`.
- Skoreluj z akcjami u偶ytkownika: D艂ugie zadanie jest problemem tylko wtedy, gdy wyst臋puje, gdy u偶ytkownik pr贸buje wej艣膰 w interakcj臋. Mo偶esz skorelowa膰 `startTime` zdarzenia INP (obserwowanego za pomoc膮 `PerformanceObserver` dla typu `'event'`) z czasami wyst膮pienia d艂ugich zada艅, kt贸re mia艂y miejsce w tym samym czasie. To powie Ci dok艂adnie, kt贸ra funkcja JavaScript zablokowa艂a interakcj臋 u偶ytkownika.
- Mierz konkretne handlery: U偶yj User Timing API, aby uzyska膰 jeszcze wi臋ksz膮 szczeg贸艂owo艣膰. Owi艅 swoje krytyczne handlery zdarze艅 (takie jak handler 'click' dla "Dodaj do koszyka") za pomoc膮 `performance.mark()` i `performance.measure()`. Powie Ci to dok艂adnie, ile czasu zajmuje wykonanie Twojego w艂asnego kodu i czy to on jest 藕r贸d艂em d艂ugiego zadania.
Radzenie sobie z wysokim CLS
U偶ytkownicy zg艂aszaj膮, 偶e tekst przeskakuje, gdy czytaj膮 artyku艂 na swoich urz膮dzeniach mobilnych. Tw贸j wynik CLS wynosi 0.3.
- Obserwuj przesuni臋cia uk艂adu (Layout Shifts): U偶yj `PerformanceObserver`, aby nas艂uchiwa膰 na wpisy `'layout-shift'`. Ka偶dy wpis b臋dzie mia艂 `value` (jego wk艂ad w wynik CLS) oraz list臋 `sources`, czyli element贸w DOM, kt贸re si臋 przesun臋艂y. To m贸wi Ci, *co* si臋 przesun臋艂o.
- Znajd藕 winny zas贸b: Nast臋pne pytanie brzmi, *dlaczego* si臋 przesun膮艂. Cz臋st膮 przyczyn膮 jest p贸藕ne za艂adowanie zasobu, kt贸ry spycha inn膮 tre艣膰 w d贸艂. Mo偶esz skorelowa膰 `startTime` wpisu `layout-shift` z czasem `responseEnd` wpis贸w z Resource Timing API. Je艣li przesuni臋cie uk艂adu nast臋puje tu偶 po zako艅czeniu 艂adowania skryptu reklamowego lub du偶ego obrazu, prawdopodobnie znalaz艂e艣 winowajc臋.
- Proaktywne rozwi膮zania: Naprawa cz臋sto polega na podaniu wymiar贸w dla obraz贸w i reklam (`
`) lub zarezerwowaniu miejsca na stronie dla dynamicznej tre艣ci przed jej za艂adowaniem. Resource Timing pomaga zidentyfikowa膰, o kt贸re zasoby musisz zadba膰 proaktywnie.
Praktyczna implementacja: Budowa globalnego systemu monitoringu
Zrozumienie tych API to jedno; wdro偶enie ich do monitorowania do艣wiadcze艅 globalnej bazy u偶ytkownik贸w to kolejny krok. To jest domena monitorowania rzeczywistych u偶ytkownik贸w (Real User Monitoring, RUM).
艁膮czenie wszystkiego w ca艂o艣膰 za pomoc膮 `PerformanceObserver`
Mo偶esz stworzy膰 jeden, pot臋偶ny skrypt do zbierania wszystkich tych kluczowych danych. Celem jest zebranie metryk i ich kontekstu bez wp艂ywu na wydajno艣膰, kt贸r膮 pr贸bujesz mierzy膰.
Oto koncepcyjny fragment solidnej konfiguracji obserwatora:
const collectedMetrics = {};
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.entryType === 'largest-contentful-paint') {
collectedMetrics.lcp = entry.startTime;
} else if (entry.entryType === 'layout-shift') {
collectedMetrics.cls = (collectedMetrics.cls || 0) + entry.value;
} else if (entry.entryType === 'event') {
// To jest uproszczony widok obliczania INP
const duration = entry.duration;
if (duration > (collectedMetrics.inp || 0)) {
collectedMetrics.inp = duration;
}
}
// ... i tak dalej dla innych typ贸w wpis贸w, jak 'longtask'
}
});
observer.observe({ entryTypes: ['largest-contentful-paint', 'layout-shift', 'event', 'longtask'] });
Niezawodne wysy艂anie danych
Gdy ju偶 zbierzesz swoje dane, musisz je wys艂a膰 do backendu analitycznego w celu przechowywania i analizy. Kluczowe jest, aby zrobi膰 to bez op贸藕niania zamykania strony i bez utraty danych od u偶ytkownik贸w, kt贸rzy szybko zamykaj膮 swoje karty.
API `navigator.sendBeacon()` jest do tego idealne. Zapewnia niezawodny, asynchroniczny spos贸b wysy艂ania niewielkiej ilo艣ci danych na serwer, nawet je艣li strona jest w trakcie zamykania. Nie oczekuje odpowiedzi, co czyni go lekkim i nieblokuj膮cym.
window.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
const payload = JSON.stringify(collectedMetrics);
navigator.sendBeacon('/api/performance-analytics', payload);
}
});
Znaczenie globalnej perspektywy
Narz臋dzia do testowania laboratoryjnego, takie jak Lighthouse, s膮 nieocenione, ale dzia艂aj膮 w kontrolowanym 艣rodowisku. Dane RUM zebrane za pomoc膮 tych API m贸wi膮 Ci prawd臋 o tym, czego do艣wiadczaj膮 Twoi u偶ytkownicy w r贸偶nych krajach, warunkach sieciowych i na r贸偶nych urz膮dzeniach.
Analizuj膮c swoje dane, zawsze je segmentuj. Mo偶esz odkry膰, 偶e:
- Twoje LCP jest doskona艂e dla u偶ytkownik贸w w Ameryce P贸艂nocnej, ale s艂abe dla u偶ytkownik贸w w Australii, poniewa偶 Tw贸j g艂贸wny serwer obraz贸w znajduje si臋 w USA.
- Twoje INP jest wysokie na urz膮dzeniach z Androidem 艣redniej klasy, kt贸re s膮 popularne na rynkach wschodz膮cych, poniewa偶 Tw贸j JavaScript jest dla nich zbyt intensywny procesorowo.
- Twoje CLS jest problemem tylko na okre艣lonych rozmiarach ekranu, gdzie zapytanie media query w CSS powoduje nieprawid艂owe przeskalowanie reklamy.
Ten poziom segmentowanego wgl膮du pozwala priorytetyzowa膰 optymalizacje, kt贸re b臋d膮 mia艂y najwi臋kszy wp艂yw na Twoj膮 rzeczywist膮 baz臋 u偶ytkownik贸w, gdziekolwiek si臋 znajduj膮.
Podsumowanie: Od pomiaru do mistrzostwa
艢wiat wydajno艣ci internetowej dojrza艂. Przeszli艣my od prostych pomiar贸w technicznych do zaawansowanego zrozumienia postrzeganego do艣wiadczenia u偶ytkownika. Ta podr贸偶 obejmuje trzy kluczowe kroki:
- Mierz do艣wiadczenie: U偶yj `PerformanceObserver` do zbierania Core Web Vitals (LCP, INP, CLS). To m贸wi Ci, *co* si臋 dzieje i *jakie to uczucie* dla u偶ytkownika.
- Diagnozuj przyczyn臋: U偶yj fundamentalnych API Czasowych (Navigation, Resource, User, Long Tasks), aby zag艂臋bi膰 si臋 w temat. To m贸wi Ci, *dlaczego* do艣wiadczenie jest s艂abe.
- Dzia艂aj z precyzj膮: U偶yj po艂膮czonych danych, aby dokonywa膰 艣wiadomych, ukierunkowanych optymalizacji, kt贸re rozwi膮zuj膮 pierwotn膮 przyczyn臋 problemu dla okre艣lonych segment贸w u偶ytkownik贸w.
Opanowuj膮c zar贸wno wysokopoziomowe metryki u偶ytkownika, jak i niskopoziomowe API diagnostyczne, mo偶esz zbudowa膰 holistyczn膮 strategi臋 wydajno艣ci. Przestajesz zgadywa膰 i zaczynasz projektowa膰 do艣wiadczenie internetowe, kt贸re jest nie tylko technicznie szybkie, ale tak偶e odczuwalnie szybkie, responsywne i przyjemne dla ka偶dego u偶ytkownika, na ka偶dym urz膮dzeniu, na ca艂ym 艣wiecie.