Narzędzie jak z epoki kamienia łupanego, czy nowe technologie?

Przestań używać zaleceń z HTTP/1, przecież mamy już HTTP/3.
Jak na zwykłej stronie zadbać o szybkość?

Co zaoszczędziłem, a co zyskałem, przechodząc na koncepcje stojące za HTTP/2 / HTTP/3?

Pod swoją opieką mam 168 domen. W indeksie Google to aż 290.640 zaindeksowanych podstron. To łączna suma stron ze wszystkich domen. Jest ich na tyle dużo, że musiałem poszukać rozwiązań, które pozwolą na pewne oszczędności. Dzięki nim:

  • Zmniejszyłem zapotrzebowanie serwera na RAM o 13 GB.
  • Zaoszczędziłem ok. 150 GB miesięcznie na transferze.

Rozwiązania te omawiam z perspektywy agencji, która utrzymuje strony klientów. Jednak sposób ten można wdrożyć też na shared hostingu.

Najwyższy już czas, by przestać słuchać starych zaleceń testów opartych o wytyczne dla HTTP/1 i faktycznie przyspieszyć swoje strony.

Wymagamy coraz więcej od stron – ładniej, szybciej, więcej

Strony nie są już nieruchomymi wizytówkami.

Teraz pełnią wiele funkcji. To sklepy, kalendarze rezerwacji, aplikacje do zarządzania.

Każda z nich ma być ładna, szybka i przede wszystkim – funkcjonalna.

Najlepiej, by była też przyjazna użytkownikom. Tak, by obsługa była, jak najprostsza.

Podstawowym zadaniem strony jest to, by wyróżniała Ciebie i Twój produkt na tle konkurencji.

Oznacza to, że ma ona opowiadać historię, inspirować, wciągać i pochłaniać użytkowników.

Jeśli znasz się na marketingu, to pewnie wiesz, że to uczucia sprzedają. Zadaniem oferty jest, więc przemawianie do emocji. W tym celu wykorzystuje się wideo, zdjęcia w dużej rozdzielczości i animacje. Ostatecznie wypierają one arkusze tekstów.

Strony internetowe nie są już takie jak były 10 lat temu… a za następnych 10 lat nie będą w niczym przypominać dzisiejszych stron.

W tej chwili są czymś w rodzaju mini aplikacji z ładnym frontem i dość skomplikowaną logiką biznesową.

Mamy coraz elastyczniejsze narzędzia

No właśnie. Prawdziwą sztuką jest obudowanie wspomnianej już skomplikowanej logiki biznesowej przy pomocy estetycznego opakowania, czyli ładnej i intuicyjnej strony.

Jednak nie zaprojektujesz pięknej i funkcjonalnej strony bez odpowiednich narzędzi. 

Muszą one być na tyle elastyczne, by sprostać różnym projektom, które musisz przecież realizować szybko i sprawnie. Narzędzia te muszą, więc dostarczać Ci możliwości, które pozwolą Ci skomplikowane rzeczy przedstawiać w sposób przystępny dla użytkownika. Powinien on też być możliwie elegancki z perspektywy odbiorcy.

Tę elastyczność ofertuje nam WordPress. Piękno daje DIVI. Jak łatwo się domyślić, na tym duecie można oprzeć projekty, które mają zachwycać użytkowników. Dzięki nim możesz skorzystać z pięknych zdjęć w wysokiej jakości, fontów, gry kolorów, animacji i interaktywności. To właśnie tym możesz zainteresować użytkowników (potencjalnych klientów) oferowanym produktem i historią firmy. 

Elastyczne narzędzia, które zwiększają „ciężar strony”

Jak się pewnie domyślasz elastyczność narzędzi ma swoją cenę. Jest nią zwiększony ciężar strony. O co w tym chodzi?

Otóż, arkusze kalkulacyjne takie jak Excel mają w sumie ponad 750 funkcji, ale używasz około 20 z nich. Po co w takim razie jest tam kolejne 730 innych funkcji? Ano dlatego, że każdy z nas używa 20 innych funkcji. Jak, więc wybrać te niepotrzebne i do usunięcia? Po prostu nie można tego zrobić.

Podobnie jest z WordPress i DIVI. 

Oferują Ci wiele funkcji, ale najprawdopodobniej używasz tylko części z nich. Nie korzystasz z ich potencjału w pełni. Możesz wstawiać: zdjęcia, fonty, CSS, animacje, JavaScript i wiele więcej. Właśnie. Jednak ceną za tę elastyczność i ogrom możliwości jest waga oraz ciężar strony.

Nowe technologie mogą pomóc rozwiązać ten problem.

Czemu twórcy tego nie poprawią?

Bo tu nie ma nic do naprawy. Nic nie jest zepsute albo niewłaściwie zrobione.

Potraktuj WordPress i DIVI jak szwedzki stół. Ty decydujesz na, co masz ochotę.

Tak stworzony ToolBox, to zestaw narzędzi, który pomaga Tobie (i tylko Tobie) w pracy. Jest dostosowany do Twoich potrzeb.

Zestaw pełen elastyczności i możliwość kreacji, z opcją dostrojenia i personalizacji narzędzi pod kątem własnych upodobań i wymagań.

Optymalizuje się efekt, a nie narzędzia same w sobie.

Jak na zwykłej stronie zadbać o szybkość?

  • Punktem wyjścia jest określenie miary, przy pomocy której ocenimy czy problem rzeczywiście nas dotyczy. 
  • Bez miary nie sprawdzimy, czy w ogóle robimy postępy. Potrzebny jest jakiś punkt odniesienia.
  • Bez wspólnej miary, każdy z nas może mieć inne wnioski z tych samych obserwacji. To powoduje chaos.
  • Narzuciłem sobie ograniczenie, by miary i rozwiązania były możliwe do zastosowania przez freelancera lub pracownika agencji bez specjalnych wymagań serwerowych.

HTTP/1 – retro testy i retro zalecenia.

Stare testy oparte o Yslow czy curl, ograniczają się do pomiarów czasów, ilości połączeń i wielkości pliku.
Tylko że Yslow ostatni raz był aktualizowany 6 lat temu. Siłą rzeczy nie uwzględnia on niczego, co powstało od tego czasu.

Przede wszystkim nie uwzględnia on zmian w budowie stron internetowych. Strony z pełnego renderowania po stronie serwera przeszły na przerzucanie dużej ilości obliczeń na użytkownika.

Opieranie się o stare wytyczne z HTTP/1 jest niepoprawne. Wynika to z założeń, że:

– Przesłanie 1 KB jest lepsze niż 1 MB. Tylko czy na pewno 1 KB skrypt z nieskończoną pętlą, zabijający CPU jest lepszy niż 1 MB zdjęcie?

– Ilość równoczesnych pobierań na domenę ograniczona jest do 8. Dostajemy zalecenia o sub-domenach i CDN, żeby obejść limit HTTP/1, gdy mamy HTTP/2 i jednym połączeniem możemy dostarczyć wiele plików.

– Pomiar czasu zapytań jest ważny tylko połowicznie. Szybsze dostarczanie elementów strony jest ważne. Jednak zignorowanie tego, które elementy jak są dostarczane i w którym miejscu są usytuowane, zakłamuje otrzymywany wynik. Jeśli użytkownik może czytać artykuł to wolne wczytywanie się zdjęcia w stopce, nie powinno wpływać na ocenę. Przecież użytkownik nawet go nie widzi.

Tego typu testy są wygodne, bo łatwo je oszukać.

Nie uwzględniając nowych standardów HTML 5, atrybutów asynchroniczności, HTTP/3 czy typów plików np. webp — localhost zawsze wygra z online. Statyczny plik zawsze wygra z PHP. 

Można uzyskać 100% punktów, mimo że na urządzeniu, z małą ilością RAM, ze słabym CPU albo bez wsparcia GPU, strona może nie nadawać się do użytku. Co z tego, że test będzie wychodził pozytywnie, skoro w praktyce użytkownik nie będzie mógł korzystać ze strony?  

Za chwilę rozwiniemy przykład z HTTP/2 / HTTP/3 – na razie zapamiętaj, to co najważniejsze:

Stosowanie testów do HTTP/1 w czasach HTTP/3, to oszukiwanie siebie i klienta.

Nowy sposób mierzenia optymalizacji

Mając na uwadze wymagania, jakie klienci stawiają przy zlecaniu projektu strony oraz do przykładów z retro testami chciałbym udowodnić, że nie powinno się działać wyłącznie w sferze cyfr i pomiarów laboratoryjnych. Bardziej liczy się działanie w sferze odczuć użytkownika. 

Nie bez powodu mówimy o wrażeniu szybkości strony i uczuciu, że strona przycina lub zamula.

Zatem, które „odczucia” dobrze jest mierzyć?

Time to first byte. TTFB. To czas, który liczy się od wysłania przez klienta prośbt do momentu odebrania pierwszego bajtu odpowiedzi na nią. Daje nam rzeczywisty obraz sprawności realizowania próśb użytkownika. Czas ten zawiera w sobie czas podróży pytania i odpowiedzi oraz to, jak szybko przygotowano samą odpowiedź. W tym pomiarze nie uwzględnia się wielkości odpowiedzi. To nie ma znaczenia, czy wysyłasz 0,1 KB wiadomości w komunikatorze, czy 1 GB filmu wideo. Ważne jest tylko to, że szybko zareagowałeś na prośbę użytkownika i u niego już coś się dzieje.

DOM Content LoadedDCL to czas, w którym jest ładowana i przetwarzana odpowiedź HTML. Przeglądarka już przeanalizowała i stworzyła model DOM naszej strony, ale bez arkuszy stylów, obrazów, iframe, JavaScript. To też pierwsza analiza, której efektem jest informacja, co jeszcze jest do zrobienia. Pomiar ten uwzględnia analizę kodu HTML. Liczy się łatwość przetworzenia na DOM, a nie wielkość w KB.

First Meaningful Paint– Pierwsze malowanie – Należy do ważniejszych elementów Heurystyki Nielsena. To widoczna reakcja na podjęte przez użytkownika działanie. Nie ma znaczenia, co dostarczasz, ani jaką ma to wielkość. Liczy się tylko to, jak szybko użytkownik widzi, że coś się dzieje. Chodzi o wizualne potwierdzenie tego, że dobrze wpisał.

Time to Interact— Pierwsza interakcja — Pomiar, który pokazuje, kiedy można zacząć używać strony. Zobaczenie strony to za mało. Istotne jest, to kiedy można podjąć jakąś akcję.

First CPU Idle— Czas, w którym urządzenie może zająć się obsługą użytkownika, a nie obsługiwaniem strony. Interaktywność i płynność działania jest mocno ograniczona, gdy CPU i GPU są zajęte w 100%.

UWAGA! Zauważ, że testy te różnią się od testów dla HTTP/1 tym, że dodano pomiary czasów przetwarzania elementów. W nowych testach liczy się efekt, jaki wywołuje Twoja strona u użytkownika. Analiza i przetworzenie HTML, CSS, JavaScript jest równie ważne, jak szybkość ich dostarczania.

Poniżej opiszę, jak prosto poprawić każdą z tych miar.

Na końcu pokażę, co w tych wszystkich miarach poprawia nam HTTP/2  i HTTP/3.

Jak użyć LightHouse?

LightHouse jest wbudowany lub dostępny w postaci pluginu we wszystkich przeglądarkach opartych na Chromium.

Standardowo zainstalowano go w Google Chrome oraz Microsoft EDGE. Warto używać go lokalnie w czasie tworzenia strony. Aby uruchomić LightHouse, wciśnij F12 i w DevTools wybierz zakładkę Audits. Ustawienia są tak proste, że nie będę ich opisywał w tym artykule. Nad każdą opcją mamy dodatkowe objaśnienia. Wystarczy zatrzymać na niej kursor myszki.

Google PageSpeed to narzędzie online, oparte o LightHouse, które oprócz testu pokazuje nam dodatkowo wyniki zebrane od realnych użytkowników strony. https://developers.google.com/speed/pagespeed/insights/

Nowy sposób optymalizacji

Powtórzę to, co jest najważniejsze. W nowych testach liczy się efekt, jaki wywołuje Twoja strona u użytkownika. Analiza i przetworzenie HTML, CSS, JavaScript jest równie ważne, jak szybkość ich dostarczania. Postarajmy się teraz na podstawie wyniku z LightHouse przejść z mglistych uczuć i wrażeń do konkretnych miar i rozwiązań, gdy mówimy o wrażeniu szybkości strony lub uczuciu zamulania. Co z tym zrobić?

Szybkość Dostarczania

Szybkość dostarczania to HTTP/1. Jest to część, która jest najstarsza i najlepiej dopracowana przez społeczność WordPress. Omówimy, więc różnice i nowości w HTTP/2 i HTTP/3.

Cache użytkownika

Na początek warto zacząć korzystać z Service Workers.

Nie ma szybszego i lepszego sposobu na dostarczanie treści użytkownikom niż serwer proxy zainstalowany w przeglądarce. Nie chodzi o cache, ale o pełnoprawny serwer proxy, który może modyfikować zapytania i odpowiedzi. Service Workers pozwala nie tylko wyświetlać treści z cache, ale umożliwia aktualizować je w tle i podmieniać na ekranie. Ten wygodny schemat działania pozwala aplikacji na funkcjonowanie, nawet gdy użytkownik aktualnie nie ma jest podłączony do Sieci. Stronę wyświetlamy z cache, a gdy wróci w online, możemy pobrać nową treść i aktualizować, to co widzi użytkownik. Warto starać się, by w Service Workers mieć jak największy Hit-Rate. Mówiąc prościej, chcemy jak najwięcej rzeczy mieć przygotowanych i wstępnie wczytanych do cache. Service Workers to nowy rodzaj cache, który daje nam nad nim pełnię władzy. Service Workers zastępuje AppCache i cache przeglądarki. 

Cache przeglądarki to stary i dobrze opisany system. Każdy plugin i poradnik porusza właśnie ten rodzaj cache. Zasada ich funkcjonowania jest banalnie prosta: jak największy poziom trafień z cache i jak najmniej pytań wysyłanych do serwera. Jest to fallback dla ServiceWorkera. W skrócie: im więcej jest w starym dobrym cache przeglądarki, tym lepiej.

Podsumujmy, więc zyski:

  • Cache po stronie użytkownika sprowadza Time to first byte prawie do zera. 
  • DOM Content Loaded drastycznie spada. 
  • Analiza HTML zaczyna się bez czekania na sieć. 
  • Jeśli pozostałe elementy strony są w cache użytkownika, również zmniejszamy pierwsze malowanie i Time to Interact oraz czasy przesyłu przez sieć.
HTTP/2 / HTTP/3

Jeśli nie mamy potrzebnego elementu w cache użytkownika, to musimy zapytać o to serwer. 

Ma to miejsce, gdy Service Workers i Cache przeglądarki nie mają odpowiedzi.

Im szybciej odpowiemy, tym lepiej. Idealnie, gdyby CDN lub serwer był blisko użytkownika i zawierał gotową odpowiedź, a całość działa się z wykorzystaniem magii HTTP/2 lub HTTP/3.

HTTP/2 już od 5 lat jest oficjalnym standardem, a jego pierwowzór, czyli SPDY był już w Internet Explorer 11,  FireFox 11, Opera 12. Bez obaw możesz używać go w swoich projektach.

Przejdźmy teraz do ciekawszej części – do nowości.

HTTP/2 push to nowe wcielenie EDGE Side Includes

Serwer lub CDN może dynamicznie doklejać nowe elementy do podstawowej odpowiedzi już w czasie odbierania prośby o stronę.

Push najczęściej używa się do doklejania CSS do HTML, ale TYLKO wtedy, gdy użytkownik nie ma naszego CSS.

I tu jest cicha rewolucja!

Koniec łączenia plików w mega-paczki.

Koniec konkatenacji, doklejania CSS w head itp.

Progresywnie rozbudowujemy naszą stronę. Wysyłamy siecią tylko to, co jest niezbędne. Użytkownik może sobie działać i robić swoje. W tle przygotowujemy się na kolejne kroki. Podsumowując mamy mniej do transferu, mniej do kompresji na serwerze, mniej do dekompresji i analizy u użytkownika, no i mniej do trzymania w cache na serwerze.

1 – HTTP/2 push – response zależne od pytającego

Podejście DRY (Don’t Repeat Yourself), które objaśnię później, jak już poznamy kolejne elementy.

Skąd wiemy, że użytkownik ma już CSS?

Pierwsza i trudniejsza opcja to pytania przechodzące przez Service Workers mogą dodawać dodatkowe nagłówki do zapytań np. X-MAM-JUZ-CSS = true.

Najprościej w Apache2 / nginx / CDN sprawdzić nagłówek „referer” oraz „cookies techniczne”. 

Jeśli referer to Twoja domena lub mamy ustawione cookie techniczne np. „MAM-JUZ-CSS” myślę, że wiesz, co trzeba zrobić. 

Czy można popełnić tu błąd?

Jeżeli pomylisz się, niewłaściwie rozpoznasz wracającego użytkownika i ma on pusty cache, a Ty nie dodasz push, to nie ma czym się przejmować. Wszystko zadziała po staremu — brakujące elementy dociągnie sobie przeglądarka. Nic się nie zepsuje, wszystko będzie jak zawsze.

Niewłaściwe jest jedynie dodawanie zawsze, wszędzie i wszystkiego w push. W takim przypadku za każdym razem wysyłasz ogromną paczkę zbędnych rzeczy, które niepotrzebnie obciążają łącza. Dodawanie zawsze push z czcionkami, CSS, JavaScript doklei do każdego zapytania te elementy, nawet jak użytkownik pyta o logo, obrazki, robots.txt, API… To nie ma żadnego sensu.

W push chodzi o progresywne dołączanie najmniejszej, niezbędnej paczki elementów.

HTTP/2 push daje nam możliwość reagowania na to „kto pyta”

Nowym użytkownikom na prośbę o HTML dodajemy HTTP/2 push i wysyłamy HTML i doklejamy CSS, JavaScript, skrypt Service Workers, manifest.
Powracającym użytkownikom na prośbę o HTML wysyłamy tylko i wyłącznie HTML.

Mając serwer lub CDN z HTTP/2, lub HTTP/3 błędem jest dodawanie przez wtyczki typu Autooptimize wszystkiego w head. Po co wysyłać, kompresować, dekompresować i analizować za każdym razem wszystko?

Pamiętaj, że HTTP/2 push nie dotyczy tylko zapytań o HTML.
Nic nie stoi na przeszkodzie, żeby do prośby o CSS wysłać np. dodatkowy plik CSS z animacjami fontów i samą czcionkę woff2.

HTTP/3, bo HTTP/2 był już za wolny

HTTP/1.1, jak i HTTP/2 korzystają z protokołu TCP jako warstwy transmisyjnej. Mamy jeszcze warstwę UDP.

Komunikacja poprzez TCP powoduje, że serwer musi zaczekać na odpowiedź z potwierdzeniem otrzymania poprzedniej paczki danych. Nie może wysłać kolejnej, dopóki nie otrzyma potwierdzenia, że poprzednia dotarła. Jeśli jedna paczla zostanie utracona to odbiorca TCP wstrzymuje wszystkie kolejne pakiety. W takim wypadku aplikacja musi zaczekać na retransmisję – nawet jeśli mogłaby w tym czasie obsłużyć inne pakiety. Mówiąc bardziej obrazowo – HTTP/1.1 oraz HTTP/2 to jest rozmowa, w której nie wyślesz kolejnej wiadomości, dopóki rozmówca nie potwierdzi poprawnego odczytania poprzedniej.

Obecnie, jeśli w czasie przesyłania danych wystąpi błąd, to protokół HTTP/1 i HTTP/2 zatrzymuje całe ładowanie strony.

W HTTP/3 proces ładowania strony będzie trwał, a uszkodzony element jest po prostu pobierany od nowa.

Z  HTTP/3 będziemy mieli multipleksowanie wysyłki wielu plików bez blokowania nagłówka. Mniej będzie zatorów i powtórzeń transmisji. Efektem jest skrócenie czasu nawiązywania połączenia.

Wyniki testów z HTTP/1 staną się w takich realiach całkowicie nieadekwatne.

Kiedy to zacznie działać?

Mozilla i Chrome już testują HTTP/3. Microsoft w EDGE 4 października 2019 dodał wsparcie.

Najpopularniejsze przeglądarki planują aktywować HTTP/3 w 2020 r.

Nowy protokół lepiej sprawdzi się również w przypadku urządzeń mobilnych, gdzie przełączamy się między różnymi nadajnikami sieci GSM i WiFi. Na razie zmiana IP powoduje zerwanie połączenia. Trzeba, więc nawiązać je na nowo. W HTTP/3 protokół zajmuje się ciągłością połączenia, a my przeglądamy strony, tak jakby nic się nie zmieniło.

Podsumowując:
  • Dążmy do tego, aby mieć gotowe odpowiedzi na prośby użytkownika.
  • Wstępnie przygotowane odpowiedzi trzymajmy jak najbliżej użytkownika.
  • HTTP/2 push to podejście blokowe. Przechowujemy i przesyłamyniezbędne minimum.
  • HTTP/2 push to możliwość wysłania wielu plików w odpowiedzi na jedno zapytanie.

2 – TTFB – Response Cache priority

Szybkość Analizy i przetwarzania

Mamy już omówioną szybkość dostarczania treści do użytkownika. Tutaj kończą pracę stare testy  HTTP/1, ale nie LightHouse. Wiemy, że narzędzie od Google mierzy efekt,jaki wywołuje nasz kod na urządzeniu użytkownika. To ważne, bo nie mamy żadnego wpływu na jakość urządzeń końcowych, na których jest wyświetlana strona. Korzystamy z różnych modeli i sprzętów, a co za tym idzie różne są modemy WiFi/GSM, różne wyświetlacze, różne procesory CPU + GPU.

W LightHouse te różnice są minimalizowane przez narzucenie ograniczeń (trhottling) na połączenie i CPU.

Co łączy te 3 miary?

  • DOM Content Loaded 
  • First Meaningful Paint
  • Time to Interact

DOM Content Loaded wlicza łatwość przetworzenia kodu HTML na Document Model Object.

W First Meaningful Paint istotne jest to, jak szybko użytkownik może zobaczyć pierwsze elementy na stronie. Zawiera to w sobie przetworzenie kodu CSS na CSS Model Object oraz połączenia go z Document Model Object.

Time to Interact wskazuje, po jakim czasie można zacząć używać strony. Tutaj zależy to od połączenia dwóch poprzednich miar i tego, jak JavaScript:

  • intensywnie używa obliczeń CPU,
  • jak głębokich zmian dokonuje w DOM i CSSOM.

Wszystkie 3 miary łączy szybkość, z jaką silnik przeglądarki przetwarza kod na Model Object. Łączy je też zależność – każda kolejna zależy od poprzedniej.

3 – Zależność TTFB, DOM Content Loaded, First Meaningful Paint, Time to Interact

Główną zaletą i wadą PageBuilder-ów jest fakt, że zawierają wiele modułów i reguł opisujących sposób umiejscowienia każdego dowolnego elementu na stronie Taka elastyczność łączy się z rozbudowanym kodem HTML i plikami CSS. Jak już wcześniej wspomniałem, jest to cena elastyczności. Po prostu trzeba się z tym liczyć. Jednak w większości przypadków na stronie używamy tylko ok. 20% tych reguł. Pozostaje jeszcze 80% – aż tyle niepotrzebnego kodu musi pobrać i przeanalizować użytkownik.

Jak optymalizować DOM i CSSOM w DIVI?

4 – Zależność First Meaningful Paint od HTML i CSS

Szybsze przeliczanie HTML do DOM oraz CSS do CSSOM uzyskamy na dwa sposoby:

  1. maksymalnie uproszczając kod CSS i HTML;
  2. nieprzeliczanie całego CSS i HTML za każdym razem.
Maksymalne uproszczenie kodu HTML i CSS

Pisząc indywidualną skórkę zawsze używaj narzędzi typu uncss, purgecss. To one optymalizują kod.

W innych przypadkach warto używać pluginów do WordPress typu Wptypek performance. Ich zadaniem jest wyczyszczenie wynikowego kodu HTML i CSS. Pozostawienie tylko tych faktycznie wykorzystywanych 20% reguł drastycznie zmniejszy czas potrzebny do analizy HTML i CSS.

Delta. Minimalny plik do przeliczenia

W DIVI wyłączamy wszystko, czego nie używamy. To proste. Tyle zmian po stronie narzędzia, ale nie stanie się z nim nic złego.

Sam WordPress też dodaje wiele zbędnych atrybutów class do kodu HTML.

Wszystkie Page Buildery takie jak DIVI mają swój uniwersalny kod.

5 – Rozbicie CSS na moduły

Nie stosuj zaleceń sprzed dekady!
Nie buduj mega-paczek. Stosuj progresywne dosyłanie elementów.

Składając wszystko w całość:

  1. Service Workers lub Cache Przeglądarki.
  2. CDN.
  3. Serwer proxy, Varnish, nginx microcache.
  4. Wtyczki WordPress response cache typu: Wptypek performance.
  5. Wtyczki WordPress optymalizujące DOM i CSSOM typu WPTypek Performance.

Artykuł został przygotowany przez: Dawid Rzepczyński @nebuso


Notice: Funkcja WP_Query została wywołana z argumentem, którego użycie jest przestarzałą praktyką od wersji 3.1.0! caller_get_posts jest przestarzałą praktyką. Zamiast tego użyj ignore_sticky_posts. in /home/kant/domains/partnerfirmy.pl/public_html/wp-includes/functions.php on line 4865