Leverage browser caching - jak rozwiązać problem

[marv]

Cześć, mam problem związany z optymalizacją strony. Gtmetrix w audycie zaleca mi włączenie browser cache, a page speed insights podobnie jako 'Wyświetlaj zasoby statyczne, stosując efektywne zasady pamięci podręcznej'. Rzecz w tym, że korzystam już z wtyczki WP Super Cache i Autoptimize, które powinny rozwiązać ten problem. Z tego co wyczytałem problem polega na tym, że jedna z wtyczek nadpisuje ustawienia tej drugiej, dlatego oba narzędzia diagnostyczne rekomendują wydłużenie cache powyżej 15 minut. Podobno jednym z rozwiązań jest dodanie do pliku htaccess kodu cache-control i cache-headers (poniżej). Czy to koniecznie, a może można to rozwiązać inaczej z poziomu tych wtyczek? Hosting na OVH.

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>

oraz

#Customize expires cache start - adjust the period according to your needs
<IfModule mod_expires.c>
  FileETag MTime Size
  AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript
  ExpiresActive On
  ExpiresByType text/html "access 600 seconds"
  ExpiresByType application/xhtml+xml "access 600 seconds"
  ExpiresByType text/css "access 1 month"
  ExpiresByType text/javascript "access 1 month"
  ExpiresByType text/x-javascript "access 1 month"
  ExpiresByType application/javascript "access 1 month"
  ExpiresByType application/x-javascript "access 1 month"
  ExpiresByType application/x-shockwave-flash "access 1 month"
  ExpiresByType application/pdf "access 1 month"
  ExpiresByType image/x-icon "access 1 year"
  ExpiresByType image/jpg "access 1 year"  
  ExpiresByType image/jpeg "access 1 year"
  ExpiresByType image/png "access 1 year"
  ExpiresByType image/gif "access 1 year"
  ExpiresDefault "access 1 month"
</IfModule>
#Expires cache end

Problem rozwiązany. Można albo zainstalować odpowiednią wtyczkę (co mija się z celem) albo wrzucić powyższy fragment do pliku htaccess i ewentualnie dodać rozszerzenia nowych formatów, jeżeli takie mamy na stronie.

Edytowane 1 Sierpnia 2019 przez marv

[szmigieldesign]

Tak jak sam sobie odpowiedziałeś - Wyświetlaj zasoby statyczne, stosując efektywne zasady pamięci podręcznej' dotyczy pamięci podręcznej przeglądarki, albo raczej poinstruowania jej, jak ma traktować materiały pobrane z serwera. WP Super Cache nie dodaje odpowiednich zapisów do .htaccess (o ile mnie pamięć nie myli), robi to W3TC albo LiteSpeed, który niezawodnie polecam do kompletnej optymalizacji stron opartych na WordPress. Myślę, że to dużo lepsze rozwiązanie niż Autoptimize, chociażby ze względu na mnogość opcji, rozbudowane zarządzanie wyjątkami i chyba najlepszą w branży optymalizację obrazów w bibliotece Media. Jeżeli jesteś zainteresowany tematem, na moim blogu przeczytasz więcej o LiteSpeed Cache dla WordPress.

[devopsiarz]

3 godziny temu, szmigieldesign napisał:

Tak jak sam sobie odpowiedziałeś - Wyświetlaj zasoby statyczne, stosując efektywne zasady pamięci podręcznej' dotyczy pamięci podręcznej przeglądarki, albo raczej poinstruowania jej, jak ma traktować materiały pobrane z serwera. WP Super Cache nie dodaje odpowiednich zapisów do .htaccess (o ile mnie pamięć nie myli), robi to W3TC albo LiteSpeed, który niezawodnie polecam do kompletnej optymalizacji stron opartych na WordPress. Myślę, że to dużo lepsze rozwiązanie niż Autoptimize, chociażby ze względu na mnogość opcji, rozbudowane zarządzanie wyjątkami i chyba najlepszą w branży optymalizację obrazów w bibliotece Media. Jeżeli jesteś zainteresowany tematem, na moim blogu przeczytasz więcej o LiteSpeed Cache dla WordPress.

 

Żadna ze znanych mi wtyczek cache, w tym LiteSpeed, mówię o wersjach darmowych, nie robi cache porządnie. Jeśli webserver jest niestandardowy (patrz: nie apache), to robią "biedacache" - wygenerowane pliki statyczne są serwerowane przez... PHP. Nie wiem jak na apache jest, mogę podejrzewać, że też źle. Czyli zamiast serwować bezpośrednio pliki, serwer podaje request do php, a php dopiero "kuma", że ma cache (redis czy coś tym stylu lub właśnie pliki statyczne).

 

Owszem w stosunku do "gołego" WP, te wtyczki przyspieszają działanie strony, ale i tak jest to marnowanie zasobów na wysokim poziomie i zmarnowany potencjał. Jeśli cache ma być porządny, to bez grzebactwa w webserverze się nie obejdzie i/lub współpracy z czymś z rodzaju varnish. Także nie polecam wydawać pieniędzy na te wtyczki, bo to nie jest warte świeczki.

[marv]

Dnia 2.08.2019 o 19:39, devopsiarz napisał:

 

Żadna ze znanych mi wtyczek cache, w tym LiteSpeed, mówię o wersjach darmowych, nie robi cache porządnie. Jeśli webserver jest niestandardowy (patrz: nie apache), to robią "biedacache" - wygenerowane pliki statyczne są serwerowane przez... PHP. Nie wiem jak na apache jest, mogę podejrzewać, że też źle. Czyli zamiast serwować bezpośrednio pliki, serwer podaje request do php, a php dopiero "kuma", że ma cache (redis czy coś tym stylu lub właśnie pliki statyczne).

 

Owszem w stosunku do "gołego" WP, te wtyczki przyspieszają działanie strony, ale i tak jest to marnowanie zasobów na wysokim poziomie i zmarnowany potencjał. Jeśli cache ma być porządny, to bez grzebactwa w webserverze się nie obejdzie i/lub współpracy z czymś z rodzaju varnish. Także nie polecam wydawać pieniędzy na te wtyczki, bo to nie jest warte świeczki.

Ciekawe spostrzeżenia devopsiarzu. Przy okazji rozmowy o wtyczkach cache, to właśnie dzisiaj po kilku dniowych przejściach ze stroną, pozbyłem się raz na zawsze wp super cache i wcale nie mam ochoty korzystać z jakichkolwiek wtyczek cache. Jaki efekt? Ano taki, że na przykład w PageInsights i GTMetrix witryna dostała 5 oczek więcej. Dziwne? Nie jestem specjalistą, ale wydaje mi się, że dla małej hobbystycznej strony, kompresja i cache po stronie serwera wystarcza, a dokładnie dodatkowych wtyczek, włączanie opcji jest drogą donikąd. Jeżeli działa bardzo dobrze, a w benchmarkach witryna dostaje więcej oczek, to dlaczego szukać dziury w całym?

Edytowane 3 Sierpnia 2019 przez marv

[devopsiarz]

Oczywiście wszystko zależy od wielkości strony (w tym przypadku m.in. bazy w WP), ilości wtyczek, które "coś robią" itp. Rzeczywiście, jak masz niewielki ruch, parę wpisów na krzyż i nie masz 100 wtyczek, to cache może być zwyczajnie zbędny. Jeżeli bez kombinowania z jakimkolwiek cache, Twojej stronie lepiej i nie narzekasz, to warto przy tym pozostać, zaznaczałem tylko, że wtyczki zazwyczaj robią "pseudo" cache. Działa nawet, ale ten prawdziwy (co daje 100/100 w PageSpeedInsights) wymaga zabawy za kulisami serwera www.

[szmigieldesign]

@devopsiarz, wtyczka LiteSpeed Cache dla WordPress to stosunkowo rozbudowane narzędzie, którego funkcje można zamknąć w dwóch grupach:

 

a) szereg narzędzi optymalizacyjnych działających po stronie PHP i funkcji wbudowanych w WordPress (minifikacja, zarządzanie skryptami, obsługa CDN, optymalizacja obrazków, etc.) - te narzędzia działają dla każdej instalacji WordPress, na każdym serwerze.

b) interfejs dla cache serwera kompatybilny z licencjonowanymi wersjami LiteSpeed Web Server.

 

Wtyczka może więc działać zarówno w tandemie z wtyczkami generującymi pliki statyczne, jak W3TC czy WP Super Cache, oraz samodzielnie w przypadku serwera LiteSpeed.

 

Zadaniem cache, nawet obsługiwanego przez PHP, jest zmniejszenie zapytań do bazy i opóźnienia przed wysłaniem kodu HTML do przeglądarki klienta - nie jest to więc rozwiązanie pozbawione sensu, nawet jeżeli routing jest oparty o PHP (a trzeba wiedzieć, że zarówno W3TC jak i WP Super Cache są w stanie obsługiwać cache przez .htaccess, czyli z pominięciem PHP). Dla serwerów, które pod obciążeniem generują TTFB na poziomie 0.3 - 0.8 sekundy, uruchomienie cache pozwala na zmniejszenie tego parametru np. do 0.1 lub mniej, nawet przy cache serwowanym przez PHP - po prostu skrypt nie czeka na bazę a PHP obsługuje jedynie prosty routing.

 

@marv, punkty w testach syntetycznych to ostatnie czym powinieneś się kierować jeżeli chodzi o wydajność strony internetowej. Podstawowym parametrem jest czas potrzebny na wyświetlenie kompletnej strony przez przeglądarkę. Nawet taki cache, którego routing jest obsługiwany przez PHP powinien zmniejszyć TTFB - szczególnie w przypadku hostingów współdzielonych, kiedy ruch na serwerze jest znaczący (pamiętaj, że chodzi nie tylko o ruch na Twojej stronie - który może być niewielki - ale także o obciążenie serwera na którym jest Twoja strona). Zobacz mój tekst, pt. "Punkty, punkciki, paranoja", gdzie piszę o wariactwie testów syntetycznych.

 

Kolejna sprawa to skuteczna konfiguracja cache oraz optymalizacji strony (minifikacja, opóźnione ładowanie skryptów, usunięcie niepotrzebnych rzeczy, optymalizacja obrazów, skorzystanie z HTTP2 i precaching, etc. - tego jest całkiem sporo).

[devopsiarz]

1 godzinę temu, szmigieldesign napisał:

@devopsiarz, wtyczka LiteSpeed Cache dla WordPress to stosunkowo rozbudowane narzędzie, którego funkcje można zamknąć w dwóch grupach:

 

a) szereg narzędzi optymalizacyjnych działających po stronie PHP i funkcji wbudowanych w WordPress (minifikacja, zarządzanie skryptami, obsługa CDN, optymalizacja obrazków, etc.) - te narzędzia działają dla każdej instalacji WordPress, na każdym serwerze.

 

Nie działają dla każdej instalacji WordPress i nie na każdym serwerze. Polecam się zapoznać z tym, jak działają czasem wtyczki "pod maską", w tym te co wymieniłeś. One z czegoś korzystają, bo nikt koła na nowo we wtyczce nie wymyśla (np. optymalizacja obrazków). Często same Ci powiedzą, czego Ci brak na serwerze, albo same zaoferują swoje API, za stosowną opłatą powyżej pewnego limitu.

 

Więc nie, nie działają wszędzie i na każdym.

 

1 godzinę temu, szmigieldesign napisał:

b) interfejs dla cache serwera kompatybilny z licencjonowanymi wersjami LiteSpeed Web Server.

 

Z punktu widzenia użytkownika końcowego lepszy jest cache kompatybilny z popularniejszymi rozwiązaniami.

Ale szanuję, mówka handlowca była tu książkowa.

 

1 godzinę temu, szmigieldesign napisał:

Wtyczka może więc działać zarówno w tandemie z wtyczkami generującymi pliki statyczne, jak W3TC czy WP Super Cache, oraz samodzielnie w przypadku serwera LiteSpeed.

 

Nie, nie może. Tzn. możesz sobie popychać treść między tymi wtyczkami, jak zależy Ci na zwiększeniu latencji, w sytuacji, gdy cache jeszcze nie masz wygenerowanego. Natomiast jak jedna wtyczka działa "dobrze", w sensie robi co powinna, to druga już efektywnie działać nie może. Chyba, że jednak będzie "poprawiać" pierwsza. Zatem kilka wtyczek do statycznych plików to ciekawa idea, ale dziwna i niepotrzebna.

 

1 godzinę temu, szmigieldesign napisał:

Zadaniem cache, nawet obsługiwanego przez PHP, jest zmniejszenie zapytań do bazy i opóźnienia przed wysłaniem kodu HTML do przeglądarki klienta - nie jest to więc rozwiązanie pozbawione sensu, nawet jeżeli routing jest oparty o PHP (a trzeba wiedzieć, że zarówno W3TC jak i WP Super Cache są w stanie obsługiwać cache przez .htaccess, czyli z pominięciem PHP).

 

Rozwiązanie się sprawdza (jako tako) do pewnej skali, ale jest pozbawione sensu w ogólnym rozrachunku, gdyż:

 

1) Użycie PHP powoduje zwiększenie zasobów serwera, fakt - bazy nie używamy, jest postęp!

 

2) Użycie PHP jest problematyczne jeszcze z innego powodu - wciąż jesteś narażony na błędy bezpieczeństwa związane z wtyczkami WP, jak i samym silnikiem PHP - dziwna sytuacja, gdy chcemy serwować pliki statyczne.

 

1 godzinę temu, szmigieldesign napisał:

Dla serwerów, które pod obciążeniem generują TTFB na poziomie 0.3 - 0.8 sekundy, uruchomienie cache pozwala na zmniejszenie tego parametru np. do 0.1 lub mniej, nawet przy cache serwowanym przez PHP - po prostu skrypt nie czeka na bazę a PHP obsługuje jedynie prosty routing.

 

Podałeś cyfry dla jakiej sytuacji? Jakie obciążenie, strona, routing, przy jakiej treści, jakim protokole konkretnie? Bo wiesz, cyfry bez kontekstu, to tylko cyfry.

 

 

1 godzinę temu, szmigieldesign napisał:

@marv, punkty w testach syntetycznych to ostatnie czym powinieneś się kierować jeżeli chodzi o wydajność strony internetowej. Podstawowym parametrem jest czas potrzebny na wyświetlenie kompletnej strony przez przeglądarkę. Nawet taki cache, którego routing jest obsługiwany przez PHP powinien zmniejszyć TTFB - szczególnie w przypadku hostingów współdzielonych, kiedy ruch na serwerze jest znaczący (pamiętaj, że chodzi nie tylko o ruch na Twojej stronie - który może być niewielki - ale także o obciążenie serwera na którym jest Twoja strona). Zobacz mój tekst, pt. "Punkty, punkciki, paranoja", gdzie piszę o wariactwie testów syntetycznych.

 

TTFB jest mocno mylącym parametrem (nie mającym nic wspólnego z tym, co określasz "podstawowym parametrem") i zalecałbym się nim nie przejmować, w ogóle nie mówi nic o wydajności strony jako takiej. Np. mój serwer może błyskawicznie wysłać header i TTFB będzie miał rewelacyjny, a że baza zwróci wyniki za 5 sek to już taka mało znacząca kwestia.

 

 

 

1 godzinę temu, szmigieldesign napisał:

Kolejna sprawa to skuteczna konfiguracja cache oraz optymalizacji strony (minifikacja, opóźnione ładowanie skryptów, usunięcie niepotrzebnych rzeczy, optymalizacja obrazów, skorzystanie z HTTP2 i precaching, etc. - tego jest całkiem sporo).

 

Skorzystanie z HTTP2, bez kontekstu, tylko na zasadzie "włączmy", może równie dobrze zdegradować wydajność.

[szmigieldesign]

@devopsiarz, korzystałeś kiedyś z wymienionych przeze mnie rozwiązań, w tym z serwera LiteSpeed czy wtyczki o której piszę? Czy piszesz tylko po to, aby komuś dogryźć?

[devopsiarz]

21 minut temu, szmigieldesign napisał:

@devopsiarz, korzystałeś kiedyś z wymienionych przeze mnie rozwiązań, w tym z serwera LiteSpeed czy wtyczki o której piszę? Czy piszesz tylko po to, aby komuś dogryźć?

 

Tak, korzystałem, pierwszy raz w 2015. Ale umówmy się, że jak nie masz zamiaru odnosić się w ogóle do treści merytorycznej mojego posta, to albo na niego nie odpowiadaj, albo nie licz, że będę na poboczne pytania jednozdaniowe odpowiadał.

 

Czyli zamiast zadawać takie pytania, wprost wskaż, gdzie nie mam racji - będzie szybciej i przyjemniej w dyskusji.

[szmigieldesign]

Jak z tym dyskutować:

 

Cytat

Wtyczka może więc działać zarówno w tandemie z wtyczkami generującymi pliki statyczne, jak W3TC czy WP Super Cache, oraz samodzielnie w przypadku serwera LiteSpeed.

 

"Nie, nie może. Tzn. możesz sobie popychać treść między tymi wtyczkami, jak zależy Ci na zwiększeniu latencji, w sytuacji, gdy cache jeszcze nie masz wygenerowanego. Natomiast jak jedna wtyczka działa "dobrze", w sensie robi co powinna, to druga już efektywnie działać nie może. Chyba, że jednak będzie "poprawiać" pierwsza. Zatem kilka wtyczek do statycznych plików to ciekawa idea, ale dziwna i niepotrzebna."

 

Albo z tym:

 

"Ale szanuję, mówka handlowca była tu książkowa."

[theqkash]

Ostatnio do swoich serwerów zacząłem wdrażać mod_pagespeed od Google, szczerze mówiąc doskonale rozwiązuje opisywany tutaj problem, a dodatkowo z automatu konwertuje grafiki na webp, kompresuje skrypty i css'y. Jedynym problemem jest praktycznie brak możliwości konfiguracji przez użytkownika, zwłaszcza wtedy gdy korzysta się np. z php-fpm. No, przynajmniej mnie się nie udało tego sensownie ustawić.

[devopsiarz]

5 godzin temu, theqkash napisał:

Ostatnio do swoich serwerów zacząłem wdrażać mod_pagespeed od Google, szczerze mówiąc doskonale rozwiązuje opisywany tutaj problem, a dodatkowo z automatu konwertuje grafiki na webp, kompresuje skrypty i css'y. Jedynym problemem jest praktycznie brak możliwości konfiguracji przez użytkownika, zwłaszcza wtedy gdy korzysta się np. z php-fpm. No, przynajmniej mnie się nie udało tego sensownie ustawić.

 

No to teraz dla pewności odpal Safari i sprawdź czy Ci webp działają

[Matix8981]

Konwertowanie grafik na WebP to zły pomysł sam tego doznałem ostatniego czasu gdy otrzymałem wiadomość, że na Operze nie widzą obrazków

[theqkash]

mod_pagespeed wyświetla webp tylko na klientach które webp obsługują. Dla innych klientów wyświetla grafiki w oryginalnych formatach.