Co to za serwer i po co on komu
MCP (Model Context Protocol) to otwarty protokół, przez który asystent AI wywołuje zewnętrzne narzędzia; pisałem o nim szerzej we wpisie o podłączeniu Search Console. Tu liczy się jedno: serwer MCP to program-pośrednik na Twoim komputerze. Z jednej strony rozmawia z asystentem, z drugiej — odpytuje API Google PageSpeed Insights, czyli ten sam silnik Lighthouse, który stoi za raportem na stronie usługi. Claude sam prosi o pomiar, dostaje liczby i je analizuje, a mnie zostaje zadawanie pytań zwykłymi słowami.
Przy okazji serwer potrafi to, czego nie ma w wersji przeglądarkowej: porównać dwie podstrony, sprawdzić do dziesięciu adresów naraz, zapamiętać pomiar bazowy i zestawić z nim nowy.
Jaki serwer wybrałem i co sprawdziłem przed instalacją
Wybrałem pagespeed-insights-mcp — pakiet npm napisany w TypeScripcie, wersja 2.1.0. Zdecydowały trzy rzeczy:
- Sześć zrozumiałych narzędzi zamiast rozsypanki. Analiza strony, diagnostyka w jednym „przekroju”, dane prawdziwych użytkowników, porównanie, sprawdzanie wielu adresów i czyszczenie pamięci podręcznej. Nic zbędnego.
- Gotowe raporty pod zadanie. Zamiast surowej odpowiedzi Google na 850 KB — podsumowanie, lista poprawek według ważności albo rozbiór zasobów blokujących wyświetlanie. Modelowi łatwiej, a tokenów schodzi mniej.
- Krótki, czytelny kod. Da się go przejrzeć w jeden wieczór, zamiast zgadywać, co robi cudzy program.
Kod przeczytałem w całości przed instalacją — to mój nawyk przy każdym serwerze MCP. Licencja Apache-2.0. Sieć: tylko dwa adresy Google — usługa PageSpeed Insights i Chrome UX Report. Klucz API jest wycinany z logów i komunikatów o błędach, ponowne próby idą ze wzrastającą przerwą, równoległych zapytań jest najwyżej trzy, a odpowiedzi trafiają do pamięci podręcznej na godzinę. Dlaczego takie sprawdzanie to nie formalność, opisywałem we wpisie o bezpieczeństwie narzędzi AI.
Krok 1. Klucz Google: osobny i z ograniczeniami
Usługa jest bezpłatna, ale bez klucza nie ruszy: wspólny anonimowy limit jest wyczerpany i już pierwsze zapytanie zwróciło błąd 429 — przekroczono limit zapytań. Potrzebny jest klucz API z projektu Google Cloud.
- W projekcie Google Cloud włączyć PageSpeed Insights API. Projekt już miałem — ten sam, co dla Google Analytics i Search Console — i ten interfejs był w nim włączony.
- W sekcji „Dane logowania” utworzyć klucz API i nadać mu czytelną nazwę.
- W ograniczeniach klucza wybrać „Ogranicz klucz” i zaznaczyć potrzebne interfejsy — zamiast zostawiać „Nie ograniczaj”.
Istniejących kluczy projektu nie rozszerzałem: każdy ma swoje zadanie, a klucz od indeksowania nie powinien umieć zaglądać do pomiarów szybkości. Osobny klucz to też osobne unieważnienie: gdy coś pójdzie nie tak, wyłączasz jeden klucz, zamiast dochodzić, które usługi od niego zależą. Ograniczenia po adresie IP ani stronie nie ustawiałem — serwer działa na moim komputerze ze zmiennym adresem.
Pułapka, która kosztowała mnie dodatkowe podejście: interfejs Chrome UX Report API — ten, który daje dane prawdziwych odwiedzających — jest w projekcie domyślnie wyłączony, nawet gdy PageSpeed już działa. Dopóki go nie włączysz i nie dodasz do ograniczeń klucza, narzędzie danych prawdziwych użytkowników odpowiada błędem 403 z przyczyną API_KEY_SERVICE_BLOCKED. Sprawdzenie tego bezpośrednim zapytaniem do interfejsu jest pewniejsze niż zgadywanie z komunikatu serwera.
Krok 2. Instalacja
Potrzebny jest Node.js w wersji 20.19 lub nowszej. Sprawdzamy:
node --version
Instalujemy pakiet globalnie:
npm install -g pagespeed-insights-mcp
Instalacja zajęła około 20 sekund i 127 pakietów zależności. W wierszu poleceń pojawił się program pagespeed-insights-mcp — to właśnie serwer. Nie trzeba go uruchamiać ręcznie: startuje go sam Claude.
Krok 3. Rejestracja w Claude Code
Klucz przekazujemy przez zmienną środowiskową. W PowerShellu:
$k = "twój_klucz_Google"
claude mcp add `
pagespeed-insights -s user `
-e "GOOGLE_API_KEY=$k" `
-e NODE_ENV=production `
-- pagespeed-insights-mcp
Flaga -s user zapisuje wpis w konfiguracji użytkownika, a nie w pliku projektu: folder projektu synchronizuje się z chmurą i klucz nie ma tam czego szukać. NODE_ENV=production przełącza logi z kolorowego tekstu na zwarty JSON — łatwiej je analizować, gdy coś pójdzie nie tak. Sprawdzamy:
claude mcp list
Przy pagespeed-insights pojawiło się „Connected”. Dalej znana z Search Console historia: w już otwartej sesji nowych narzędzi nie ma, lista wczytuje się przy starcie. Poza tym „Connected” oznacza tylko, że proces wystartował i odpowiedział na uścisk dłoni — a nie że klucz działa i interfejs jest włączony. Dlatego najpierw sprawdziłem klucz zwykłym zapytaniem do interfejsu PageSpeed: odpowiedź 200 i pełny raport strony głównej. Dopiero potem otworzyłem nową sesję.
Sześć narzędzi po ludzku
- Analiza strony. Pełne badanie Lighthouse: oceny szybkości, dostępności, SEO i dobrych praktyk. Można poprosić o podsumowanie, pełny rozbiór albo listę poprawek według priorytetu.
- Diagnostyka. Jeden „przekrój” do wyboru: zasoby blokujące, obrazy, skrypty, usługi zewnętrzne, sieć, wczesne ładowanie widoku, elementy strony.
- Dane prawdziwych użytkowników. Wskaźniki z raportu Chrome UX Report — to, co widzą żywi odwiedzający, a nie pomiar laboratoryjny.
- Porównanie. Dwie podstrony między sobą albo strona z własnym wcześniejszym pomiarem; pomiar bazowy leży w pliku w folderze domowym użytkownika.
- Sprawdzanie wielu adresów. Do dziesięciu adresów w jednym wywołaniu i podsumowanie dla każdego.
- Czyszczenie pamięci podręcznej. Serwer trzyma odpowiedzi godzinę; po poprawkach na stronie warto ją wyczyścić, bo inaczej dostaniesz stary pomiar.
Co pokazał pierwszy test na mojej stronie
Sprawdziłem stronę główną studia w profilu mobilnym. Oceny: szybkość — 66–71 na 100 (w różnych uruchomieniach), dostępność — 90, dobre praktyki — 100, SEO — 100. Najsłabiej wypadły główne wskaźniki Google (Core Web Vitals): czas pojawienia się głównego elementu strony (LCP) — 5,0–5,3 s przy normie do 2,5 s oraz przesuwanie się układu podczas ładowania (CLS) — około 0,13 przy normie do 0,1.
Diagnostyka zasobów blokujących wskazała dziesięć plików — style i skrypty szablonu, które przeglądarka musi pobrać, zanim pokaże stronę. Razem opóźniały wyświetlenie o około 1,9 s. Najcięższe to główny plik stylów motywu (około 81 KB) i skrypt UIkit (około 50 KB). Do tego nieużywany kod: około 101 KB stylów i 49 KB skryptów, a osobną pozycją — zbędne przekierowania, które zjadają około 0,75 s. To szablon konstruktora, a nie mój kod, więc trzeba to rozwiązać ustawieniami budowania i pamięci podręcznej, a nie edycją plików.
Sprawdzenie dwóch podstron naraz pokazało rozrzut, który ręcznie łatwo przeoczyć: strona główna — 69, podstrona o SEO — 85 (LCP 3,2 s, brak przesunięć układu). Porównanie rosyjskiej i angielskiej strony głównej: 66 do 71. Danych prawdziwych użytkowników raport Chrome dla domeny nie zwrócił: „za mało ruchu”. Dla małej witryny to normalne, a nie awaria: do raportu trafiają tylko adresy z wystarczającą liczbą wizyt z Chrome.
Pułapki, w które wpadłem
- 429 bez klucza. Anonimowy limit Google jest wspólny i prawie zawsze wyczerpany, więc „spróbować bez klucza” się nie da.
- 403 przy danych prawdziwych użytkowników. Klucz ograniczony do jednego interfejsu nie przepuści drugiego: Chrome UX Report API trzeba włączyć osobno i dodać do ograniczeń klucza.
- Nowych narzędzi nie ma w starej sesji. Po
claude mcp add sesję trzeba otworzyć od nowa.
- Oceny się wahają. Pomiar jest laboratoryjny, na umownym telefonie, i między uruchomieniami różnica to kilka punktów — u mnie 66 i 71 na tej samej stronie. Jedno uruchomienie to nie dowód: narzędzia mają parametr „liczba uruchomień” (do pięciu), a serwer sam robi przerwę około minuty między nimi, inaczej Google zwróciłby ten sam wynik.
- Pamięć podręczna na godzinę. Poprawiłeś stronę — wyczyść pamięć serwera i dopiero mierz. Inaczej porównasz się sam ze sobą.
- Oznaczenie „zmienia dane” przy porównaniu dotyczy pliku lokalnego. Chodzi tylko o plik z pomiarem bazowym w Twoim folderze domowym. Strony ani usług Google to narzędzie nie rusza.
Co się sprawdziło, a co nie
- Działa od razu: wskazanie przyczyn spowolnienia, lista poprawek według ważności, porównanie podstron jednej witryny, sprawdzanie wielu adresów. Asystent sam dobiera narzędzie do pytania i tłumaczy raport z angielskiego.
- Wymaga przygotowania: dane prawdziwych użytkowników — osobne włączenie API i odpowiedni ruch.
- Z zastrzeżeniami: to pomiar, a nie leczenie. Serwer niczego nie zmienia na stronie: pokazuje, co spowalnia, a poprawiać i tak musisz Ty albo programista. Za to zamiast pół godziny w raporcie masz listę poprawek w minutę.
- Zawsze pamiętać: sprawdzane są tylko strony publiczne. Panel klienta i wszystko, co jest za hasłem, usługa nie zobaczy.
Krótka lista kontrolna
- Upewnić się, że jest Node.js 20.19 lub nowszy.
- Włączyć PageSpeed Insights API (oraz Chrome UX Report API, jeśli potrzebne są dane prawdziwych użytkowników).
- Utworzyć osobny klucz API i ograniczyć go do potrzebnych interfejsów.
- Zainstalować pakiet
pagespeed-insights-mcp przez npm.
- Zarejestrować serwer poleceniem
claude mcp add w zakresie użytkownika.
- Sprawdzić klucz zwykłym zapytaniem i otworzyć nową sesję Claude.
- Do porównania „przed i po” prosić o trzy do pięciu uruchomień zamiast jednego.
Jeśli nie masz ochoty przechodzić tej drogi samodzielnie, możemy podłączyć PageSpeed Insights do asystenta AI za Ciebie — na Twoim komputerze albo w Twojej chmurze.
