32 Porady SEO

3,5 regułki .htaccess dzięki którym strona będzie szybsza

Od dłuższego czasu Google robi wszystko co w swojej mocy by dać do zrozumienia webmasterom, że im szybciej strona się wczytuje tym lepiej. I nie chodzi tutaj o czynnik wpływający na pozycję, ale o samą wygodę użytkowników.

Dzisiaj przedstawię Wam 3 proste regułki w pliku .htaccess dzięki którym strona będzie się wczytywała trochę szybciej. Efektem ubocznym będzie to, że zdobędziecie kilka punktów więcej we wszelkiej maści testerom on-line.

Co trzeba powiedzieć przeglądarce internetowej by wczytywała stronę szybciej?

Kompresja plików gzip!

Oczywistą oczywistością jest fakt, że wszystkie pliki CSS, JS i obrazki kompresujemy w taki sposób by były jak najmniejsze. Czasami nawet warto scalać wiele plików w jeden. Dzięki temu zmniejszamy ilość zapytań do serwera. Jest jeszcze jedna kompresja dzięki której pliki mogą wczytywać się jeszcze szybciej. Jest to gzip. Dzięki kompresji gzip, pliki mogą być nawet do 70% mniejsze!

Poniżej regułka htaccess gzip (DEFLATE) dla serwera Apache:


    AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript

Jeżeli na stronie są inne typy plików, to śmiało możesz dodać inne. Powyższa regułka zawiera te najpopularniejsze.

Poprawne działanie tej regułki znajdziesz na stronie gzipwtf.com - zaznacz opcję „details” by zobaczyć czy pliki są kompresowane.

Efekt działania kompresji GZIP

Expires - czyli czas wygaśnięcia cache

Kolejna istotna rzecz, to powiedzenie przeglądarce by zapamiętał pliki z naszej strony na określony czas. Prawda jest taka, że im dłużej tym lepiej. Dzięki temu przeglądarka nie musi tracić czasu na pobieranie każdego pliku tylko bierze go ze swojego cache’a.

Regułka wygląda tak:



    ExpiresActive on
    ExpiresDefault                                      "access plus 1 month"

  # CSS
    ExpiresByType text/css                              "access plus 1 year"

  # Data interchange
    ExpiresByType application/json                      "access plus 0 seconds"
    ExpiresByType application/xml                       "access plus 0 seconds"
    ExpiresByType text/xml                              "access plus 0 seconds"

  # Favicon (cannot be renamed!) and cursor images
    ExpiresByType image/x-icon                          "access plus 1 week"

  # HTML components (HTCs)
    ExpiresByType text/x-component                      "access plus 1 month"

  # HTML
    ExpiresByType text/html                             "access plus 0 seconds"

  # JavaScript
    ExpiresByType application/javascript                "access plus 1 year"

  # Manifest files
    ExpiresByType application/x-web-app-manifest+json   "access plus 0 seconds"
    ExpiresByType text/cache-manifest                   "access plus 0 seconds"

  # Media
    ExpiresByType audio/ogg                             "access plus 1 month"
    ExpiresByType image/gif                             "access plus 1 month"
    ExpiresByType image/jpeg                            "access plus 1 month"
    ExpiresByType image/png                             "access plus 1 month"
    ExpiresByType video/mp4                             "access plus 1 month"
    ExpiresByType video/ogg                             "access plus 1 month"
    ExpiresByType video/webm                            "access plus 1 month"

  # Web feeds
    ExpiresByType application/atom+xml                  "access plus 1 hour"
    ExpiresByType application/rss+xml                   "access plus 1 hour"

  # Web fonts
    ExpiresByType application/font-woff                 "access plus 1 month"
    ExpiresByType application/vnd.ms-fontobject         "access plus 1 month"
    ExpiresByType application/x-font-ttf                "access plus 1 month"
    ExpiresByType font/opentype                         "access plus 1 month"
    ExpiresByType image/svg+xml                         "access plus 1 month"

Czy to działa można to sprawdzić za pomocą narzędzi dla developerów. Zakładka sieć i obserwujemy dane połączenia. Nas będzie interesować rubryka rozmiar i czas. Jeżeli wszystko jest ok, to rozmiar będzie miał wartość „from cache” zaś czas, to będzie kilka milisekund. Patrz poniższy obrazek:

Wczytywanie danych z cache przeglądarki - Chrome Dev Tools

Jest to screen z jednej z moich stron. Na liście są dwa moje pliki - reszta to pliki zaciągane przez skrypty Google (reklamy i statystyki).

Zapamiętaj pliki!

Po pierwsze - musi zapamiętać nasze wszystkie pliki CSS, JS i obrazki. Dzięki temu przy następnej wizycie (czy nawet przejściu na kolejną podstronę) pliki nie będą musiałby być wgrywane z naszego serwera tylko z pamięci podręcznej przeglądarki (cache).



    Header set Cache-Control "max-age=31536000, public"


    Header set Cache-Control "max-age=31536000, private"


Dzięki ten regułce pliki zdefiniowane pliki zostaną zapamiętane w przeglądarce na 365 dni. Ta regułka robi największą robotę w narzędziu Google :).

Efekt?

Przed (wg narzędzie Google SpageSpeed Insights):

  • Mobile: 66
  • Desktop: 77
  • Czas wgrania się bloga: 3,12 sek. (wg Google dev tool)

Po:

  • Mobile: 77
  • Desktop: 90
  • Czas wgrania się bloga: 2,54 sek. (wg Google dev tool)

Wynik performance mojego bloga

Zauważalna różnica się w czasie wgrywania się strony. Różnica to prawie 0,3 sekundy. W przypadku bloga to nie jest dużo, ale w przypadku sklepu internetowe każdy ułamek sekundy jest na wagę złota.

Jako ciekawostkę mogę Wam powiedzieć, że mój inny blog dzięki tym regułkom ładuje się w 152ms (tak, jest bardzo minimalistyczny) :D, udało się przyspieszyć o 24ms. Ciekawe czy uda mi się zejść poniżej 150ms :).

0,5

A teraz połóweczka. A właściwie podpowiedź rozszerzająca kompresowanie plików. Jeżeli na stronie używasz obrazki z rozszerzenie PNG, to polecam zainteresować się stroną tinypng.com, która bardzo dobrze optymalizuje te pliki. Warto dodać, że na tej stronie można zakupić rozszerzenie do Photoshopa, które kompresuje PNG z poziomu programu :).



Zdjęcie autora wpisu - Piotr Cichosz

Piotr Cichosz — autor wpisu

Frontend developer. Tworzę zaawansowane systemy webowe w JS. Swoją wiedzę nt. SEO wykorzystuję do rozwijania własnych projektów (z lepszym lub gorszym efektem). Dużo eksperymentuję i staram się określić jak bardzo można nagiąć cierpliwość algorytmów Google (:.

Zobacz podobne wpisy

Komentarze 32

author Orion www 19.03.2015 08:56:16

Coś podobnego wykorzystywałem z tej strony http://crunchify.com/how-to-speed-up-wordpress-leveraging-browser-caching-via-htaccess/ Przydatne :) i bez niepotrzebnych wtyczek

author Grzelak www 19.03.2015 09:06:02

Zapamięta plików CSS, JS oraz obrazków faktycznie robi największą różnice + Expires. Dobry artykuł

author Dawid www 19.03.2015 09:36:29

Brawo, case study którego niedawno szukałem dot.właśnie wskazówek które pojawiają się w insight. Odnotowałeś zmiany pozycji? (choć jeśli szybkość ma być czynnikiem rankingowym to obstawiam że będzie to dopiero za jakiś czas)

author Vipster www 19.03.2015 09:57:00

No niezle wlasnie koncze swoja stronke to musze to koniecznie zaimplementować bo widze efekty sa spektakularne. Swoja droga nie wiedziałem ze boty które sprawdzaja speed maja cache

author Sławek Borowy 19.03.2015 10:50:13

ehh z htaccess zawsze na bakier ;)
zabieram się do testów, dzięki!

author Piotr Pokraczyński 19.03.2015 11:37:31

Dzięki za dobre info odnośnie .htaccess, mam jeszcze pytanie jak poradzić sobie z elementami blokującymi wyświetlanie (JS i CSS). Nie chce tego robić przez żadne wtyczki innego rodzaju cuda. Masz może jakieś sugestie :) ?

author shpyo www 19.03.2015 11:43:01

@Piotr: musisz dodać atrybut "async" do tagu script. Minusem tego jest to, że jeżeli ładujesz w taki sposób kilka plików i są one zależne od siebie, to może rzucić błędem. Rozwiązaniem tego problemu, to merge dla wszystkich plików JS.
Co do CSS, to masz opisane wszystko na stronie Google: https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery :)

author rebuk www 19.03.2015 12:05:46

tinypng.com jest spoko, dla grafik nieprzezroczystych używam również kraken.io

author Piotr Pokraczyński www 19.03.2015 12:08:36

Dzięki będę kombinował ;)
Na tą chwilę udało mi się na desktop dojść do 90, ale niestety mobile ma 68. Trzeba będzie popracować nad tym troszkę. Niestety Joomla pod tym względem jest dość oporna :/

author Przemek www 19.03.2015 12:31:51

Hmm dodałem do mojego .httacess tę kompresję plików (joomla 3) jednak gwzipwtf pokazuję wszędzie 'none' co może być nie tak, dzięki z góry za opd

author Piotr Pokraczyński www 19.03.2015 14:10:40

W konfiguracji Joomla masz włączoną gzip ?

author Przemek 19.03.2015 14:24:22

próbowałem z włączonym gzip w joomla i bez, w jednym i drugim przypadku test na gzipwtf pokazuje 'none' przy każdej pozycji.

author Piotr Pokraczyński www 19.03.2015 14:55:01

Dziwne, może skontaktuj się z twoim dostawcą hostingu i zapytaj czy to nie jest ich sprawka. Ewentualnie przed tym sprawdź jakie phpinfo czy masz gzip enabled.

author Przemek 19.03.2015 15:49:29

phpinfo(); pokazuje, że jest ok, napisałem do pomocy technicznej, zobaczymy co poradzą :)

author Comandeer 19.03.2015 16:11:05

@shpyo, samo [async] też może zblokować na ułamek sekundy stronę. Najlepsze rezultaty daje połączenie [async][defer]… albo po prostu inline małych JS ;) Osobiście napisałem sobie dirty tool, który sam robi takie rzeczy. Przy większych projektach jednak i tak zostajemy skazani na systemy modułów, typu UMD.

Co do artykułu - skoro już tak bardzo dbamy o wydajność, to warto zauważyć, że .htaccess również zabija wydajność i regułki z niego w miarę możliwości należy przenieść do httpd.conf ;)

Niemniej nie lubię strasznie zbytniego przywiązywania do kwestii wydajności, przy pomijaniu praktycznie w ogóle kwestii bezpieczeństwa. IMO Google powinno tak przerobić PageSpeed Insights i jego dokumentację, żeby nie pluć się przy Content-Security-Policy, ale obsługiwać go poprawnie. Co ciekawe, CSP jest rozumiane całkowicie inaczej przez bota PageSpeed, a inaczej przez Googlebota z testu mobilnego czy GWT. PageSpeed rozumie w pełni poprawnie CSP 2.0, podczas gdy "normalny" Googlebot wykłada się na tym równo, przez co można otrzymać negatywny wynik w teście mobilnym i 99/100 w wygodzie usera w zakładce mobilnej PageSpeed. Wydaje mi się, że PageSpeed jest ciut oderwany od rzeczywistości (zwłaszcza, że jego dokumentacja de facto dissuje Angulara ;)).

Nie chodzi mi o to, że nie należy dbać o wydajność. Po prostu uważam, że PageSpeed (zwłaszcza w dobie wchodzącego HTTP/2) jest ciut paranoiczny… i ta paranoja niestety udziela się środowisku, które nagle w wydajności zaczyna dostrzegać nowego bożka Sieci…

author Łukasz 19.03.2015 17:19:18

Czy może zauważyliście u siebie że po włączeniu komplresji gzip szybkość crawlowania GoogleBota wzrasta natomiast drastycznie maleje liczba przeglądanych dziennie stron?

author Mirek www 19.03.2015 22:00:37

dzięki za info, jednak siła w htacces :]

author Luk 20.03.2015 11:45:53

Co może być powodem, że strona (na WP) nie reaguje na wprowadzone reguły?
Sprawdzałem na jednej i ładnie poszło w górę, a na drugiej z 1 pkt. Strona stoi na serwerach zenbox.pl

author Adam www 23.03.2015 01:33:43

Piszesz o gzip, mili sekundach..., cache, optymalizacjach a grafiki które zamieszczasz w artykule można by trochę jeszcze bardziej "przyciąć" ;) np przez bezpłatny program Xnwiew* (Menu) -> plik/kreator eksportu wybierając ilość kolorów w png czy nawet kompresje jpg dla twojego zdjęcia (Dlaczego użyłeś PNG dla małego zdjęcia ? To nie zawsze to chyba optymalny wybór dla fotografii ?).

np: http://postimg.org/gallery/h7ft9hki/c4fb3a4d/

Logo też możesz przeprojektować dla wersji eko ;) .

Choć w erze LTE, już dość szybkich łącz nie ma to już takiego znaczenia (chyba).


*Program ma tą zaletę że pokazuje na bieżąco efekty przed ostatecznym zapisem, przy kompresji zróżnicowanych detali, faktur, można z góry przyjąć swój próg jakości w przetwarzaniu wsadowym ale gdy jest sporo nieba w łagodnych przejściach to np 50% może dosłownie bić po oczach kwadratami i trzeba podnieść czasem podnieść do 70-80%.

author Damian www 24.03.2015 17:09:44

Ale śmieszne wideło. HEHE HEHE :D

author Dirty Frank www 26.03.2015 12:21:30

MEGA dobry artykuł, dzięki!

author Analityk www 30.03.2015 12:43:42

Bardzo fajny, przydatny post - dzięki! Dodane do ulubionych :)

author Bogdan Kondracki www 14.04.2015 22:32:10

Dzień dobry, również jak serwer jest dobry to strona wczytuje się szybko, polecam Blink, jest tani i nowoczesny, również nowości - skrypt Laze opóźnia wczytywanie obrazków,strona już się otworzyła, można przewijać a obrazki wciąż się wczytują. Bardzo dobry wynalazek.
Bogdan Kondracki

author Bartek www 16.04.2015 16:16:52

Regułka 3 jest bardzo fajna. Niesamowicie przyśpiesza ładowanie kolejnych podstron. Myślę, że to zwiększy "doznania" odwiedzających kolejną podstronę i może zdecydują się zobaczyć coś jeszcze.

author Mr Math www 28.05.2015 17:46:12

Wykorzystam na pewno. Dzięki

author Bronek 02.09.2015 16:25:11

Na wordpresie nie mam róznicy - może przez poinstalowane wtyczki ale na stronach html na google speed wzrost o 3 punkty. Działa.

author Paweł 08.01.2016 18:51:25

Świetny konkretny wpis, dzięki :)

author Michał www 11.02.2016 10:43:37

Ciekawy artykuł, widzę że muszę jeszcze kilka rzeczy na swojej stronie poprawić, aby zwiększyć jej szybkość :)

author FotoGuzik www 12.05.2016 21:29:45

Trochę nie rozumiem jednej rzeczy:
po co stosować ExpiresByType dla kolejnych typów plików, a potem dodawać jeszcze:
Header set Cache-Control "max-age=31536000, public"
Header set Cache-Control "max-age=31536000, private"
skoro powyższe i tak zadeklaruje ważność wszystkich plików na rok...
Czy to aby nie jest tak, że ALBO korzystamy z ExpiresByType ALBO z Header set Cache-Control?

author Polskie litery www 23.05.2016 19:20:18

Wielkie dzięki. Bardzo przydatny artykuł.

author Pchli Targ www 26.06.2017 13:51:50

Mam właśnie problem z długim czasem wczytywania się strony. Informacje te są dla mnie bardzo cenne. Dzięki

author Accurate www 30.06.2017 11:35:04

Ciekawy artykuł. Sporo przydatnych informacji.

Dodaj komentarz