Po co używać zaleceń z HTTP/1, skoro mamy już HTTP/3?
Jak zwiększyć szybkość na stronie?

Co zyskałem, przechodząc na koncepcje stojące za HTTP/2 / HTTP/3?

Zarządzam niemal 170 domenami. W indeksie Google mam blisko 300 tysięcy zaindeksowanych podstron. To łączna suma stron ze wszystkich domen i trzeba przyznać, że robi ona wrażenie. Nikogo, więc nie powinno dziwić, że szukam usprawnień. Dzięki zastosowanym przeze mnie rozwiązaniom:

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

Opiszę moje doświadczenia z perspektywy agencji, która utrzymuje strony klientów. Rozwiązania te można też zastosować na shared hostingu.

Ale przejdźmy już do konkretów, bo to one są najciekawsze. W skrócie – nadszedł już czas by porzucić wytyczne dla HTTP/1 i realnie przyspieszyć swoje strony.

 

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

Strony już od dawna nie są statycznymi wizytówkami. To zdecydowanie za mało. Teraz to interaktywne sklepy, portfolia, kalendarze rezerwacji i aplikacje do zarządzania.

Wszystko ma być eleganckie, proste i szybkie. Przy okazji musi też być świetnie pełnić swoje funkcje i być przystępne dla użytkowników. Głównym zadaniem strony jest wyróżnienie Ciebie i Twojego produktu na tle konkurencji. Strona powinna też opowiadać jakąś ciekawą historię, być inspiracją i przyciągać nowych odbiorców.

Cały marketing opiera się na tym, że to uczucia sprzedają. Oznacza to, więc że dobrze przygotowana oferta powinna przemawiać do emocji. W tym celu można wykorzystywać dobrodziejstwo techniki: filmy wideo, zdjęcia w dużej rozdzielczości, animacje. Te elementy wypierają arkusze tekstów, które na ich tle wydają się po prostu nudne.

Strony internetowe nie przypominają już tych sprzed 10 lat. Teraz to bardziej mini aplikacjami z ładnym frontem i skomplikowaną logiką biznesową w tle.

Mamy coraz bardziej elastyczne narzędzia!

Prawdziwą sztuką jest zamknięcie wspomnianej już skomplikowanej logiki biznesowej i strategii marketingowej w estetycznej i równocześnie intuicyjnej stronie. W tym celu należy korzystać z odpowiednio dobranych narzędzi.

Muszą być na tyle elastyczne, by sprostać różnym projektom, które będziesz wykonywał. Narzędzia te muszą też być na tyle uniwersalne, by dostarczać Ci wiele możliwości. Dzięki nim skomplikowane rzeczy możesz przedstawiać w sposób prosty i estetyczny. Taki, który nie odstrasza użytkowników.

Tę elastyczność daje nam właśnie WordPress. DIVI dodaje do niej walory wizualne.

Ten duet jest niezastąpiony, bo pozwala stworzyć coś funkcjonalnego i gustownego i to w krótkim czasie. Dzięki zdjęciom w wysokiej jakości, czcionkom, zabawie kolorami i odcieniami, animacjom i funkcjom interaktywnym zdobędziesz zainteresowanie użytkownika swoim produktem i historią firmy. 

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

Ile Twoim zdaniem funkcji ma Excel? Ponad 750. Ilu z nich używasz? 20? 30? A może mniej? W takim razie, po co jest ich aż tak dużo? Cóż… każdy korzysta z innych 20 funkcji. Te, które są dla Ciebie niezbędne, przez kogoś innego w ogóle nie są stosowane. Wszystko zależy od indywidualnych potrzeb.

Podobnie jest z WordPress i DIVI. 

Oferują Ci ogromną ilość funkcji, ale zwykle używasz tylko części z nich. 

Możesz używać zdjęć, fontów, CSS, animacji, JavaScript i wiele więcej. Ale pamiętaj, że nic nie jest za darmo. Ceną za elastyczność oraz dużą ilość dostępnych funkcji jest waga, oraz ciężar strony.

Technologia idzie do przodu i rozwiązuje ten problem.

Czemu twórcy nic z tym nie zrobią?

A co mają zrobić? Tutaj nie ma nic do naprawy. Wszystko jest w porządku.

Wyobraź sobie, że WordPress i DIVI to szwedzki stół, z którego możesz wybierać to, czego aktualnie potrzebujesz. Tak skomponowany ToolBox, to unikatowy zestaw narzędzi, który pomoże Ci w pracy. Jest on w pełni dopasowany do Twoich potrzeb.

Pamiętaj, że optymalizujesz efekt, a nie samo narzędzie.

Jak na zwyczajnej stronie zadbać o szybkość?

  • Punktem wyjścia jest określenie miary, która pomoże ocenić, czy problem nas dotyczy. 
  • Bez miary nie sprawdzimy, czy robimy jakieś postępy. Nie dowiemy się też, w którą stronę one się przesuwają.
  • Bez wspólnej miary, każdy może mieć inne wnioski z tych samych obserwacji.
  • Przyjąłem ograniczenie, że miary i rozwiązania mają być 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.
Tyle że Yslow ostatnią aktualizację miał 6 lat temu, co jest równoznaczne z tym że nie uwzględnia on niczego, co powstało w ostatniej dekadzie.

Przede wszystkim nie uwzględnia on zmian w budowie stron. Z pełnego renderowania po stronie serwera przeszły one na przerzucanie dużej ilości obliczeń na użytkownika, co jest pewną nowością. Przynajmniej dla Yslow.

Opieranie się o stare wytyczne z HTTP/1 jest błędne. Wynika to z założenia, ż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, więc jednym połączeniem możemy dostarczyć wiele plików.

- Pomiar czasu zapytań to czynnik ważny połowicznie. Jasne, że szybsze dostarczanie elementów strony jest istotne. Jednak nie należy pomijać tego, co to za elementy, jak są one dostarczane i w którym miejscu strony są one usytuowane. Zignorowanie tego zakłamuje wynik. Pomyślmy spokojnie. Czy użytkownik, który może czytać artykuł, przejmie się tym, że zdjęcie w stopce wczytuje się zbyt wolno? Nie. Najprawdopodobniej nawet tego nie zauważy. Nie powinno, więc w żaden sposób wpływać to na ocenę.

Sprawdziany tego typu są wygodne. Bardzo łatwo je oszukać i uzyskać wynik, który będzie korzystny.

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. Wynik jest po prostu zakłamany i nie oddaje rzeczywistości.

 

Zaraz opiszę 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

Biorąc pod uwagę wymagania, jakie są stawiane przez klientów zlecających tworzenie stron oraz przykładów z retro testami, widzisz już, że nie należy działać w sferze cyfr i pomiarów laboratoryjnych.

Powinieneś działać w sferze odczuć użytkownika. 

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

Które „odczucia” warto mierzyć?

Time to first byte. TTFB. To czas, który jest liczony od wysłania przez klienta prośby aż do momentu odebrania pierwszego bajtu odpowiedzi na nią. TTFB daje realny obraz sprawności realizowania próśb użytkownika. Czas ten zawiera w sobie czas podróży pytania i odpowiedzi oraz to, jak szybko przygotowano odpowiedź. W tym pomiarze nie gra roli wielkość samej odpowiedzi. Bez różnicy, czy wysyłasz 0,1 KB wiadomości w komunikatorze, czy 1 GB filmu wideo. Ważne jest tylko to, jak szybko zareagowałeś na prośbę użytkownika i to, że na jego ekranie już coś się dzieje.

DOM Content Loaded DCL to czas ładowania i przetwarzania odpowiedzi HTML. Przeglądarka przeanalizowała i stworzyła model DOM strony. Bez arkuszy stylów, obrazów, iframe, JavaScript. To tylko początkowa analiza tego, co jest jeszcze do zrobienia. Pomiar ten bierze pod uwagę analizę kodu HTML. Liczy się łatwość przetworzenia na DOM, a nie wielkość w KB.

First Meaningful Paint – czyli tzw. pierwsze malowanie – To jeden z ważniejszych elementów Heurystyki Nielsena. To widoczna reakcja na podejmowane przez użytkownika działanie. Nie ma znaczenia, co dostarczasz i jaką ma to wielkość. Ważne jest tylko to, jak szybko użytkownik widzi, że jego aktywność sprawia, że na stronie coś się zaczyna dziać. Chodzi o identyfikację, która potwierdza, że poprawnie wykonał jakąś czynność, np. wpisał frazę w wyszukiwarkę.

Time to Interact — Pierwsza interakcja — Ten parametr pokazuje, kiedy można zacząć używać strony. Powiedzmy sobie szczerze – co z tego, że użytkownik widzi już stronę, jeśli nic jeszcze nie może na niej zrobić? Ważne jest, więc by ten czas był możliwie jak najkrótszy.

First CPU Idle — To czas potrzebny urządzeniu do tego, by 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! 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 wyjaśnię, jak łatwo 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 zainstalowany lub dostępny w postaci pluginu we wszystkich przeglądarkach opartych na Chromium.

Standardowo można znaleźć go w Google Chrome oraz Microsoft EDGE. Warto też używać go lokalnie podczas tworzenia strony. Aby uruchomić LightHouse, wciśnij F12 i w DevTools wybierz zakładkę Audits. Ustawienia są tak proste, że nie warto ich tu opisywać. Po zatrzymaniu kursora na wybranej opcji pojawiają się dodatkowe objaśnienia, więc obsługa nie powinna stanowić problemu.

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

W nowych testach najważniejszy jest efekt, jaki wywołuje Twoja strona u użytkownika. Liczy się to, co widzi użytkownik. Pamiętaj o tym, bo to jest kluczowe. 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 niematerialnych emocji i wrażeń do konkretnych miar i rozwiązań. Skupmy się na wrażeniu szybkości strony lub uczuciu jej zamulania. To dwa miejsca, o które musimy szczególnie zadbać.

Szybkość Dostarczania

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

Cache użytkownika

Pierwszym krokiem powinno być korzystanie z Service Workers.

Nie ma szybszego sposobu na dostarczanie treści użytkownikom niż serwer proxy, który jest zainstalowany w przeglądarce. To równocześnie najlepsze rozwiązanie i jedno z najprostszych. Nie chodzi jednak o cache, ale o pełnoprawny serwer proxy, który jest w stanie modyfikować zapytania i odpowiedzi. Service Workers pozwala wyświetlać treści z cache, równocześnie w tle aktualizować je i podmieniać na ekranie. Ten schemat działania pozwala naszej aplikacji na funkcjonowanie, nawet gdy użytkownik jest offline. Wtedy po prostu wyświetlamy stronę z cache. Gdy wróci online, pobrana zostanie nowa treść. Mówiąc prościej, aktualizujemy, to co widzi użytkownik. Staramy się, by w Service Workers mieć jak największy Hit-Rate. Zależy nam na tym, by 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 dość stary i dobrze już poznany system. Każdy plugin i poradnik porusza właśnie ten typ cache. Zasada ich działania opiera się na tym, by utrzymać maksymalny poziom trafień z cache i wysyłać minimalną ilość pytań do serwera. Jest to fallback dla ServiceWorkera. W skrócie: im więcej jest w starym cache przeglądarki, tym lepiej, bo dane te tworzą pewnego rodzaju zaplecze dla nowszych rozwiązań.

Podsumujmy, więc zyski:

  • Cache po stronie użytkownika sprowadza Time to first byte niemal do zera. 
  • DOM Content Loaded spada, co też jest w naszym interesie. 
  • Analiza HTML zaczyna się bez oczekiwania 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 wysyłamy zapytanie do serwera. 

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

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

HTTP/2 jest już od 5 lat oficjalnie uznawane za standard. Jego pierwowzór SPDY był w Internet Explorer 11,  FireFox 11, Opera 12. Bez obaw możesz, więc stosować go w swoich projektach.

Skupmy się na teraz nowościach.

 

HTTP/2 push to nowe wcielenie EDGE Side Includes

Serwer lub CDN może dynamicznie doklejać dodatkowe elementy do podstawowej odpowiedzi wysyłanej na prośbę 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 właśnie jest cicha rewolucja!

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

Koniec konkatenacji, doklejania CSS w head itp.

Rozbudowujemy naszą stronę w sposób progresywny. Wysyłamy siecią tylko to, co jest niezbędne. Żadnych dodatków. Żadnych bajerów. Użytkownik może sobie działać, a w tle przygotowujemy się na kolejne kroki. Oznacza to mniej danych do transferu, mniej danych do kompresji na serwerze, mniej danych do dekompresji i analizy u użytkownika. Mniej do trzymania w cache na serwerze.

Podejście DRY (Don't Repeat Yourself) wyjaśnimy sobie później.

request http new vs repeat

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

Pierwsza i trudniejsza opcja to pytania, które przechodzą przez Service Workers. Mogą one dodawać 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 albo masz ustawione cookie techniczne np. „MAM-JUZ-CSS”, to jesteśmy już w domu i pewnie wiesz, co trzeba z tym zrobić.

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

Jeśli niepoprawnie zidentyfikujesz użytkownika, który powraca i ma on pusty cache, a Ty nie dodasz push, to wszystko zadziała po staremu. Po prostu brakujące elementy dociągnie sobie sama przeglądarka. Nic się nie popsuje.

Błędem jest jednak dodawanie zawsze, wszędzie i wszystkiego w push. Za każdym razem wysyłasz ogromną ilość zbędnych danych. 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 pewnego rodzaju marnotrawstwo.

W push chodzi o progresywne dołączanie niezbędnej paczki elementów i niczego więcej.

 

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.
Wracającym użytkownikom na prośbę o HTML wysyłamy wyłącznie HTML.

Mając serwer lub CDN z HTTP/2, lub HTTP/3 niewłaściwe jest dodawanie przez wtyczki typu Autooptimize wszystkiego w head. Po co wysyłać, kompresować, dekompresować i analizować za każdym razem wszystko? To strata czasu i transferu. Zależy nam na tym, by tego uniknąć.

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 przez TCP sprawia, że serwer musi za każdym razem czekać na odpowiedź z potwierdzeniem otrzymania poprzedniej paczki danych. Dopiero później wysyła następną. Jeśli jedna paczka zostanie utracona, to mamy pewne komplikacje. Odbiorca TCP wstrzymuje wysyłkę kolejnych pakietów. Aplikacja musi zaczekać na retransmisję. Nie może w tym czasie zająć się obsługą żadnych innych pakietów. Mówiąc prościej – HTTP/1.1 oraz HTTP/2 to rozmowa, w której nie wyślesz kolejnej wiadomości, dopóki rozmówca nie potwierdzi poprawnego odczytania poprzedniej. Trochę jak z rozmową przez krótkofalówkę, w której czasie każda wypowiedź kończy się słynnym „over”.

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

Nowość pojawia się w HTTP/3. W tym wypadku proces ładowania strony będzie trwał, jedynie uszkodzony element jest ponownie pobierany.

Z HTTP/3 będziemy mieli multipleksowanie wysyłki wielu plików bez blokowania nagłówka. Minimalizuje to zatory i powtórzenia transmisji. Skutkiem jest krótszy czas 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 dodał wsparcie 4 października 2019.

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

Nowy protokół sprawdzi się także w przypadku urządzeń mobilnych. W ich wypadku musimy wziąć pod uwagę zmiany sieci GSM i WiFi. W tej chwili zmianie IP towarzyszy zerwanie połączenia i nawiązanie go na nowo. W HTTP/3 protokół zajmuje się ciągłością połączenia, a użytkownik przegląda strony, nie zawracając sobie głowy zmianami sieci.

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

response cache priority

2 - TTFB - Response Cache priority

Szybkość Analizy i przetwarzania

Wyjaśniliśmy już sobie szybkość, z jaką dostarczane są 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.

W praktyce nie mamy wpływu na jakość urządzeń końcowych. Każdy dysponuje innym sprzętem. Mamy różne modele, a co za tym idzie mamy różne modemy WiFi/GSM, różne wyświetlacze, różne procesory CPU + GPU.

W LightHouse te różnice są minimalizowane poprzez 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 uznaje łatwość przetworzenia kodu HTML na Document Model Object.

W First Meaningful Paint ważne jest, po jakim czasie użytkownik widzi 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 rzeczywiście można zacząć używać strony. Zależy to od połączenia dwóch wspomnianych już miar oraz 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 jest zależna od poprzedniej.

analiza dom cssom

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ł, które opisując sposób położenia dowolnego elementu na stronie. Ta elastyczność owocuje pokaźnym kodem HTML i plikami CSS. Taka ilość danych jest niestety ceną elastyczności. W większości przypadków na stronie używamy tylko ok. 20% tych reguł. Pozostałe 80% to zbędny kod, który użytkownik musi pobrać i przeanalizować.

Jak optymalizować DOM i CSSOM w DIVI?

optymalizacja dom 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

Tworząc personalizowaną skórkę zawsze warto korzystać z narzędzi typu uncss, purgecss. To właśnie one optymalizują kod.

W innych przypadkach lepiej użyć pluginów do WordPress typu WPTypek Performance plugin. Chodzi o to, by oczyścić nasz wynikowy kod HTML i CSS. Pozostawienie tylko tych rzeczywiście wykorzystywanych 20% reguł zdecydowanie zmniejsza czas potrzebny do analizy HTML i CSS.

Delta. Minimalny plik do przeliczenia

W DIVI sprawa jest prosta. Wyłączamy wszystko, czego nie używamy. Wcale nie wpływa to na funkcjonowanie samego narzędzia. Nawiasem mówiąc, WordPress też dodaje wiele zbędnych atrybutów class do kodu HTML.

Wszystkie Page Buildery, takie jak DIVI mają swój uniwersalny kod.general css database

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

Moja strona internetowa wykorzystuje cookies (ciasteczka). Dowiedz się więcej o celu ich używania i zmianie ustawień cookies w przeglądarce.

Korzystając ze strony wyrażasz zgodę na używanie cookie, zgodnie z aktualnymi ustawieniami przeglądarki.

Aby dowiedzieć się więcej przeczytaj Politykę prywatności zgodną z RODO (GDPR).