Raport w Looker Studio, który otwiera się minutę albo dłużej, rzadko jest ofiarą samej ilości danych. Znacznie częściej problemem jest liczba zapytań, które strona wysyła do źródeł przy każdym otwarciu, odświeżeniu filtra czy zmianie zakresu dat. Każdy wykres, każda tabela i każdy kontroler to osobne żądanie, a jeśli źródłem jest konektor GA4 albo Search Console, każde z nich trafia do zewnętrznego API z własnymi limitami. Poniżej osiem najczęstszych przyczyn, przez które Looker Studio wolno działa, i konkretne sposoby, żeby raport znów ładował się w kilka sekund.
Jak sprawdzić, co spowalnia raport
Zanim zaczniesz cokolwiek przebudowywać, ustal, który element jest wąskim gardłem. Najprostsza metoda to praca na kopii raportu: usuwasz kolejne wykresy ze strony i mierzysz czas ładowania po każdym kroku. Jeśli zniknięcie jednej tabeli skraca ładowanie z 40 do 8 sekund, wiesz, gdzie szukać. Drugi sygnał to ikony błędów i komunikaty o przekroczeniu limitu w rogu wykresów; przy konektorze GA4 pojawiają się one, gdy raport wyczerpuje godzinowy przydział tokenów usługi.
1. Zbyt wiele wykresów na jednej stronie
Looker Studio renderuje wszystkie elementy aktualnej strony równolegle, ale każdy z nich generuje własne zapytanie. Strona z 25 kartami wyników, czterema tabelami i trzema wykresami czasowymi to ponad 30 zapytań wysyłanych jednocześnie. Przy konektorach API część z nich trafia do kolejki, a użytkownik widzi kręcące się kółka.
Rozwiązanie jest banalne, choć niewygodne dla autorów raportów: dzielisz treść na kilka stron tematycznych. Strona przeglądowa z 6–8 kluczowymi wskaźnikami ładuje się szybko, a szczegóły trafiają na podstrony, które otwiera tylko ten, kto ich potrzebuje. Karty wyników pokazujące ten sam wskaźnik w różnych okresach można zastąpić jedną tabelą z porównaniem okresów. Jeśli szukasz układów, które dobrze to rozwiązują, zobacz wzorce dashboardów SEO i AIO w Looker Studio.
2. Blendy danych i ich koszt
Blend łączy dane z kilku źródeł po wspólnym kluczu, na przykład dacie albo adresie strony. Problem w tym, że Looker Studio wykonuje złączenie po swojej stronie: najpierw pobiera dane z każdego źródła osobno, a dopiero potem je łączy. Blend pięciu źródeł oznacza pięć zapytań na każdy wykres, który z niego korzysta. Do tego złączenie po kluczu o wysokiej kardynalności (URL, zapytanie wyszukiwania) potrafi wygenerować setki tysięcy wierszy pośrednich.
Praktyczne zasady są trzy. Łącz najmniej źródeł, ile się da, i tylko po kluczach, które naprawdę są potrzebne. Ograniczaj zakres już w blendzie, a nie dopiero filtrem na wykresie. A jeśli ten sam blend zasila kilkanaście elementów, to znak, że złączenie powinno odbywać się w źródle danych, nie w raporcie.
3. Pola liczone kontra przygotowanie danych u źródła
Pola liczone są wygodne, ale każde z nich jest przeliczane przy każdym zapytaniu. Pojedyncze CASE grupujące kanały nie zrobi różnicy. Kilkanaście zagnieżdżonych REGEXP_MATCH na polu adresu strony, liczone na milionach wierszy, już tak. Szczególnie kosztowne są pola liczone na poziomie wykresu, bo nie korzystają z pamięci podręcznej tak samo jak pola zdefiniowane w źródle danych.
Jeśli klasyfikacja jest stała (typ strony, grupa produktów, rodzaj zapytania), lepiej przygotować ją wcześniej: w arkuszu, w widoku BigQuery albo w tabeli pośredniej. Więcej o tym, kiedy pola liczone mają sens, a kiedy szkodzą, piszemy w tekście o polach liczonych, blendach i parametrach w Looker Studio.
4. Ustawienia pamięci podręcznej i odświeżania
Każde źródło danych ma ustawienie świeżości danych. Dla konektorów Google domyślnie jest to 12 godzin, ale autor może je skrócić nawet do 15 minut. Krótki interwał oznacza, że Looker Studio częściej omija pamięć podręczną i odpytuje źródło na nowo. Dla raportu SEO, w którym dane Search Console i tak pojawiają się z dwu- lub trzydniowym opóźnieniem, odświeżanie co kwadrans nie daje nic poza wolniejszym ładowaniem.
Ustaw świeżość zgodnie z rytmem, w jakim dane faktycznie się zmieniają: 12 godzin dla GA4 i Search Console, 4 godziny dla danych kampanii, jeśli ktoś naprawdę reaguje w ciągu dnia. Pamiętaj też, że przycisk ręcznego odświeżania danych omija cache dla wszystkich, więc nie warto go klikać przy każdym otwarciu raportu.
5. Konektor GA4 i limity API
Konektor GA4 odpytuje Data API w czasie rzeczywistym, a każda usługa ma godzinowe i dzienne limity tokenów. Raport współdzielony przez kilkanaście osób, z wieloma wymiarami i długim zakresem dat, wyczerpuje je szybko. Skutek to nie tylko wolne ładowanie, ale też puste wykresy z komunikatem o błędzie. Opis limitów znajdziesz w dokumentacji limitów Google Analytics Data API.
Pomaga skrócenie domyślnego zakresu dat (ostatnie 28 dni zamiast 12 miesięcy), rezygnacja z wymiarów o wysokiej kardynalności na stronie głównej raportu oraz łączenie podobnych wykresów w jeden.
6. Wyodrębnione dane jako źródło
Funkcja wyodrębniania danych (Extract Data) tworzy statyczną migawkę wybranych wymiarów i danych, przechowywaną po stronie Looker Studio. Raport korzystający z wyciągu nie odpytuje API przy każdym otwarciu, więc ładuje się wyraźnie szybciej. Wyciąg można odświeżać automatycznie raz dziennie, raz w tygodniu albo raz w miesiącu.
Ograniczenia są dwa: wyciąg ma limit rozmiaru (100 MB) i obejmuje tylko pola wybrane przy jego tworzeniu. Dlatego sprawdza się przy raportach o ustalonym zakresie, na przykład miesięcznym podsumowaniu dla klienta. Takie raporty łatwo potem rozsyłać automatycznie, o czym więcej w tekście o automatyzacji raportów klienckich w Looker Studio.
7. Filtry, kontrolki i zakres dat na poziomie raportu
Kontrolka rozwijana z listą 20 tysięcy adresów URL sama w sobie jest zapytaniem, i to ciężkim. Tak samo działa porównanie z poprzednim okresem włączone na każdym wykresie: podwaja liczbę zapytań. Zamiast listy wszystkich stron lepiej dać kontrolkę wyszukiwania tekstowego albo filtr po grupie stron. Porównanie okresów warto zostawić tylko tam, gdzie ktoś faktycznie z niego korzysta.
8. Kiedy przenieść dane do BigQuery
Gdy raport łączy kilka źródeł, ma kilkunastu odbiorców i regularnie trafia w limity API, najrozsądniejszym krokiem jest przeniesienie danych do hurtowni. BigQuery przyjmuje zapytania z Looker Studio szybko, a złączenia, klasyfikacje i agregacje można przygotować raz, w zaplanowanym zapytaniu, zamiast liczyć je przy każdym otwarciu raportu.
Punktem wyjścia jest zwykle natywny eksport, który opisujemy w poradniku eksport GA4 do BigQuery. Kluczowa zasada: nie podpinaj surowej tabeli zdarzeń bezpośrednio do raportu. Zbuduj z niej dzienne tabele zagregowane (sesje, konwersje, strony docelowe) i to je udostępnij Looker Studio. Zapytanie do tabeli z kilkoma tysiącami wierszy jest szybkie i tanie, a zapytanie do pełnej tabeli zdarzeń za rok potrafi przeskanować dziesiątki gigabajtów przy każdym kliknięciu filtra.
Krótka lista kontrolna
| Objaw | Najczęstsza przyczyna | Pierwszy krok |
|---|---|---|
| Wszystkie wykresy ładują się długo | Za dużo elementów na stronie | Podziel raport na strony tematyczne |
| Puste wykresy z błędem limitu | Wyczerpane tokeny GA4 Data API | Skróć zakres dat, użyj wyciągu lub BigQuery |
| Wolny tylko jeden wykres | Ciężki blend lub pole liczone | Przenieś złączenie albo klasyfikację do źródła |
| Raport wolny przy każdym otwarciu | Krótka świeżość danych | Wydłuż odświeżanie do 12 godzin |
| Wolna kontrolka filtra | Lista o wysokiej kardynalności | Zastąp ją wyszukiwaniem tekstowym |
FAQ
Dlaczego Looker Studio wolno działa, skoro danych jest niewiele?
Bo czas ładowania zależy głównie od liczby zapytań, a nie od wielkości danych. Każdy wykres, tabela i kontrolka wysyła osobne zapytanie, a przy konektorach API (GA4, Search Console) każde z nich podlega limitom i kolejkowaniu.
Czy wyodrębnione dane zawsze przyspieszą raport?
Zwykle tak, bo raport przestaje odpytywać API przy każdym otwarciu. Wyciąg ma jednak limit 100 MB i obejmuje tylko wybrane pola, więc nie nadaje się do raportów, w których użytkownik dowolnie zmienia wymiary i długie zakresy dat.
Ile wykresów można bezpiecznie umieścić na jednej stronie raportu?
Nie ma sztywnej granicy, ale strony z 6–10 elementami zazwyczaj ładują się sprawnie. Powyżej 20 elementów, zwłaszcza przy konektorach API, spowolnienie jest niemal pewne.
Czy przeniesienie danych do BigQuery jest drogie?
Przy rozsądnie zaprojektowanych tabelach zagregowanych koszt jest niewielki, często mieści się w darmowym progu zapytań. Drogo robi się wtedy, gdy raport odpytuje surową tabelę zdarzeń za długi okres przy każdej zmianie filtra.
Czy ręczne odświeżanie danych pomaga, gdy raport się zawiesza?
Nie. Ręczne odświeżanie omija pamięć podręczną i wymusza ponowne odpytanie wszystkich źródeł, więc przy przeciążonym raporcie zwykle pogarsza sytuację.