Szybkość custom post types w WordPress – jak ją poprawić?

Największym winowajcą wolnych CPT są nieefektywne zapytania WP_Query. Domyślnie WordPress pobiera wszystkie dane posta wraz z metadanymi, nawet gdy potrzebujesz jedynie tytułu i miniaturki. Rozwiązaniem jest parametr `fields => 'ids'`, który zwraca wyłącznie identyfikatory postów – resztę danych pobierasz na żądanie. Ustaw `no_found_rows => true`, jeśli nie potrzebujesz paginacji, co eliminuje kosztowne zapytanie SQL_CALC_FOUND_ROWS. Parametr `update_post_meta_cache => false` wyłącza preloading metadanych, gdy ich nie wykorzystujesz. Na stronie z 5000 wpisów CPT te trzy zmiany skróciły czas odpowiedzi z 2,3 s do 0,4 s.

Tabela wp_postmeta w WordPressie domyślnie posiada indeks jedynie na kolumnie meta_id i post_id. Przy dużej liczbie custom post types zapytania filtrujące po meta_key i meta_value wykonują pełne skanowanie tabeli (full table scan), co drastycznie spowalnia stronę. Dodanie złożonego indeksu na kolumnach (meta_key, meta_value) za pomocą polecenia ALTER TABLE wp_postmeta ADD INDEX idx_meta_key_value (meta_key(191), meta_value(100)) potrafi przyspieszyć zapytania meta_query nawet dziesięciokrotnie. Pamiętaj również o regularnym uruchamianiu OPTIMIZE TABLE na tabelach wp_posts i wp_postmeta, szczególnie po masowym usuwaniu lub edycji wpisów.

Cache obiektowy z Redis lub Memcached to fundament wydajnego WordPressa z rozbudowanymi CPT. Zamiast odpytywać bazę danych przy każdym wyświetleniu strony, wyniki zapytań przechowywane są w pamięci RAM serwera. Wtyczka Redis Object Cache integruje się z WordPressem w kilka minut. Uzupełnieniem jest Transient API – natywny mechanizm cache WordPressa idealny do przechowywania wyników złożonych zapytań WP_Query. Ustawiasz czas wygasania (np. 3600 sekund) i WordPress automatycznie odświeża dane. Dla list CPT wyświetlanych na stronie głównej lub w sidebarze to rozwiązanie redukuje zapytania do bazy o 90% przy typowym ruchu.

Gdy Twoja strona wyświetla dziesiątki lub setki wpisów CPT jednocześnie, sam cache nie wystarczy. Implementacja lazy loading poprzez AJAX pozwala ładować wpisy partiami – np. 12 na raz – dopiero gdy użytkownik przewinie stronę. Dzięki temu początkowy czas ładowania drastycznie maleje, a serwer nie musi generować pełnej listy za jednym razem. W WordPressie realizujesz to przez wp_ajax_ i wp_ajax_nopriv_ hooki w połączeniu z JavaScript Intersection Observer API. Alternatywą jest klasyczna paginacja AJAX z parametrem `paged` w WP_Query. Oba podejścia znacząco zmniejszają obciążenie serwera i poprawiają wynik Largest Contentful Paint.

Bez regularnego monitorowania nie wiesz, czy wprowadzone optymalizacje działają. Wtyczka Query Monitor wyświetla wszystkie zapytania SQL wykonywane na danej stronie wraz z czasem ich wykonania – szybko zidentyfikujesz te najwolniejsze. GTmetrix i Google PageSpeed Insights dostarczą danych o Core Web Vitals. Warto skonfigurować monitoring ciągły za pomocą narzędzi takich jak New Relic lub wbudowanego w hosting APM. Ustaw alerty na czas odpowiedzi serwera (TTFB) powyżej 500 ms. Zbieraj dane tygodniowo i porównuj trendy – pozwoli to reagować zanim problem wpłynie na pozycje w Google.

Wdrożenie tego, o czym piszemy w artykule, wymaga doświadczenia i czasu. Jeśli wolisz, by zajęli się tym specjaliści, sprawdź naszą ofertę WordPress lub ofertę stron internetowych.

Możesz też napisać do nas bezpośrednio – umów bezpłatną konsultację, a my przeanalizujemy Twoją sytuację i zaproponujemy najlepsze rozwiązanie.