Jak pisać na blogu firmowym

Narzędzie z epoki kamienia łupanego kontra nowe technologie.

Przestań używać zaleceń z HTTP/1 – 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.

Zarządzam 168 domenami.
W indeksie Google mam 290.640 zaindeksowanych podstron — suma stron ze wszystkich domen.

Stosując się do poniżej zaproponowanych rozwiązań:

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

Całość pokazuję z perspektywy agencji utrzymującej strony klientów, ale w sposób nadający się do wdrożenia na shared hostingu. 

Zatem przestańmy słuchać zaleceń testów opartych o wytyczne dla HTTP/1 i realnie przyspieszmy swoje strony.

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

Strony dawno przestały być statycznymi wizytówkami. 

Sklepy, kalendarze rezerwacji, aplikacje do zarządzania. 

Wszystko ma być ładne, szybkie, estetyczne. 

Ogromna funkcjonalność w eleganckim i estetycznym opakowaniu. 

Łatwym w obsłudze. Wyróżniającym Ciebie i Twój produkt na tle konkurencji.

Strona ma opowiadać historię, inspirować, wciągać i pochłaniać.

Cały marketing mówi, że uczucia sprzedają, a oferta ma przemawiać do emocji i uczuć. 

Wideo, zdjęcia w dużej rozdzielczości, animacje wypierają arkusze tekstów. 

Strony internetowe nie są takie jak 10 lat temu.

Są mini aplikacjami z ładnym frontem i skomplikowaną logiką biznesową.

Mamy coraz elastyczniejsze narzędzia.

Sztuką jest obudowanie skomplikowanej logiki biznesowej za pomocą ładnej i intuicyjnej strony.

Do tworzenia pięknych i funkcjonalnych stron potrzebujesz odpowiednich narzędzi.  

Na tyle elastycznych narzędzi, aby sprostać różnym projektom. Szybko i sprawnie realizowanym. Dostarczając opcji i możliwości, które pozwolą Ci skomplikowane rzeczy przedstawiać w sposób prosty i elegancki dla użytkownika.

WordPress daje nam elastyczność. 

DIVI dodaje piękno i estetykę. 

Ten duet pozwala szybko stworzyć coś funkcjonalnego i gustownego.

Dzięki pięknym zdjęciom w super jakości, czcionce, grze kolorów i tonacji, animacjom i interaktywności zainteresujesz użytkownika swoim produktem i historią firmy. 

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

Arkusze kalkulacyjne typu Excel mają ponad 750 funkcji.
Prawdopodobnie używasz tylko 20 z tych funkcji. Czemu jest tam aż tyle możliwości?
Bo każdy z nas używa innych 20 funkcji.

Podobnie jest z WordPress i DIVI. 

Otrzymujemy ogrom funkcji, a prawdopodobnie używasz tylko części z nich. 

Zdjęcia, czcionki, CSS, animacje, JavaScript i wiele więcej.

Ceną za elastyczność, ogrom funkcji i możliwości jest waga oraz ciężar strony.

Technologia idzie do przodu i rozwiązuje te problemy. 

Czemu twórcy tego nie poprawią?

Bo tu nie ma co naprawiać, nic nie jest zepsute lub źle zrobione. 

Potraktuj WordPress i DIVI jako szwedzki stół, z którego Ty wybierasz, co potrzebujesz.

Tak stworzony ToolBox, to zestaw narzędzi, który pomaga ci w pracy.

Zestaw pełen elastyczności i możliwość kreacji, dostrojenia i personalizacji narzędzi pod siebie.

Optymalizuje się efekt końcowy, 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 nas dotyczy. 
  • Bez miary nie sprawdzimy, czy robimy postępy.  
  • Bez wspólnej miary każdy z nas może mieć inne wnioski z tych samych obserwacji.
  • Narzuciłem sobie ograniczenie, aby 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.
Pomijając to, że Yslow ostatnią aktualizację miał 6 lat temu to nie uwzględnia on, nic co powstało w ostatniej dekadzie.

Nie uwzględnia 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 błędne, bo założenia, że:

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

– ilości równoczesnych pobierań na domenę ograniczony 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ń. Tutaj połowicznie czynnik jest ważny. Szybsze dostarczanie elementów strony jest ważne. Pomijanie jak są dostarczane elementy, co to za elementy i w którym miejscu są usytuowane, zakłamuje wynik. Jeśli użytkownik może czytać artykuł to wolne wczytywanie się zdjęcia w stopce, którego nie widzi, nie powinno wadzić w pozytywnej ocenie.

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 być nienadająca się do użytku. 

Za chwilę rozwiniemy przykład z HTTP/2 / HTTP/3 – na razie zapamiętaj:

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

Nowy sposób mierzenia optymalizacji.

Odwołując się do wymagań, jakie klienci stawiają nam przy tworzeniu stron oraz do przykładów z retro testami chce pokazać ze nie powinno się działać w sferze cyfr i pomiarów laboratoryjnych. 

Działaj w sferze odczuć użytkownika. 

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

Zatem, które “odczucia” warto mierzyć?

Time to first byte. TTFB. Czas liczony od wysłania przez klienta próśb do momentu odebrania pierwszego bajtu odpowiedzi daje nam realny obraz sprawności realizowania próśb użytkownika. Czas ten zawiera w sobie nie tylko czas podróży pytania i odpowiedzi, ale co ważne, jak szybko przygotowano odpowiedź. W tym pomiarze nie ma nic o wielkości odpowiedzi. Możesz wysyłać 0,1 KB wiadomości w komunikatorze lub 1 GB filmu wideo. Ważne jest to, że szybko zareagowałeś na prośbę użytkownika i u niego już coś się dzieje.

DOM Content Loaded — DCL to czas ładowania i przetwarzania odpowiedzi HTML. Przeglądarka przeanalizowała i stworzyła model DOM naszej strony, bez arkuszy stylów, obrazów, iframe, JavaScript. Jest to też pierwsza analiza, co jest jeszcze do zrobienia. Zauważ, że pomiar uwzględnia analizę kodu HTML. Liczy się łatwość przetworzenia na DOM, a nie wielkość w KB.

First Meaningful Paint. Pierwsze malowanie – Jedno z ważniejszych elementów Heurystyki Nielsena. Widoczna reakcja na działanie użytkownika. Nieistotne jest co i jak dużego dostarczasz. Ważne jak szybko użytkownik widzi, że coś się dzieje, identyfikacja wizualna potwierdza, że dobrze wpisał.

Time to Interact— Pierwsza interakcja — Pomiar pokazujący, kiedy można zacząć używać strony. Co z tego, że użytkownik widzi stronę, jak nic nie może zrobić.

First CPU Idle — Czas, w którym urządzenie może zająć się obsługą użytkownika, a nie obsługiwaniem Twojej strony. Interaktywność i płynność działania jest mocno ograniczona, gdy CPU i GPU trzymasz 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 sobie omówimy, 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 wbudowany lub dostępny w postaci pluginu we wszystkich przeglądarkach opartych na Chromium.

Standardowo zainstalowany jest w Google Chrome oraz Microsoft EDGE. Polecam 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 będę ich omawiał. Po zatrzymaniu myszki nad opcją mamy dodatkowe objaśnienia.

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ę się, bo to jest istotne. 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 uczuć i wrażeń to konkretnych miar i rozwiązań, gdy mówimy o wrażeniu szybkości strony lub uczuciu, zamula. Zatem mamy dwa miejsca, o które musimy zadbać,

Szybkość Dostarczania

Szybkość dostarczania to HTTP/1, dlatego jest najstarszą i najlepiej dopracowaną przez społeczność WordPress częścią.  Skupię się tutaj tylko na różnicach i nowościach w HTTP/2 i HTTP/3.

Cache użytkownika

W pierwszej kolejności powinniśmy 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 nam wyświetlać treści natychmiast z cache w tle aktualizować je i podmieniać na ekranie. Ten sam schemat działania pozwala naszej aplikacji na funkcjonowanie, nawet gdy użytkownik nie ma dostępu do Internetu — pokazujemy z cache, a gdy wróci w online, pobieramy nową treść i aktualizujemy, to co widzi użytkownik. Dążymy do tego, aby w Service Workers mieć jak największy Hit-Rate, czyli chcemy jak najwięcej rzeczy mieć przygotowanych i wstępnie wczytanych do cache.  Service Workers to nowy rodzaj cache, który daje nam pełnię władzy nad tym cache. Service Workers zastępuje AppCache i cache przeglądarki. 

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

Podsumujmy zyski i przejdźmy do ciekawszej części.

  • 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 i czasy przesyłu przez sieć.
HTTP/2 / HTTP/3

Jeśli nie mamy potrzebnego elementu w cache użytkownika, to pytamy 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 magią HTTP/2 lub HTTP/3.

HTTP/2 jest już 5 lat oficjalnym standardem, a jego pierwowzór SPDY był już w Internet Explorer 11,  FireFox 11, Opera 12 więc możesz go śmiało stosować w swoich projektach.

Przejdźmy do nowości.

HTTP/2 push to nowe wcielenie EDGE Side Includes.

Serwer lub CDN. odbierając prośbę o stronę, w locie, do podstawowej odpowiedzi może dynamicznie doklejać dodatkowe elementy.

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ą niezbędne minimum, użytkownik może sobie działać, a w tle powoli przygotowujemy się na kolejne kroki. Mniej do transferu, mniej do kompresji na serwerze, mniej do dekompresji i analizy u użytkownika, mniej do trzymania w cache na serwerze i użytkownika.

Podejście DRY (Don’t Repeat Yourself), które pokażę później, jak 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 źle zidentyfikujesz powracającego użytkownika i ma on pusty cache, a Ty nie dodasz push, to wszystko zadziała po staremu — brakujące elementy dociągnie sobie przeglądarka. Nic się nie zepsuje.

Błędem jest jedynie dodawanie zawsze, wszędzie i wszystkiego w push. W takim przypadku za każdym razem wysyłasz ogromną paczkę zbędnych rzeczy.  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, …

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 sam 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 za każdym razem czekać na odpowiedź, z potwierdzeniem otrzymania poprzedniej paczki danych, zanim wyśle kolejną. Jeśli jeden pakiet zostanie utracony, odbiorca TCP wstrzymuje wszystkie kolejne pakiety, a w rezultacie 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 wiadomości. 

Obecnie jak w trakcie 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 ponownie pobierany.

Z  HTTP/3 będziemy mieli multipleksowanie wysyłki wielu plików bez blokowania nagłówka. Minimalizacja zatorów i powtórzeń transmisji. Skrócenie 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ł 4 października 2019 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ę pomiędzy nadajnikami sieci GSM a WiFi. Obecnie zmiana IP powoduje zerwanie połączenia i wymaga nawiązywania go 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łamy niezbę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. 

Nie mamy wpływu na jakość urządzeń końcowych. Wszyscy mamy różne modele a co za tym idzie 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łeczenie 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 ważne jak szybko użytkownik widzi pierwsze elementy na stronie a to zawiera w sobie przetworzenie kodu CSS na CSS Model Object oraz połączenia go z Document Model Object.

Time to Interact pokazuje po jakim czasie można zacząć używać strony. Tutaj zależy to 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 zawiera mnóstwo modułów i reguł opisujących sposób położenia dowolnego elementu na stronie Taka elastyczność owocuje pokaźnym kodem HTML i plikami CSS. Jak już wcześniej wspomniałem jest to koszt elastyczności.  W większości przypadków na stronie używamy ok 20% tych reguł. 80% – tyle niepotrzebnego kodu musi pobrać i przeanalizować użytkownik.

Jak optymalizować DOM i CSSOM w DIVI?

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

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

  1. maksymalne uproszczenie kodu CSS i HTML
  2. nieprzeliczanie całego CSS i HTML za każdym razem
Maksymalne uproszczenie kodu HTML i CSS

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

W innych przypadkach warto użyć pluginów do WordPress typu Wptypek Performance aby oczyścić nasz wynikowy kod HTML i CSS. Pozostawienie tylko tych faktycznie wykorzystywane 20% reguł drastycznie zmniejsza czas potrzebny do analizy HTML i CSS.

Delta. Minimalny plik do przeliczenia

W DIVI wyłączamy wszystko czego nie używamy. Tyle zmian po stronie narzędzia i tu jest wszystko OK.

Sam WordPress 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
  1. CDN
  2. Serwer proxy, Varnish, nginx microcache
  3. Wtyczki WordPress response cache typu: WPTypek Performance
  4. Wtyczki WordPress optymalizujące DOM i CSSOM typu WPTypek Performance

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