Wtyczka FlyingPress – Taking WordPress To New Heights - 5.6.5

FlyingPress to wtyczka optymalizacji wydajności WordPressa od FlyingWeb LLC: cache stron, usuwanie nieużywanego CSS, opóźnianie JavaScriptu i optymalizacja obrazów w jednym panelu. Sprawdza się tam, gdzie strona mimo działającego cache’a nie przechodzi Core Web Vitals – najcięższe analizy przejmuje chmura producenta.

Cache stron, preloading i osobny cache dla urządzeń mobilnych

FlyingPress generuje statyczne pliki HTML i oddaje je bezpośrednio przez serwer WWW, z pominięciem PHP i całego WordPressa. Zapis idzie od razu w postaci skompresowanej GZIP – producent podaje tu około 80% redukcji rozmiaru katalogu cache. Układy mobilne dostają własny zestaw plików i własny preload, bo widok na telefonie rzadko pokrywa się z desktopowym.

Automatyczny preload i odbudowa cache po aktualizacji treści

Listę adresów do zbudowania cache wtyczka układa sama, prosto z zawartości bazy danych – bez sitemapy. Kolejka pracuje w tle, a panel na bieżąco pokazuje liczniki „Pages Cached” oraz „URLs in Queue”.

Zapis wpisu, produktu albo pola ACF czyści i odbudowuje nie samą zmienioną stronę – idą za nią powiązane archiwa, kategorie i tagi. Tak samo działa aktualizacja produktu WooCommerce przychodząca przez REST API, choćby przy zmianie stanu magazynowego.

Cache dla zalogowanych użytkowników według roli

Dla zalogowanych FlyingPress tworzy osobne pliki przypisane do roli WordPressa, na przykład index-logged-in-subscriber.html.gz. Konto z kilkoma rolami dostaje klucz łączony. Wersje serwowane zalogowanym pomijają optymalizacje front-endowe, więc mechanizm pasuje do obszarów członkowskich i paneli klienta WooCommerce – nie do treści układanej pod pojedyncze konto.

Wykluczenia, ciasteczka i parametry śledzące w kluczu cache

• Wykluczanie stron z cache – pojedyncze adresy albo wzorce ścieżek pomijane przy generowaniu statycznego HTML.
• Bypass po ciasteczku – wskazane ciasteczka wyłączają serwowanie cache dla danej sesji, co obejmuje między innymi ciasteczko koszyka WooCommerce.
• Osobny cache dla parametrów query – wybrane parametry adresu tworzą własną wersję strony.
• Ignorowanie parametrów śledzących – utm_source, gclid, fbclid, msclkid, srsltid, gad_source, gbraid czy mc_cid nie rozbijają klucza cache na dziesiątki wariantów tej samej strony.

Object caching na Redis dla koszyka, kasy i panelu klienta

Jeden przełącznik. Tyle wystarczy, żeby wtyczka zainstalowała drop-in object-cache.php i przeniosła wyniki zapytań do bazy na serwer Redis. Panel pokazuje potem status połączenia, zużycie pamięci i cache hit ratio z ostatniej godziny.

Zysk pojawia się tam, gdzie cache stronowy nie sięga: w koszyku, kasie, obszarze „moje konto”, panelach członkowskich i zapleczu wp-admin. Warunek jest twardy – osiągalny serwer Redis oraz rozszerzenie PHP phpredis. Bez nich przełącznik zostaje nieaktywny.

Usuwanie nieużywanego CSS, opóźnianie JavaScriptu i lazy render

Optymalizacje front-endowe FlyingPress powstają w chmurze producenta: prawdziwa przeglądarka renderuje stronę i wykrywa CSS faktycznie użyty w pierwszym viewporcie, elementy above-the-fold oraz skrypty zewnętrzne. Wykryty CSS trafia inline w znaczniku style o identyfikatorze flying-press-css, reszta arkuszy dociąga się asynchronicznie w chwili bezczynności przeglądarki. Analiza powtarza się po każdej zmianie układu lub treści.

Elementy pojawiające się dopiero po interakcji – popupy, taby, rozwijane menu – analiza pierwszego widoku potrafi przeoczyć. Od tego jest safelista, do której trafiają ich selektory.

Trzy strategie opóźniania JavaScriptu i automatyczne wykrywanie skryptów third-party

Skrypty zewnętrzne – analityka, reklamy, widgety społecznościowe – wtyczka rozpoznaje sama, bez ręcznego wpisywania domen. Do wykluczenia pojedynczego skryptu wystarczy fragment jego zapisu. Dopasowanie przeszukuje cały tag script i nie rozróżnia wielkości liter, więc zadziała tak samo na kawałku adresu, na identyfikatorze i na kodzie osadzonym inline.

Lazy Render, czyli opóźnione renderowanie sekcji poniżej pierwszego ekranu

Przeglądarka wstrzymuje renderowanie dalszych sekcji, dopóki odwiedzający do nich nie dojedzie. Odpowiada za to natywna właściwość content-visibility: auto, przypisywana elementom spod pierwszego ekranu. Wymiary sekcji wtyczka podaje z góry, żeby opóźnione renderowanie nie rozjeżdżało układu. Efekt widać przede wszystkim w metrykach TBT i TTI – na stronach z długimi, rozbudowanymi układami.

Preload Links i wstępne pobieranie stron przy najechaniu na link

Prefetch opiera się na natywnym Speculation Rules API przeglądarki: strona docelowa ładuje się w tle już przy najechaniu kursorem na odnośnik, więc przejście wydaje się natychmiastowe. Poza kolejką prefetchu zostają automatycznie koszyk, kasa i wylogowanie WooCommerce. Obok nich zaplecze wraz z ekranem logowania, odnośniki z parametrami zapytania i wszystko, co kończy się na .php. Wbudowane Speculation Rules WordPressa wtyczka przy tym wyłącza, żeby obie warstwy nie pracowały równolegle.

Optymalizacja obrazów, fontów i osadzonych filmów

Wbudowany optymalizator obrazów kompresuje pliki JPG i PNG oraz konwertuje je do WebP lub AVIF na serwerach producenta, a oryginały zostawia do ewentualnego przywrócenia. Obrazy spod pierwszego ekranu doczytują się przy przewijaniu. Obraz LCP wtyczka wykrywa i preloaduje z wysokim priorytetem, a brakujące atrybuty width i height uzupełnia, co ogranicza przesunięcia układu.

Konwersja do WebP i AVIF oraz reguły fallback dla starszych przeglądarek

Do wyboru tryb stratny, bezstratny albo optymalizacja z zachowaniem oryginalnego formatu. Gotowe pliki trafiają do katalogu uploads, wtyczka przepisuje adresy w treści, a Biblioteka mediów pokazuje statystyki dla pojedynczego obrazu. Nowe wgrywane pliki przechodzą optymalizację automatycznie, jeśli tak ustawiono; wybrane obrazy da się wykluczyć po nazwie.

Przeglądarki bez obsługi nowszych formatów obejmuje reguła fallback w .htaccess albo w konfiguracji Nginx – dostają plik oryginalny. Uwaga: optymalizacja obejmuje wyłącznie JPG, JPEG i PNG. Pliki GIF czy SVG zostają nietknięte, a trwałe skasowanie oryginałów jest nieodwracalne bez własnej kopii zapasowej.

Lazy loading mediów i automatyczne wykluczanie obrazów above-the-fold

Odroczone ładowanie obejmuje obrazy, filmy, ramki iframe oraz tła definiowane w CSS. Chmura rozpoznaje media widoczne w pierwszym ekranie i wypisuje je z lazy loadingu, żeby nie opóźniać elementu odpowiedzialnego za LCP.

Osobno idą atrybuty srcset i sizes, które wtyczka generuje z rozmiarów przygotowanych przez WordPressa. Przeglądarka pobiera wtedy wariant dopasowany do ekranu – również dla obrazów wstawianych przez motyw czy builder.

Fonty Google z własnej domeny i lekkie miniatury YouTube

Fonty Google wtyczka potrafi pobrać i serwować z domeny witryny, z opcjami łączenia i preloadowania. Alternatywa to tryb „Use System Fonts First”, w którym na starcie wchodzą fonty systemowe. Preload obejmuje wyłącznie te kroje, które faktycznie pojawiają się na stronie.

Osadzony odtwarzacz YouTube ustępuje miejsca statycznej miniaturze. Wtyczka pobiera ją przez usługę chmurową w najwyższej dostępnej rozdzielczości i hostuje lokalnie, więc przy wejściu na stronę nie leci żadne zapytanie do ytimg.com.

Pomiar Core Web Vitals od realnych odwiedzających i porządki w bazie danych

Panel Vitals zbiera LCP, INP, CLS i TTFB od realnych odwiedzających, przez nieblokujący mikroskrypt vitals.min.js ładowany asynchronicznie na publicznych stronach. Pierwsze wyniki są w ciągu kilku godzin – nie po 28-dniowej średniej, jak w danych polowych PageSpeed Insights. Zebrane dane producent anonimizuje, wiąże z domeną witryny i trzyma u siebie, poza bazą WordPressa.

Filtry danych: urządzenie, zakres czasu, kraj i pojedyncza podstrona

Wyniki zawężają się do urządzeń mobilnych albo desktopowych i do okna czasowego: ostatnia godzina, doba, siedem lub trzydzieści dni. Dodatkowe rozbicia pokazują metryki dla poszczególnych krajów i dla pojedynczych podstron. Tyle wystarczy, żeby odróżnić problem globalny od jednego ciężkiego szablonu.

Harmonogram czyszczenia bazy: rewizje, transienty, spam i optymalizacja tabel

• Rewizje wpisów i autodrafty narosłe przez lata edycji.
• Wpisy i komentarze w koszu oraz komentarze oznaczone jako spam.
• Wygasłe transienty pozostawione przez wtyczki.
• Defragmentacja i optymalizacja tabel bazy danych.

Całość idzie ręcznie albo w harmonogramie – dziennym, tygodniowym lub miesięcznym.

Bloat Remover i wyłączanie nieużywanych elementów WordPressa

Zakładka Bloat Remover wyłącza to, czego dana witryna zwykle i tak nie używa: CSS edytora blokowego i bloków WooCommerce, Dashicons dla niezalogowanych, emoji, jQuery Migrate, XML-RPC, kanały RSS oraz oEmbedy. Osobne przełączniki tną liczbę rewizji do trzech i spowalniają Heartbeat API do 60 sekund. Na koncie współdzielonym widać to w obciążeniu.

Integracje z Cloudflare, Redisem, WooCommerce i wtyczkami wielojęzycznymi

Integracja z Cloudflare przenosi cache całych stron HTML na edge i działa na wszystkich planach Cloudflare, łącznie z darmowym, bez sięgania po APO. Wykluczenia stron, ignorowane parametry query, bypass cookies i tryb osobnego cache mobilnego wtyczka odwzorowuje po stronie Cloudflare automatycznie. Czyszczenie cache w panelu obejmuje przy tym również warstwę edge.

Cloudflare, FlyingCDN i podłączenie własnego CDN

Integracja potrzebuje dwóch rzeczy: ruchu przechodzącego przez proxy Cloudflare, czyli pomarańczowej chmurki w DNS, oraz wyłączonego APO. Uwaga o kompatybilności: APO i integracja FlyingPress cache’ują to samo – pełny HTML na edge. Działają rozłącznie, nigdy równolegle.

Osobnym, opcjonalnym dodatkiem jest FlyingCDN oparty na sieci Cloudflare Enterprise: cache stron, konwersja obrazów do WebP w locie bez zmiany adresów, HTTP/3, Brotli, Argo Smart Routing i ochrona przed DDoS. Zamiast niego wchodzi dowolny inny CDN – BunnyCDN, KeyCDN – po podaniu własnego adresu w zakładce CDN. Zalogowani użytkownicy WordPressa omijają cache HTML po stronie Cloudflare zawsze.

WooCommerce: wykluczenia stron transakcyjnych, purge po aktualizacji produktu, cache per waluta

Koszyk, kasa i „moje konto” wypadają z cache automatycznie, bez ręcznego dopisywania adresów. Aktualizacja produktu odświeża jego stronę razem z powiązanymi archiwami – także wtedy, gdy zmiana przychodzi przez REST API. Ceny i dostępność nie tracą aktualności w statycznym pliku.

Wielowalutowość obsługują integracje z Aelia Currency Switcher, CURCY, WooCommerce Multilingual i YITH Multi-Currency Switcher: każda waluta dostaje własny cache, a preload buduje wersję w walucie domyślnej. Producent przetestował też koegzystencję z SureCart i Easy Digital Downloads, przy ręcznym wykluczeniu ich stron dynamicznych.

Strony wielojęzyczne na WPML, Polylang, TranslatePress i Weglot

Każda wersja językowa ma własny cache – bez znaczenia, czy języki rozdzielono na subkatalogi, subdomeny czy oddzielne domeny. Po aktualizacji treści wtyczka czyści i preloaduje wyłącznie strony w odpowiednim języku. Pozostałe wersje zostają w cache nietknięte.

WP-CLI, hooki i filtry dla deweloperów

Warstwa deweloperska zaczyna się od komend WP-CLI: preload-cache, purge-pages i purge-everything – przeznaczonych do cronów i skryptów wdrożeniowych. Dalej idą funkcje PHP do programowego czyszczenia i budowania cache, action hooki przed i po purge oraz filtry, między innymi flying_press_auto_purge_urls i flying_press_optimization_image_ids. Konfiguracja wtyczki eksportuje się do pliku i wgrywa na kolejnej instalacji.

Dla jakich witryn FlyingPress ma sens

FlyingPress trafia przede wszystkim do sklepów WooCommerce i witryn contentowych, które mimo działającego cache’a nie spełniają Core Web Vitals, oraz na słabszy hosting współdzielony – tam najcięższe analizy wykonuje chmura producenta zamiast lokalnego CPU. Druga grupa to zespoły utrzymujące wiele witryn naraz, dla których liczą się eksport konfiguracji, obsługa z linii poleceń i realne dane metryk zamiast pojedynczego pomiaru z PageSpeed Insights.

Sklepy WooCommerce, które nie przechodzą mobilnych Core Web Vitals

Typowy sklep na Elementorze albo Bricksie ładuje obszerny CSS motywu, kilkanaście skryptów wtyczek i galerie zdjęć produktów. Statyczny cache obejmuje kategorie i karty produktów. Strony transakcyjne zostają poza nim – i to właśnie te dynamiczne widoki przyspiesza Redis.

Do tego osobne optymalizacje dla widoku mobilnego, opóźnienie skryptów zewnętrznych do pierwszej interakcji i preload obrazu LCP. To warstwy, na których przyspieszenie strony WordPress widać w metrykach polowych mocniej niż po samym page cache’u.

Blogi i portale z dużą liczbą podstron oraz osadzonymi filmami

Serwis z kilkuset wpisami zyskuje najwięcej na kolejce preloadu, którą wtyczka układa sama – bez sitemapy, z obciążeniem rozłożonym w czasie. Osadzone filmy zamieniają się w lokalnie hostowane miniatury, obrazy przechodzą do WebP lub AVIF, a prefetch przez Speculation Rules skraca przejścia między kolejnymi wpisami.

Agencje i witryny na współdzielonym hostingu

Przy kilkudziesięciu witrynach klienckich na różnych hostingach liczy się powtarzalność ustawień. Konfigurację wystarczy raz wyeksportować i wgrywać dalej, a purge oraz preload integrują się ze skryptami wdrożeniowymi przez WP-CLI. Panel Vitals dodaje do tego raport z realnymi metrykami dla każdej witryny osobno.

Na tanim koncie współdzielonym decyduje co innego. Generowanie used CSS i kompresja obrazów idą na serwerach producenta, więc limity procesów na hostingu nie stają się wąskim gardłem.

Kiedy FlyingPress nie jest dobrym wyborem

• Witryny niedostępne publicznie – instalacje na localhost, za HTTP Basic Auth, VPN-em lub firewallem blokującym serwery producenta nie zostaną zoptymalizowane, bo chmura musi pobrać stronę.
• Hosting LiteSpeed z w pełni wykorzystanym LiteSpeed Cache – cache na poziomie serwera bywa tam szybszy pod względem TTFB, a dwie wtyczki cache równolegle są odradzane.
• Setupy oparte na logice PHP przy każdym żądaniu – przekierowania i nagłówki HTTP dodawane w functions.php lub przez wtyczki pokroju Really Simple SSL nie wykonają się na stronie serwowanej z cache; ich miejsce jest na poziomie serwera albo CDN.
• Treść personalizowana indywidualnie – cache dla zalogowanych rozróżnia role, nie pojedyncze konta, więc osobiste dashboardy odpadają.
• Rozbudowane, ręcznie dostrojone stosy wydajnościowe – wtyczka projektowana jest jako jedyna warstwa optymalizacji i demontuje kolidujące funkcje sąsiadów.

Wymagania środowiska, hostingi i kompatybilność z builderami

FlyingPress wymaga WordPressa 4.7 lub nowszego, PHP 7.4 (producent zaleca 8.0 wzwyż) oraz bazy MySQL 5.6 albo MariaDB 10.0. Katalog wp-content musi być zapisywalny – trafiają tam pliki cache i zoptymalizowane zasoby. Do Apache, Nginx, LiteSpeed i OpenLiteSpeed wtyczka dostraja się sama, ale witryna musi być osiągalna z internetu, bo optymalizacje powstają w chmurze producenta.

Serwery, hostingi i dostępność witryny z internetu

Na liście sprawdzonych hostingów producent wymienia między innymi SiteGround, Cloudways, Kinsta, Closte, Rocket.net, WP Engine, GridPane, RunCloud, SpinupWP, Pressable i InstaWP, a obok nich dowolne konto z cPanel lub Plesk. U części z nich czyszczenie cache w panelu wtyczki obejmuje również cache serwerowy hostingu.

Analizy wykonują serwery rozstawione w Los Angeles, Waszyngtonie, Amsterdamie, Frankfurcie, Singapurze i Mumbaju, a preload przychodzi z USA, Niemiec i Singapuru. Restrykcyjny firewall albo wtyczka bezpieczeństwa blokująca REST API przerywa kolejkę preloadu. Żądania z User-Agentem zawierającym „FlyingPress” muszą przez taką barierę przejść.

Buildery, motywy i wtyczki przetestowane przez producenta

Po stronie motywów przetestowane są Hello Elementor, Astra, GeneratePress, Kadence, Blocksy, OceanWP, Neve, Divi, Bricks, Avada, Storefront, Sydney, Phlox oraz motywy domyślne WordPressa. Z wtyczek producent wymienia Rank Math SEO wraz z wersją PRO, SEOPress, WooCommerce, Advanced Custom Fields PRO, Gravity Forms, WPForms Lite, WP Mail SMTP, FluentSMTP i Nginx Helper.

Osobną grupę stanowią wtyczki, w których FlyingPress po aktywacji sam wyłącza kolidujące funkcje: Breeze, EWWW Image Optimizer, Perfmatters, ShortPixel Adaptive Images i SiteGround Optimizer – bez rozbrajania ustawień po kolei.

Multisite i polski interfejs wtyczki

Sieć multisite działa w wariancie subkatalogów, subdomen i domain mappingu. Aktywację sieciową producent odradza – wtyczkę włącza się osobno na każdej podwitrynie, a przy zmapowanych domenach logowanie przed aktywacją odbywa się przez domenę docelową. Superadmin ma dostęp do panelu wtyczki z poziomu sieci.

Interfejs wtyczki jest przetłumaczony na polski od wersji 5.4.0 z kwietnia 2026, z poprawkami ładowania tłumaczeń w kolejnych wydaniach; dokumentacja i wsparcie techniczne pozostają anglojęzyczne. Dla polskich witryn liczy się też poprawne dekodowanie znaków spoza ASCII w adresach URL – adresy z ogonkami są prawidłowo obsługiwane przy generowaniu i czyszczeniu cache. Polskie firmy hostingowe nie występują na liście przetestowanych dostawców, ale wspierane silniki serwerów obejmują praktycznie cały rodzimy rynek.

Wtyczki, z którymi FlyingPress nie powinien działać równolegle

Uwaga o kompatybilności: na liście konfliktów producent umieszcza WP Optimize, WP Meteor, instant.page oraz Super Page Cache. Ich funkcje pokrywają się z mechanizmami wtyczki i kończą się podwójną optymalizacją tych samych zasobów.

Osobne ograniczenie dotyczy object cache: w katalogu wp-content działa tylko jeden drop-in object-cache.php, więc równoległa wtyczka object cache odpada technicznie. Producent zaleca prowadzenie FlyingPress jako jedynej warstwy cache i optymalizacji – druga wtyczka cache potrafi spowolnić witrynę i podnieść obciążenie serwera.

Najczęściej zadawane pytania