Najszybszy hosting: jak porównać TTFB, cache i działanie strony pod obciążeniem?

Najszybszy hosting dla konkretnej strony można wskazać dopiero po porównywalnym pomiarze kupowanych pakietów. Ta sama aplikacja, podobne warunki sieciowe, jawny stan cache i sprawdzenie rzeczywistych czynności są ważniejsze niż pojedynczy zielony wynik. Szybka strona operatora ani najwyższy wynik jednego testu nie dowodzą, że Twój sklep będzie tak samo działał.

WebBay przedstawia siedem zasad porównania oraz arkusz do własnych odczytów. Dokumentacje zweryfikowaliśmy 28.10.2026. Nie wykonaliśmy w tym materiale benchmarku firm i nie przyznajemy zwycięzcy. Najpierw wybierz oferty o zakresie odpowiednim do porównania.

Jeżeli masz już działającą witrynę i szukasz przyczyny problemu, zacznij od diagnozy wolnego WordPressa. Tutaj celem jest przygotowanie uczciwej próby kilku środowisk przed decyzją zakupową. Nie uruchamiaj obciążenia na cudzych usługach bez odpowiedniej zgody.

Plan porównania ofert

• Ustal pakiet i zakres wniosku
• Przygotuj porównywalną instalację
• Zapisz warunki, lokalizację i narzędzie
• Rozdziel TTFB od użyteczności strony
• Rozpisz osobne scenariusze cache
• Uzgodnij test operacji i obciążenia
• Oceń serię wyników razem z błędami

Przykład uczciwego porównania dwóch środowisk

Przygotuj tę samą kopię strony na obu środowiskach i uzgodnij dozwolony zakres prób. Dla jednej podstrony wykonaj po pięć spokojnych odczytów w tych samych warunkach, osobno z rozgrzanym cache i osobno dla potrzebnej funkcji dynamicznej. Zapisz wszystkie czasy zamiast wybierać najlepszy zrzut. Porównaj typowy wynik i rozrzut, a następnie sprawdź poprawność formularza lub zamówienia. Są to założenia przykładu; nie przedstawiają pomiarów konkretnych operatorów.

1. Najszybszy hosting: najpierw określ, co porównujesz

Zapisz nazwę pakietu, okres rozliczenia, cenę zakupu i odnowienia oraz wymagane dodatki. Dołącz informację o przydziale zasobów i funkcjach, które będą wykorzystywane w próbie. Wynik konkretnego planu nie jest automatycznie oceną wszystkich usług danej marki. Podstawowy hosting i zarządzany serwer o innym budżecie odpowiadają na różne potrzeby.

Rozdziel dwie możliwe metody. Pierwsza porównuje możliwie podobne środowisko techniczne. Druga ocenia gotową usługę wraz z jej zalecaną konfiguracją, cache i wsparciem. Obie mogą być użyteczne, ale nie wolno mieszać ich bez opisu. Jeśli jeden pakiet ma dodatkową usługę, zaznacz jej koszt i wpływ na zakres porównania.

Nie testuj wyłącznie strony głównej operatora. Może korzystać z innej infrastruktury, własnych optymalizacji lub sieci dystrybucji niż kupowany produkt. Potrzebujesz swojej kontrolowanej instalacji na właściwym pakiecie albo rzetelnych danych dokładnie opisujących takie środowisko. Bez tego wynik jest informacją o badanym adresie, a nie dowodem możliwości dowolnego klienta.

Przed zakupem próby sprawdź zasady rozliczenia i dopuszczalne użycie. Nie zakładaj bezpłatnego zwrotu ani prawa do dowolnego generowania ruchu. Ustal, co wolno uruchomić, jak długo, z jakiej lokalizacji i kto odbierze zgłoszenie w razie problemu. Sam dostęp do panelu nie oznacza zgody na test przeciążenia współdzielonej infrastruktury.

2. Ta sama aplikacja i te same dane testowe

Przygotuj kopię tej samej wersji WordPressa, motywu i rozszerzeń. Zachowaj porównywalną zawartość, obrazy oraz ustawienia istotne dla scenariusza. Zapisz wersję PHP i bazy oraz włączone dodatki serwerowe. Jeśli nie da się uzyskać identycznego środowiska, nie ukrywaj różnicy: jest ograniczeniem porównania i możliwym powodem wyniku.

Wybierz kilka reprezentatywnych adresów: zwykły artykuł, cięższą podstronę i operację dynamiczną. Lista powinna wynikać z funkcji witryny. Test samej pustej instalacji nie rozstrzyga zachowania katalogu produktów z dodatkami. Z kolei kopiowanie ogromnej bazy bez anonimizacji może niepotrzebnie ujawnić dane klientów i utrudnić kontrolę próby.

Środowisko testowe przygotuj tak, aby nie wysyłało przypadkowych wiadomości ani nie realizowało prawdziwych zamówień. Ustal, które integracje są zastąpione trybem testowym. Jeżeli usunięcie integracji istotnie zmienia obciążenie, odnotuj to i ogranicz wniosek. Nie przedstawiaj wyniku uproszczonego sklepu jako pomiaru pełnego procesu sprzedaży.

Zachowaj kopię konfiguracji i opis odtworzenia. Nie przełączaj publicznej domeny między serwerami tylko po to, by wykonać odczyt. Korzystaj z uzgodnionego sposobu dostępu do próbnych środowisk. Przy zmianie domeny sprawdź, czy nie zmieniły się zasoby, przekierowania i połączenia zewnętrzne, które zaburzą porównywalność.

3. Lokalizacja, urządzenie i wersja narzędzia

Każdy odczyt opisuj datą, strefą czasową, lokalizacją pomiaru, urządzeniem, przeglądarką i wersją narzędzia. Zachowaj tę samą konfigurację sieci lub emulowanego ograniczenia. Jeśli porównujesz różne kraje, prowadź dla nich osobne serie. Średnia łącząca odmienne lokalizacje może ukryć problem najważniejszej grupy odbiorców.

Nie porównuj szybkiego komputera bez dodatków z obciążonym laptopem i aktywnymi rozszerzeniami. Dokumentacja Lighthouse wymienia warunki urządzenia, sieci i dodatkowego oprogramowania jako źródła zmienności. Zamiast wybierać jeden najładniejszy raport, zachowaj całą uzgodnioną serię oraz opis odstępstw. [3]

Ustal kolejność prób tak, aby jedna oferta nie była zawsze badana o innej porze. Możesz przeplatać odczyty A i B, zachowując podobne warunki. To propozycja organizacji pracy, a nie gwarancja usunięcia wszystkich zakłóceń. Jeśli w trakcie zmienił się kod, cache albo zewnętrzna integracja, oznacz serię jako nieporównywalną i wyjaśnij przyczynę.

Zapisuj surowe raporty, ale przed ich udostępnieniem sprawdzaj prywatne parametry, nagłówki i dane sesji. W publicznym opracowaniu pokazuj tylko potrzebne, bezpieczne informacje. Czytelnik powinien móc zrozumieć metodę bez dostępu do haseł, kopii danych klientów lub prywatnych adresów administracyjnych.

4. TTFB, renderowanie i działająca funkcja to różne rzeczy

TTFB opisuje czas od początku nawigacji do otrzymania pierwszego bajtu. Dla nawigacji obejmuje między innymi przekierowania, DNS, zestawienie połączenia i oczekiwanie na odpowiedź. Nie jest czystym czasem wykonania PHP i nie należy do Core Web Vitals. Porównanie wymaga znajomości definicji używanej przez narzędzie. [1]

Dokumentacja zwraca uwagę na odpowiedzi 103 Early Hints i różnice pomiaru początku odpowiedzi. Dlatego zapisz wersję narzędzia oraz sposób wyznaczania metryki. Nie porównuj bez komentarza wartości pochodzącej z pierwszej odpowiedzi informacyjnej z czasem rozpoczęcia końcowego dokumentu. Bardzo mała liczba nie dowodzi jeszcze, że użytkownik szybko zobaczył zawartość.

Aktualny zestaw Core Web Vitals obejmuje LCP, INP i CLS. Dane od użytkowników i warunki laboratoryjne mają różne zastosowanie. Zwykły przebieg Lighthouse bez wejścia użytkownika nie mierzy INP; laboratoryjny TBT może pomagać w diagnozie, lecz nie jest tym samym wskaźnikiem. Nie nazywaj jednego raportu testem wszystkich rzeczywistych odbiorców. [2]

Jeżeli potrzebujesz ofert spełniających określone wymaganie techniczne, porównaj zakres pakietów i koszty testowanej konfiguracji. Punktacja narzędzia nie zastępuje budżetu, zakresu administracji i prawidłowego działania aplikacji. Kryteria zakupowe rozwija lista pytań przed zakupem hostingu WordPress.

5. Osobne serie dla cache i stron dynamicznych

Rozpisz stan cache przed próbą. Gotowa odpowiedź artykułu może ominąć część pracy aplikacji, podczas gdy zalogowanie i koszyk wymagają danych użytkownika. Wynik HIT i MISS nie powinien trafiać do jednej nieopisanej średniej. Jeśli celem jest gotowa usługa z cache, pokaż jej przewagę w tym scenariuszu oraz ograniczenia innych operacji.

W LSCache rozpoznaj rzeczywiste nagłówki głównego dokumentu, a nie tylko nazwę wtyczki. Dokumentacja wskazuje między innymi X-LiteSpeed-Cache, a przy innych warstwach odpowiednie warianty ADC lub QUIC.cloud. Zapisz widoczny stan odpowiedzi. Brak nagłówka LiteSpeed nie dowodzi braku każdego możliwego rozwiązania cache na innym serwerze. [5]

Oddziel też cache przeglądarki od serwera. Opcja Disable cache w Chrome dotyczy pamięci przeglądarki; nie jest dowodem wyłączenia cache na serwerze. Zapisz obie warstwy w arkuszu. Test pierwszej wizyty i powrotnego wejścia może być użyteczny, o ile dla porównywanych ofert stosujesz tę samą procedurę. [4]

Nie czyść wszystkich kopii w działającym sklepie przed każdą próbą i nie wymuszaj zapisu spersonalizowanych treści w publicznym cache. Test ma zachować poprawność i bezpieczeństwo funkcji. Jeżeli konfiguracja wymaga zmiany, wykonuj ją na uzgodnionym środowisku, z planem powrotu oraz kontrolą menu, formularzy i właściwego wariantu odpowiedzi.

Trzy karty scenariusza przed uruchomieniem narzędzia

Publiczny artykuł: wybierz tę samą treść z identycznymi obrazami i zapisz wariant niezalogowanego gościa. Oddziel wejście bez gotowej odpowiedzi serwera od kolejnego odczytu potwierdzonego nagłówkiem. W obu środowiskach sprawdź także, czy użytkownik rzeczywiście otrzymuje pełny tekst i działające menu. Sam krótki dokument lub komunikat blokady nie jest sukcesem wydajności.

Wyszukiwanie albo filtr: wybierz to samo zapytanie i zestaw danych, a następnie sprawdź zawartość odpowiedzi. Nie zestawiaj wyszukania jednej pozycji z filtrem przeglądającym zupełnie inny katalog. Zapisz, czy wynik jest gotową kopią, czy wymaga wykonania zapytań do bazy. Jeśli mechanizm korzysta z zewnętrznego serwisu, zaznacz jego udział w czasie i granicę wniosku o hostingu.

Operacja zalogowanego użytkownika: przygotuj kontrolowane konto testowe i tę samą czynność, na przykład zapis roboczej treści. Nie używaj prywatnego konta klienta ani prawdziwych danych płatniczych. Sprawdź zarówno odpowiedź przeglądarki, jak i oczekiwany skutek operacji. Szybki komunikat nie dowodzi, że dane zostały poprawnie zapisane. Późniejszy odczyt powinien potwierdzić wynik bez tworzenia niepotrzebnych publicznych zmian.

Te karty nie narzucają jednej liczby żądań każdej witrynie. Pomagają opisać, co jest porównywane, zanim powstanie tabela wyników. Jeśli aplikacja nie ma wyszukiwarki albo logowania, wybierz inną rzeczywistą funkcję zamiast dodawać ją wyłącznie dla testu. Wspólna metoda ma służyć Twojemu zastosowaniu, nie sztucznie ujednoliconemu konkursowi operatorów.

6. Obciążenie tylko w uzgodnionym zakresie

Najpierw odbierz zwykłe działanie strony. Następnie uzgodnij z operatorem i opiekunem środowiska dopuszczalny scenariusz obciążenia. Określ adresy, rodzaj operacji, czas, źródło ruchu i warunki przerwania. Nie uruchamiaj dowolnej liczby żądań na współdzielonym planie tylko dlatego, że narzędzie pozwala wpisać dużą liczbę.

Przykład: krótka próba dokumentu HTML w k6 na Windows

Ten wariant służy własnej, odizolowanej stronie testowej. Najpierw uzgodnij także parametry przykładu: najwyżej dwa wirtualne wykonania naraz, 30 sekund rozpoczynania kolejnych iteracji i do 6 sekund na zakończenie rozpoczętej pracy. Nie jest to zalecany limit dla każdej usługi. Wybierz publiczny dokument bez logowania i skutków takich jak płatność lub wysyłka wiadomości.

1. W PowerShell zainstaluj narzędzie poleceniem poniżej. Otwórz terminal ponownie i wpisz k6 version. Jeśli polecenie nadal nie istnieje, sprawdź instalację i ścieżkę programu; nie przechodź do próby.

winget install k6 --source winget

2. W edytorze tekstu zapisz poniższy plik jako pomiar.js w UTF-8, bez końcówki .txt. Zastąp FRAGMENT_TEKSTU krótkim, stałym fragmentem rzeczywiście obecnym w HTML obu porównywanych stron. Otwórz PowerShell w folderze tego pliku.

import http from 'k6/http';
import { check, sleep } from 'k6';

export default function () {
  const r = http.get(__ENV.TARGET_URL, { timeout: '5s', redirects: 0 });
  check(r, {
    'HTTP 200': (v) => v.status === 200,
    'oczekiwana tresc': (v) => typeof v.body === 'string' && v.body.includes('FRAGMENT_TEKSTU')
  });
  sleep(1);
}

3. W poleceniu zastąp przykładowy adres adresem uzgodnionej kopii. Najpierw wykonaj tylko jedno żądanie. Obie kontrole powinny się udać. Skrypt czeka najwyżej 5 sekund na odpowiedź i nie podąża za przekierowaniami. Przy błędzie sprawdź docelowy URL, odpowiedź i fragment tekstu; przerwij przy blokadzie lub błędzie aplikacji zamiast zwiększać ruch. Timeout zapisz jako przekroczenie przyjętego czasu, a nie pomiar pełnego czasu odpowiedzi.

k6 run --vus 1 --iterations 1 -e TARGET_URL=https://stage.example.com/poradnik/ pomiar.js

4. Dopiero po poprawnej próbie i uzgodnieniu zakresu uruchom krótki przebieg poniżej. W razie błędów albo pogorszenia działania przerwij go przez Ctrl+C i zapisz moment zdarzenia. Nieudana kontrola check sama nie zatrzymuje k6. Każde wirtualne wykonanie czeka sekundę po odpowiedzi; dwa VU nie oznaczają stałych dwóch żądań na sekundę.

k6 run --vus 2 --duration 30s -e TARGET_URL=https://stage.example.com/poradnik/ pomiar.js

5. Zachowaj podsumowanie: liczbę żądań, błędy http_req_failed, powodzenie kontroli treści oraz medianę i p95 http_req_duration. Powtórz uzgodnione serie dla B z tym samym plikiem, lokalizacją i opisanym stanem cache. Czas ten obejmuje wysłanie, oczekiwanie i pobranie odpowiedzi, bez początkowego DNS i zestawiania połączenia. Skrypt pobiera HTML, nie obrazy i skrypty strony; nie mierzy LCP, INP ani całego zakupu. Tak krótka próba nie wyznacza maksymalnej liczby klientów.

Rozróżnij liczbę równoczesnych żądań, tempo rozpoczęcia operacji i liczbę zakończonych zadań. Nie przeliczaj ich automatycznie na dzienną liczbę klientów. Odwiedzający może wykonać wiele działań, a poszczególne strony mają różny koszt. Sama liczba kontenerów testowych lub wątków programu nie opisuje rzeczywistego ruchu sklepu.

Scenariusz powinien sprawdzać odpowiedź funkcjonalną, nie tylko kod HTTP. Dokument błędu może zwrócić poprawny technicznie status, a szybki pusty koszyk nie oznacza udanego zamówienia. Ustal kontrolę oczekiwanego wyniku bez wykonywania prawdziwych płatności i przypadkowej wysyłki powiadomień do klientów. Zakres testowy musi być oddzielony od zwykłej sprzedaży.

Obok czasu zapisuj liczbę prób, błędów i przerwanych operacji. Sprawdź także, co dzieje się po zakończeniu próby: czy aplikacja wraca do normalnego działania i czy nie pozostawiła zadań do wykonania. Jeśli narzędzie samo osiągnęło limit, wynik nie rozstrzyga możliwości serwera. Udokumentuj ten problem zamiast przypisywać go operatorowi.

Dla sklepu uwzględnij osobno wyszukiwanie, koszyk i pracę panelu. Zakres wymagań aplikacji przedstawia poradnik hostingu WooCommerce. Przy ocenie zasobów porównuj operacje, które rzeczywiście będą wykonywane; nie zakładaj, że wynik buforowanego artykułu przewiduje pracę importu lub płatności.

7. Seria wyników zamiast najlepszego zrzutu

Przed rozpoczęciem ustal liczbę powtórzeń i sposób podsumowania. Jako prosty przykład obliczeniowy weź pięć wymyślonych wartości: 100, 110, 120, 130 i 1000 ms. Mediana wynosi 120 ms, a średnia 292 ms. To nie pomiary hostingu: przykład pokazuje, że pojedyncza liczba może ukryć zupełnie inny obraz zmienności.

Nie odrzucaj wolnego odczytu bez powodu. Zapisz, czy to błąd narzędzia, zmiana warunków czy rzeczywista obserwacja. Jeżeli znasz przyczynę wyłączenia próbki, udokumentuj ją. Nie usuwaj niewygodnych wyników tylko dlatego, że zmieniają kolejność ofert. Przy małej próbie unikaj precyzyjnie brzmiących wniosków o wszystkich użytkownikach i całym miesiącu.

Nie nagradzaj szybkości wynikającej z błędów. Oferta, która kończy mniej poprawnych operacji, może pokazać krótki czas odpowiedzi dlatego, że odrzuca pracę. Czytaj razem czas, poprawność i liczbę zakończonych zadań. Podsumowanie powinno wskazywać scenariusz oraz ograniczenia, a nie jedną bezwarunkową etykietę dla całej marki.

Reguły decyzji ustal przed obejrzeniem wyników

Określ, które funkcje muszą działać poprawnie i co oznacza przerwanie próby. Rozdziel wymaganie bezwzględne od preferencji: niedziałający zapis danych jest innym problemem niż niewielka różnica czasu artykułu. Nie zmieniaj tych zasad po zobaczeniu ulubionej oferty. Dzięki temu tabela pozostaje narzędziem decyzji, a nie uzasadnieniem wcześniej wybranego dostawcy.

Gdy oferta A lepiej obsługuje gotowy artykuł, a B sprawniej wykonuje ważną operację dynamiczną, nie ma obowiązku sprowadzenia ich do jednej gwiazdki. Opisz dwa wyniki i wybierz scenariusz odpowiadający stronie. To przykład sposobu rozumowania, bez przypisanych wartości i bez twierdzenia, że konkretna firma uzyskała taki rezultat. Ujawnienie różnicy bywa bardziej użyteczne niż sztuczna kolejność.

Jeżeli różnice mieszczą się w widocznej zmienności serii, zapisz brak rozstrzygnięcia. Możesz wtedy oprzeć zakup na cenie odnowienia, zakresie wsparcia lub prostocie utrzymania. Nie dopisuj kolejnych miejsc po przecinku, aby stworzyć pozorną przewagę. Dokładność prezentacji powinna odpowiadać metodzie, a nie możliwości formatowania arkusza.

Po wyborze wykonaj odbiór na rzeczywistym środowisku docelowym. Sprawdź przekierowania, certyfikat, obrazy, logowanie oraz czynności, które były podstawą porównania. Uzgodnij także sposób powrotu przy istotnym problemie. Próba przed zakupem ogranicza niepewność, lecz nie zastępuje kontroli po przeniesieniu i nie gwarantuje zachowania strony po przyszłych aktualizacjach.

Arkusz do uzupełnienia rzeczywistymi odczytami

Wypełnij arkusz odczytami po uzgodnionej próbie i zachowaj źródłowe raporty. Wynik z jednego dnia nie gwarantuje przyszłej szybkości. Powtórna kontrola po wdrożeniu jest potrzebna, zwłaszcza gdy zmieni się zawartość, wersja aplikacji lub sposób korzystania ze strony.

Gdy wynik zależy od dodatkowej warstwy

Jeżeli jedno środowisko używa CDN, a drugie odpowiada bez niego, zdecyduj, czy porównujesz kompletne usługi, czy samą warstwę hostingu. W pierwszym wariancie pokaż zależność od CDN i ewentualną opłatę. W drugim zaplanuj uzgodnioną porównywalną konfigurację. Nie usuwaj tej informacji z opisu tylko dlatego, że dodatkowa warstwa jest domyślnie włączona w jednej ofercie.

Zwróć uwagę na docelowe adresy po przekierowaniu. Jeśli wariant A otwiera stronę bezpośrednio, a B przechodzi przez kilka przekierowań, część różnicy dotyczy ścieżki żądania. Możesz oddzielnie ocenić tę konfigurację i poprawić ją przed właściwą próbą, ale zapisz zmianę. Nie przypisuj całego czasu różnicy mocy CPU, gdy porównywane żądania pokonują inne etapy.

Podobnie odczyt z nieaktualnej kopii cache nie stanowi pełnego sukcesu. Obok szybkości sprawdź świeżość treści i poprawność wariantu użytkownika. Usługa powinna dostarczyć właściwą odpowiedź, a nie jedynie najszybciej zwrócić dowolny dokument. Zachowaj ten warunek również przy podsumowaniu wyników.

Jak wybrać po zakończeniu próby?

Najpierw odrzuć nieporównywalne dane i rozwiąż krytyczne błędy. Następnie porównaj scenariusze najważniejsze dla swojej witryny oraz pełny koszt utrzymania. Różnica ma znaczenie, gdy dotyczy rzeczywistej czynności użytkownika i jest widoczna w powtarzalnych warunkach. Minimalna przewaga jednego odczytu nie zastępuje stabilności, wsparcia i planu odtworzenia.

Jeżeli nie możesz przeprowadzić własnych prób, sprawdzaj jawność metod cudzych opracowań: konkretny pakiet, wersje, datę, cache, lokalizację i błędy. Brak tych informacji ogranicza użyteczność wyniku. Nie przypisuj sobie cudzych pomiarów i nie przedstawiaj reklamowego hasła jako dowodu. Możesz uczciwie wybrać ofertę na podstawie zakresu i kosztu bez ogłaszania rekordu szybkości.

Najszybszy hosting w Twoim scenariuszu powinien także mieścić się w budżecie i mieć potrzebną obsługę. Po określeniu warunków zestaw wyniki swojej próby z parametrami i odnowieniem ofert. Decyzję zapisz wraz z datą, ograniczeniami i planem odbioru po przeniesieniu. Bez porównywalnych odczytów nie ma podstaw do wskazania zwycięzcy szybkości.

Pytania przed porównaniem

Czy 100 punktów Lighthouse oznacza najlepszy serwer?

Nie. To ocena badanego widoku w określonych warunkach. Może się zmieniać wraz z urządzeniem, siecią i kodem strony. Nie opisuje samodzielnie działania panelu, koszyka ani wszystkich obciążeń. Zachowaj raport i jego warunki zamiast traktować samą liczbę jako certyfikat hostingu.

Czy test cache i brak cache można połączyć?

Można pokazać oba scenariusze w jednym opracowaniu, ale ich wyniki trzeba opisać oddzielnie. Wspólna nieopisana średnia ukrywa różne ścieżki obsługi. Najpierw określ, jaki udział mają te operacje w Twoim zastosowaniu i czy porównanie zachowuje poprawność aplikacji.

Źródła i data weryfikacji

Oficjalne dokumentacje sprawdzono 29.10.2026. Protokół, arkusz, kod przykładowej próby i przykład średniej oraz mediany są opracowaniem instruktażowym; nie przedstawiamy ich jako wykonanych pomiarów szybkości operatorów.

1. [1] web.dev — zakres TTFB i znaczenie Early Hints.
2. [2] web.dev — Core Web Vitals, dane laboratoryjne i dane użytkowników.
3. [3] Chrome — zmienność i znaczenie punktacji Lighthouse.
4. [4] Chrome DevTools — warunki sieci i cache przeglądarki.
5. [5] LiteSpeed — odczyt rzeczywistego stanu cache strony.
6. Grafana k6 — instalacja na Windows.
7. Grafana k6 — uruchamianie skryptu.
8. Grafana k6 — kontrola poprawności odpowiedzi.
9. Grafana k6 — znaczenie metryk HTTP.
10. Grafana k6 — przekazanie adresu przez parametr.
11. Grafana k6 — czas, iteracje i liczba VU.
12. Grafana k6 — timeout i przekierowania HTTP.
13. Grafana k6 — zakończenie rozpoczętych iteracji.