Audyt wydajności i Core Web Vitals

Faza P3 · Etap A — Zrozum
Ramy czasowe: 4–8 godzin na reprezentatywny audyt; 2–5 dni roboczych na badanie obejmujące cały szablon ze śladami inżynieryjnymi. 28-dniowa walidacja terenowa następuje po poprawkach i nie wydłuża początkowych ram czasowych audytu.
Właściciel: lider SEO technicznego odpowiada za zakres i akceptację. Inżynier wydajności lub starszy inżynier front-end odpowiada za diagnozę; właściciele platformy, CDN, analityki, projektu i produktu wnoszą wkład tam, gdzie ich systemy powodują opóźnienia lub niestabilność.

Ta faza przekształca dowody terenowe od rzeczywistych użytkowników i powtarzalne testy laboratoryjne w rejestr naprawczy powiązany z adresami URL, szablonami, metrykami, właścicielami i kryteriami ukończenia — a nie w ogólną ocenę szybkości.

Dlaczego ta faza i dlaczego tutaj

Wydajność należy do Etapu A, ponieważ strona, która się nie ładuje, jest problemem indeksacyjnym, zanim stanie się problemem UX. Crawler lub agent pobierający ma ograniczony budżet żądań. Jeśli serwer zwleka, wielokrotnie przekierowuje lub zwraca niekompletną odpowiedź, klient może porzucić stronę, zanim będzie w stanie ocenić treść. Szybsze nagłówki, lepsze teksty i silniejsze dane strukturalne nie pomogą treści, która nie jest niezawodnie pobierana.

P3 korzysta z kanonicznych hostów, zamierzonych szablonów indeksowalnych, priorytetowych ścieżek użytkownika, dowodów dotyczących kodów statusu i nierozwiązanych ustaleń infrastrukturalnych z podstawowego audytu technicznego . Taka kolejność zapobiega fałszywej diagnozie. Na przykład pięciosekundowe „ładowanie strony" spowodowane pętlą przekierowań nie jest zadaniem optymalizacji obrazów, a szybki test zbuforowanej strony błędu nie jest zaliczeniem. P2 ustala, że właściwy URL może być żądany i wybrany; P3 ustala, że może być dostarczony i używany w akceptowalnych granicach czasu i stabilności.

Przeprowadzenie tej fazy zbyt późno prowadzi do przeróbek. Zespół treści może publikować w szablonie, którego hero zawsze jest najwolnieszym elementem, albo zatwierdzić slot promocyjny, który przesuwa każdą kartę produktu. Wada mnoży się wtedy na nowych stronach.

Dane wejściowe i wyjściowe

Dane wejściowe czynią próbkę reprezentatywną. Dane wyjściowe stanowią umowę z następną fazą: dokładnie które strony są niezawodnie dostępne, które warunki pozostają słabe i które ograniczenia wydajnościowe muszą kwalifikować późniejsze pomiary.

Dane terenowe i dane laboratoryjne to różne rodzaje dowodów

Dane terenowe opisują to, czego rzeczywiście doświadczyli kwalifikujący się użytkownicy Chrome. Chrome User Experience Report, w skrócie CrUX, agreguje pomiary z rzeczywistych wizyt i raportuje 75. percentyl: wartość, przy lub poniżej której znajduje się 75% zarejestrowanych doświadczeń. Obejmuje złożoność prawdziwych urządzeń, sieci, lokalizacji, pamięci podręcznych, narzędzi zgody, sesji i interakcji. Używaj go, aby zdecydować, czy użytkownicy przechodzą przez opublikowane progi i czy wdrożona zmiana ostatecznie poprawiła doświadczenie populacji.

Dane laboratoryjne opisują jedno kontrolowane ładowanie strony lub interakcję w zadeklarowanych warunkach. Lighthouse to test laboratoryjny, który stosuje symulację urządzenia i sieci, rejestruje ślad i wyjaśnia prawdopodobne przyczyny. Używaj go, aby odtworzyć problem, porównać dwie wersje w tych samych warunkach, przeanalizować łańcuchy żądań i zidentyfikować pracę do wykonania. Wynik laboratoryjny jest użytecznym dowodem, ale nie dowodzi, że prawdziwi użytkownicy przechodzą test.

Oba źródła mogą być ze sobą w sprzeczności, nie oznacza to jednak, że któreś z nich jest błędne. Szybkie uruchomienie laboratoryjne może korzystać z pobliskiej lokalizacji, ciepłego CDN i bez znaczących interakcji, podczas gdy odwiedzający w terenie korzystają ze starszych telefonów i odległych sieci. Zanotuj rozbieżność i zbadaj jej warunki; nigdy nie uśredniaj wartości ani nie wybieraj tej, która wygląda zdrowiej.

Lista kontrolna

Wykonaj te czynności w podanej kolejności. Każda pozycja określa działanie, powód, metodę, narzędzie i warunek akceptacji, dzięki czemu może zostać przypisana i ponownie przetestowana.

1. Zamroź reprezentatywną macierz URL-i i warunków

Co: zdefiniuj URL-e, szablony, profile urządzeń, lokalizacje geograficzne, stany zgody i stany pamięci podręcznej do przetestowania. Dlaczego: audyt ograniczony do strony głównej może zakończyć się sukcesem, podczas gdy szablon produktu, artykułu lub kasy zawodzi. Jak: połącz spis P2 z danymi o ruchu i priorytetach biznesowych; wybierz typowe, ciężkie i krytyczne dla konwersji przykłady. Narzędzie: analityka, spis z indeksowania, rejestr wydań i wspólny arkusz testowy. Gotowe, gdy: każdy priorytetowy szablon ma zatwierdzoną przez właściciela próbkę produkcyjną, a każdy test odnotowuje założenia dotyczące urządzenia, sieci, lokalizacji, logowania, zgody i pamięci podręcznej.

2. Pobierz bazową ocenę CrUX w terenie

Co: zapisz dostępne metryki terenowe p75 na poziomie URL oraz oddzielnie na poziomie domeny. Dlaczego: domena może ukryć słaby szablon, podczas gdy pojedynczy URL o niskim ruchu może nie mieć publikowalnych danych. Jak: użyj tej samej daty obserwacji i 28-dniowego okna, wyraźnie oznacz URL vs domena i zapisz puste wartości jako „niewystarczające dane". Narzędzie: AmICited Web Vitals i CrUX. Gotowe, gdy: każdy próbkowany URL ma wartości LCP, INP, CLS, FCP i TTFB lub udokumentowany stan nieznany; poziom źródła i okno są jednoznaczne.

3. Zweryfikuj niezawodność odpowiedzi przed oceną pikseli

Co: powtórz żądania i zapisz status, przekierowania, Time to First Byte (TTFB), przekroczenia czasu i niespójne odpowiedzi. TTFB to odstęp od rozpoczęcia żądania do nadejścia pierwszego bajtu odpowiedzi. Dlaczego: strona nie może zacząć się renderować, zanim jej HTML zacznie docierać, a sporadyczna awaria jest poważniejsza niż kosmetyczne spowolnienie. Jak: przetestuj zachowanie zimnej i ciepłej pamięci podręcznej z odpowiednich regionów, sprawdź czas odpowiedzi serwera i skoreluj anomalie z logami CDN i serwera. Narzędzie: monitor żądań, panel sieciowy przeglądarki, obserwowalność CDN/serwera i wodospad Lighthouse. Gotowe, gdy: priorytetowe URL-e zwracają zamierzoną odpowiedź 200 bez nieoczekiwanych skoków lub przekroczeń czasu, a każda wolna lub nieudana odpowiedź ma zarejestrowane ustalenie z właścicielem.

4. Zdiagnozuj Largest Contentful Paint

Co: zidentyfikuj element Largest Contentful Paint (LCP) i podziel jego czas na opóźnienie serwera, odkrycie zasobu, pobranie zasobu i opóźnienie renderowania. LCP mierzy, kiedy największy widoczny obraz lub blok tekstu kończy renderowanie. Dlaczego: kompresja obrazu niewiele daje, gdy przeglądarka odkrywa go późno, a zmiany front-endowe nie mogą usunąć powolnej odpowiedzi serwera. Jak: przeanalizuj ślad i wodospad, porównaj uruchomienia z pamięcią podręczną i bez, sprawdź priorytet preload, responsywne rozmiary obrazów, blokujące renderowanie zasoby, zachowanie czcionek i renderowanie po stronie klienta. Narzędzie: Lighthouse, narzędzia wydajności przeglądarki, wodospad żądań i inspekcja obrazów. Gotowe, gdy: rzeczywisty element LCP i dominująca podczęść są nazwane dla każdego zawodzącego szablonu, z powtarzalnym pomiarem przed zmianą i konkretną hipotezą naprawy.

5. Zdiagnozuj Interaction to Next Paint

Co: przetestuj ścieżkę Interaction to Next Paint (INP) dla rzeczywistych działań, takich jak otwieranie menu, filtrowanie, dodawanie do koszyka, wprowadzanie danych w formularzu i odrzucanie zgody. INP mierzy opóźnienie od interakcji użytkownika do momentu, gdy przeglądarka wyświetli następną aktualizację wizualną, wykorzystując interakcję o wysokim opóźnieniu z wizyty. Dlaczego: strona może wydawać się gotowa, ale nadal ignorować użytkownika, gdy JavaScript zajmuje główny wątek. Jak: odtwórz ważne działania, przeanalizuj długie zadania i procedury obsługi zdarzeń, przetestuj skrypty stron trzecich i oddziel opóźnienie wejścia, czas przetwarzania i opóźnienie prezentacji. Narzędzie: CrUX, ślad wydajności przeglądarki, profilowanie interakcji i realistyczne urządzenie. Gotowe, gdy: każda ważna interakcja została przećwiczona, wolna interakcja i odpowiedzialne zadanie są zidentyfikowane dla zawodzących szablonów, a poprawka ma powtarzalny test interakcji.

6. Zdiagnozuj Cumulative Layout Shift

Co: zlokalizuj nieoczekiwane ruchy przyczyniające się do Cumulative Layout Shift (CLS). CLS to bezwymiarowy wynik reprezentujący nieoczekiwany ruch wizualny w trakcie życia strony. Dlaczego: późny baner, obraz bez rozmiaru, zamieniona czcionka, reklama lub hydratowany komponent mogą przesunąć link, który użytkownik ma zamiar kliknąć, i mogą zmienić miejsce, w którym zautomatyzowana ekstrakcja znajduje treść. Jak: użyj regionów przesunięcia układu i filmstrip, przetestuj opóźnione zasoby i stany zgody oraz sprawdź elementy bez zarezerwowanych wymiarów. Narzędzie: CrUX, ślad Lighthouse, narzędzia diagnostyczne renderowania przeglądarki i rejestracja regresji wizualnych. Gotowe, gdy: każde istotne przesunięcie ma źródłowy element, wyzwalacz i poprawkę dotyczącą zarezerwowanego miejsca lub renderowania; oczekiwany ruch spowodowany natychmiast przez działanie użytkownika jest udokumentowany oddzielnie.

7. Użyj FCP, aby oddzielić opóźnienie pustego ekranu

Co: zmierz First Contentful Paint (FCP), czas do momentu, gdy przeglądarka wyrenderuje pierwszą treść tekstową, obraz, canvas lub SVG. Dlaczego: FCP odróżnia wczesny sygnał postępu od strony, która pozostaje pusta, choć nie dowodzi, że główna treść jest gotowa. Jak: porównaj FCP z TTFB i LCP, następnie przeanalizuj blokujący CSS, czcionki, skrypty, znaczniki renderowane po stronie serwera i zachowanie streamingu. Narzędzie: CrUX, Lighthouse i ślad sieci/wydajności. Gotowe, gdy: każde wolne FCP jest przypisane do opóźnienia serwera, blokowania renderowania, renderowania tylko po stronie klienta lub innej udowodnionej przyczyny, a nie opisane jedynie jako „strona działa wolno".

8. Uszereguj ustalenia według powagi, zasięgu i zależności

Co: uporządkuj backlog według pasma awarii, dotkniętego ruchu i szablonów, krytyczności biznesowej i zależności upstream. Dlaczego: naprawa pięciu żółtych wyników może pochłonąć sprint, podczas gdy jedna czerwona awaria TTFB opóźnia każdą stronę na serwerze. Jak: umieść awarie niezawodnościowe na pierwszym miejscu, następnie słabe metryki przed metrykami wymagającymi poprawy; w obrębie tej samej powagi napraw wspólne przyczyny platformowe i TTFB przed downstreamowymi pracami nad LCP. Narzędzie: rejestr ustaleń, analityka, spis szablonów i estymata inżynieryjna. Gotowe, gdy: każde ustalenie ma określoną powagę, liczbę dotkniętych URL-i lub zakres szablonów, dowody, właściciela, nakład pracy, zależność i jawny priorytet.

9. Zweryfikuj implementację w laboratorium

Co: porównaj zmienioną wersję z zarejestrowaną bazą w identycznych warunkach. Dlaczego: dane terenowe nie mogą zapewnić natychmiastowej informacji zwrotnej o wydaniu, a niepowtarzalne uruchomienie „po" nie może dowieść, że zmiana kodu spowodowała różnicę. Jak: wykonaj wiele kontrolowanych próbek, porównuj mediany zamiast pojedynczego najlepszego uruchomienia, przeanalizuj ślad pod kątem regresji i przetestuj krytyczne interakcje i układy. Narzędzie: Lighthouse, narzędzia wydajności przeglądarki, staging lub kontrolowane wydanie produkcyjne oraz monitorowanie żądań. Gotowe, gdy: zamierzona przyczyna została usunięta, docelowa metryka przechodzi uzgodniony budżet laboratoryjny w powtarzalnych uruchomieniach, żadna inna krytyczna metryka nie ulega regresji, a dowody są dołączone do ustalenia.

10. Oznacz wydanie i czekaj na potwierdzenie w terenie

Co: zapisz czas wdrożenia, zakres, oczekiwaną metrykę i daty walidacji. Dlaczego: CrUX używa kroczącego okna 28-dniowego, więc wizyty sprzed wydania pozostają w raportowanym percentylu po wdrożeniu poprawki. Jak: monitoruj błędy natychmiast, sprawdzaj kierunkowe zmiany terenowe w miarę napływania nowych danych i dokonaj ostatecznego porównania dopiero, gdy wystarczająca liczba dni po wydaniu reprezentuje okno. Narzędzie: log wdrożeń, AmICited Web Vitals, CrUX i monitorowanie. Gotowe, gdy: natychmiastowe kontrole techniczne przechodzą, adnotacja wydania jest widoczna, a nazwany właściciel i data istnieją dla potwierdzenia terenowego; ustalenie nie jest oznaczane jako „zweryfikowane" wyłącznie na podstawie dowodów laboratoryjnych.

Narzędzia w AmICited

Otwórz https://app.amicited.com/audit/web-vitals, aby porównać swoją domenę ze śledzoną konkurencją przy użyciu rzeczywistych danych użytkowników CrUX. Audyt umieszcza LCP, INP, CLS, FCP i TTFB w jednej tabeli, oznacza twoją domenę i uwidacznia brakujące dane terenowe, zamiast zamieniać je w mylące zero. Użyj porównania, aby odpowiedzieć na dwa pytania: czy domena przechodzi przez opublikowane progi i czy konkurent obsługujący tę samą publiczność wykazał znacząco lepszy wynik terenowy.

Funkcja Performance Impact łączy wydajność na poziomie strony z pozycją cytowania i prawdopodobieństwem. Traktuj tę zależność jako dowód priorytetyzacji, a nie dowód na to, że sama szybkość spowodowała zmianę w cytowaniu. Jeśli wolna cytowana strona i szybka niecytowana różnią się autorytetem, trafnością lub treścią, wydajność jest tylko jedną ze zmiennych. Użytecznym sygnałem jest to, że dotknięta strona jest wystarczająco wartościowa, aby ją naprawić i monitorować.

Instrukcje obsługi produktu znajdziesz w Jak sprawdzić Core Web Vitals w AmICited . Ten podręcznik określa zakres audytu, decyzje i przekazanie; tutorial obejmuje kliknięcia i odczyty, więc powielanie go tutaj stworzyłoby dwie instrukcje, które mogą się rozjechać.

Zasady decyzyjne: jak wygląda słaby wynik

Oceniaj Core Web Vitals na podstawie danych terenowych w 75. percentylu. „Dobry" oznacza, że wartość p75 jest na lub poniżej granicy dobra. Wartość na granicy należy do lepszego pasma; na przykład LCP wynoszący dokładnie 2,5 sekundy jest dobry. Wspierające progi FCP i TTFB kierują diagnozą i akceptacją, ale nie są częścią trzy-metrycznej oceny zaliczenia Core Web Vitals.

| Metryka | Co reprezentuje | Dobry | Wymaga poprawy | Słaby | Domyślna odpowiedź | |—|—:|—:|—:|—:| | TTFB | Pierwszy bajt odpowiedzi; upstream każdego renderowania | ≤ 800 ms | > 800–1 800 ms | > 1 800 ms | Zbadaj serwer, pamięć podręczną, CDN, przekierowania i geografię przed pracami nad renderowaniem LCP. | | FCP | Pierwsza widoczna treść | ≤ 1,8 s | > 1,8–3,0 s | > 3,0 s | Usuń opóźnienie pustego ekranu i zidentyfikuj blokowanie renderowania lub dostarczanie tylko po stronie klienta. | | LCP | Główna widoczna treść wyrenderowana | ≤ 2,5 s | > 2,5–4,0 s | > 4,0 s | Podziel na TTFB, odkrycie, pobranie i opóźnienie renderowania; napraw dominującą część. | | INP | Responsywność interakcji użytkownika | ≤ 200 ms | > 200–500 ms | > 500 ms | Profiluj wolną interakcję i zmniejsz pracę głównego wątku lub renderowania. | | CLS | Nieoczekiwany ruch wizualny | ≤ 0,10 | > 0,10–0,25 | > 0,25 | Zarezerwuj miejsce i usuń późne przesunięcia szablonów; testuj przez całą wizytę. |

Stosuj następujące zasady priorytetyzacji:

1. Nieudane żądania, przekroczenia czasu i nieprawidłowe odpowiedzi są ważniejsze niż wyniki. Niezawodność jest bramką dostarczania.
2. Napraw słabe pasma przed pasmami wymagającymi poprawy. Czerwony to udowodnione złe doświadczenie, a nie okazja do szlifowania.
3. Napraw TTFB przed LCP, gdy TTFB jest słaby. LCP nie może wystąpić, zanim odpowiedź się nie rozpocznie, więc opóźnienie backendu konsumuje budżet LCP, zanim przeglądarka cokolwiek wyrenderuje.
4. Preferuj wspólne przyczyny nad izolowanymi objawami. Jedna naprawa polityki pamięci podręcznej w czterech szablonach ma wyższy priorytet niż cztery osobne poprawki obrazów o mniejszym zasięgu.
5. Uwzględniaj ruch i wartość ścieżki w obrębie tej samej powagi. Słaby INP w kasie lub LCP artykułu o wysokim ruchu ma wyższy priorytet niż niskotrafficzne archiwum w tym samym paśmie.
6. Nie nazywaj pustej wartości CrUX dobrą. Jest nieznana. Używaj powtarzalnych dowodów laboratoryjnych i porównywalnego szablonu, dopóki nie pojawi się wystarczający wolumen terenowy.
7. Nie obiecuj natychmiastowej zmiany terenowej. Zweryfikuj wdrożenie teraz, a następnie pozwól kroczącemu oknu zastąpić starsze doświadczenia, zanim zaakceptujesz lub odrzucisz wynik terenowy.

Efekt końcowy: rejestr naprawczy wydajności

Przekaż zespołowi inżynieryjnemu jeden rejestr wraz z folderem dowodów. Arkusz kalkulacyjny, tracker zgłoszeń lub ustrukturyzowana tabela projektu są akceptowalne, jeśli zachowują poniższe pola i umożliwiają filtrowanie według szablonu, powagi, właściciela i statusu:

ID i ustalenie:
Dotknięte URL-e i szablony:
Kontekst ścieżki priorytetowej i ruchu:
Metryka i pasmo terenowe:
Poziom CrUX, wartość p75 i 28-dniowe okno:
Konfiguracja laboratoryjna i powtórzona wartość bazowa:
Zaobserwowana przyczyna i odniesienie do dowodów:
Oczekiwany stan i cel:
Zalecana zmiana:
Powaga i uzasadnienie priorytetu:
Właściciel, zależność i nakład pracy:
Data wydania i adnotacja:
Natychmiastowy wynik akceptacji laboratoryjnej:
Data i wynik potwierdzenia terenowego:
Status: Otwarte | Zaplanowane | Zaakceptowane w laboratorium | Zweryfikowane w terenie | Zaakceptowane ryzyko

Dołącz macierz URL-i, eksport CrUX, ślady laboratoryjne, wodospady, filmstripy, nagrania interakcji, dowody przesunięć układu i adnotacje wydań. Dedyplikuj według przyczyny: jeśli to samo niezbuforowane zapytanie do serwera powoduje słaby TTFB w trzech szablonach, utwórz jedno nadrzędne ustalenie z trzema dotkniętymi zakresami, zamiast trzech konkurujących diagnoz.

„Zaakceptowane ryzyko" wymaga nazwanego zatwierdzającego, powodu, dotkniętego zakresu, daty wygaśnięcia lub przeglądu oraz warunku monitorowania. Nie zastępuje właściciela. Przekazanie jest zakończone, gdy inżynier może odtworzyć awarię, a właściciel następnej fazy może zidentyfikować, które wyniki pozostają ograniczone przez wydajność.

Co może pójść źle

Traktowanie Lighthouse jako werdyktu. Wynik 100 w jednym uruchomieniu laboratoryjnym nie unieważnia słabych danych terenowych p75. Traktuj Lighthouse jako dowód diagnostyczny, a CrUX jako dowód populacyjny.

Testowanie tylko strony głównej. Pobierz próbkę każdego wartościowego szablonu plus ciężki przykład, w przeciwnym razie wady szablonów umkną audytowi.

Optymalizacja obrazu LCP przed sprawdzeniem TTFB. Zasób może być mały, podczas gdy serwer spędza dwie sekundy na generowaniu HTML. Podziel LCP na komponenty i najpierw napraw czas upstream.

Używanie pojedynczego najszybszego uruchomienia. Ciepła pamięć podręczna, aktywność w tle i zmienność sieci mogą stworzyć pochlebny wynik odstający. Utrzymuj stałą konfigurację i porównuj mediany z powtarzanych uruchomień.

Ogłaszanie zwycięstwa dzień po wydaniu. Laboratorium może udowodnić, że kod i dostarczanie zmieniły się natychmiast; 28-dniowe okno terenowe nie może. Oznacz wydanie i zaplanuj akceptację terenową.

Oznaczanie brakujących danych CrUX jako zero. Brak danych oznacza, że próg kwalifikowalności lub ruchu nie został osiągnięty. Nie mówi nic o jakości wydajności.

Gonienie za złożonym wynikiem zamiast za zawodzącym doświadczeniem. Zbiorczy wynik może się poprawić, podczas gdy interakcja w kasie wciąż się zacina lub hero wciąż się przesuwa. Akceptuj nazwane metryki i ścieżki, a nie kosmetyczną zmianę wyniku.

Usuwanie użytecznej funkcjonalności, aby wygrać test. Usunięcie zgody, personalizacji, analityki lub zachowania dostępności z wariantu laboratoryjnego daje wynik, którego użytkownicy nigdy nie otrzymują. Optymalizuj wymagania produkcyjne lub podejmij jawną decyzję produktową.

Ignorowanie regresji poza docelową metryką. Odłożenie skryptów może poprawić LCP, ale stworzyć słaby INP przy pierwszej interakcji; zarezerwowanie niewłaściwych wymiarów może zastąpić opóźnienie ładowania CLS. Przetestuj ponownie wszystkie pięć metryk i krytyczną ścieżkę użytkownika.

Następna faza: dostępność AI i gotowość dla agentów

Faza Dostępność AI i gotowość dla agentów otrzymuje reprezentatywną macierz URL-i, dowody niezawodności odpowiedzi, rozkład TTFB, nierozwiązane ustalenia wydajnościowe oraz informację, która treść jest obecna w początkowej odpowiedzi. Jej właściciel używa tych dowodów, aby odróżnić awarię polityki dostępu od awarii dostarczania i odtworzyć rzeczywiste warunki, w których agent pobiera stronę.

Następna faza może być kontynuowana, gdy krytyczne URL-e reagują niezawodnie, a żadne nierozwiązane ustalenie wydajnościowe nie czyni dowodów pobierania nieinterpretowalnymi. Może być kontynuowana z pisemnym ograniczeniem, gdy metryka wymagająca poprawy wpływa na użytkowników, ale nie uniemożliwia stabilnego dostępu. Powinna zostać wstrzymana dla dotkniętych szablonów, gdy żądania przekraczają czas, zwracają sporadyczne błędy lub główna odpowiedź regularnie przekracza uzgodniony próg krytyczny.

Przekazanie jest zakończone, gdy następny właściciel wie, które URL-e reprezentują każdy szablon, jakie są warunki testowe, jakie pozostały awarie dostarczania i czy dowody z P3 już wyjaśniają wolne pobieranie przez agenta.

FAQ

Najczęściej zadawane pytania