powrot do bloga

Optymalizacja strony Wordpress. Jak przyśpieszyć stronę.

Optymalizacja strony Wordpress. Jak przyśpieszyć stronę.

Dlaczego szybkość ładowania strony ma znaczenie ?

Z tego artykułu dowiesz się co wpływa na szybkość ładowania strony internetowej. Jak powinny być zoptymalizowane obrazy oraz baza danych dla Wordpress by szybkość ładowania była na zadowalającym poziomie dla użytkownika oraz dla nowego algorytmu Google Core Web Vitals.

Spis treści:

  1. Optymalizacja strony na Wordpress
  2. Prędkość ładowania strony jako czynnik rankingowy
  3. Parametry Core Web Vitals
  4. Sposób wykonania szablonu HTML, CSS
  5. Jak sprawdzić szybkość strony (czas ładowania)
  6. Jak poprawić czas ładowania strony na Wordpress
  7. Konfiguracja wtyczki W3Total Cache
  8. Optymalizacja wdrożenia szablonu Wordpress
  9. Optymalizacja serweru
  10. Gotowe szablony Wordpress - jak wybrać i czy warto

Optymalizacja strony Wordpress


Czas wczytywania strony internetowej to jeden z pierwszych jej elementów, który odbiera użytkownik. Nawet najlepiej zaprojektowana i funkcjonalna strona nie zda się na nic, jeśli zniechęcony długim ładowaniem odbiorca po prostu z niej wyjdzie, rezygnując z odwiedzania kolejnych podstron. Głównie spadek konwersji odnotujemy dla urządzeń mobilnych oraz odczujemy pośrednio na wynikach organicznych w wyszukiwarce Google.

Prędkość ładowania strony jako czynnik rankingowy


Aby użytkownik w ogóle znalazł się na naszej stronie, musi być ona odpowiednio wysoko pozycjonowana w wynikach wyszukiwania Google. Poprawna optymalizacja i zapewnienie szybkiego wczytywania i działania serwisu ma znaczenie też tutaj, gdyż prędkość ładowania strony jest jednym z kryteriów do obliczania rankingu w wyszukiwarce. Dlatego też podczas tworzenia i zarządzania stroną, powinniśmy przykładać dużą uwagę do jej szybkości.

Co wpływa na czas ładowania strony?

Parametry Core Web Vitals

Czas, który upływa momentu wpisania adresu URL strony lub kliknięcia linku do wyświetlenia gotowej strony użytkownikowi można zmierzyć za pomocą kilku kluczowych wskaźników. Są to:

  1. TTFB (Time to First Byte) - czas, jaki upływa do odebrania przez przeglądarkę pierwszych danych z serwera. Najważniejszym czynnikiem wpływającym na wysoki TTFB jest optymalizacja kodu naszej strony. Jeśli skrypt PHP naszego szablonu jest skomplikowany, ma wiele pętli i zapytań do bazy, czas wygenerowania strony dla użytkownika znacznie się wydłuży.

  2. FCP / LCP (First / Largest Contentful Paint) - wskaźniki które najbardziej odzwierciedlają postrzeganie prędkości ładowania strony przez użytkownika. Określają czas, po którym na ekranie wyświetla się pierwszy (FCP) lub największy (LCP) element naszej strony.

  3. TTI - (Time to Interactive) mówi o czasie, w którym strona staje się interaktywna i może być w pełni i bez przeszkód użytkowana. Określa się go jako czas od FCP a zakończeniem ostatniego zadania, które blokowało główny wątek przez dłużej niż 50ms.

Wykonany template Wordpress / motyw /

Są różne możliwośći napisania / kodowania / tego samego projektu graficznego. Można wykonać szablon wordpress czytelne z minimalną ilością kodu JavaScript oraz CSS, a może go być zbyt dużo (często w gotowych szablonach), który zbyt obciąża sposób odczytania strony i jej renderowania.

Oprócz samego kodu HTML strony, ważną jej częścią są także wszystkie podlinkowane zasoby statyczne. Na typowej stronie są to arkusze stylów CSS, pliki webfontów oraz skrypty JavaScript.

Zasoby blokujące renderowanie

Wymienione powyżej typy plików to zasoby blokujące renderowanie (ang. render-blocking resources). Zbyt duży rozmiar tych zasobów powoduje wydłużenie ładowania się drzewa DOM, co pociąga za sobą powolne wyświetlanie strony.

Techniczne aspekty strony na Wordpress

W tym artykule skupimy się na technicznej stronie wykonania kodowania szablonu dla Wordpress.


Jak przetestować szybkość strony

Zanim przystąpimy do optymalizacji i prób przyspieszenia strony, musimy zidentyfikować czynniki, które mają największy wpływ na jej wolne ładowanie. Analizując wykonaną stronę lub stronę, którą należy zoptymalizować pierwszą czynnośią jest sprawdzenie jej programami analitycznymi by sprawdzić sposób wykonania kodowania HTML oraz samego wdrożenia Wordpress.


Google PageSpeed Insights

Najważniejsze, ze względu na pozycjonowanie, narzędzie do testowania witryny. Pokazuje zarówno zagregowany wynik dla urządzeń mobilnych i desktopów, jak i poszczególne parametry składowe wraz z informacją, które z nich wymagają poprawy. Wyniki narzędzia google mają bezpośredni wpływ na ranking SEO, dlatego warto skupić się na jak najwyższej punktacji.

GTmetrix

Pokazuje kluczowe wskazówki, które ułatwią wyeliminowanie największych czynników wpływających na wolne ładowanie witryny. Pozwala też na analizę tzw. waterfall, czyli wykresu ładowania poszczególnych zasobów w czasie, co może być pomocne przy znalezieniu tych, które mogą ładować się zbyt długo.

KeyCDN Performance Test

Pozwala ocenić prędkość DNS oraz wartość wskaźnika TTFB z różnych miejsc na świecie, co może być przydatne w szczególności, gdy naszą witrynę kierujemy do odbiorców w różnych krajach.

Konsola w przeglądarce

Pozwala dokładnie przeanalizować kolejność i prędkość ładowania wszystkich zasobów, których żąda strona, wraz z podziałem na składowe tych czasów. Umożliwia także szybkie wychwycenie zbyt dużych plików obrazków, skryptów i stylów, a także emulację różnych prędkości internetu (np. 3G lub wolne LTE). Zakładka Performance wyświetla także wszystkie wskaźniki Web Vitals z informacją, czy ich wartości są w normie, czy zbyt wysokie. Dla zaawansowanych użytkowników dostępne są także funkcje takie jak “Coverage”, które pozwala odnaleźć nieużywany kod CSS i JavaScript.

Poprawa prędkości stron Wordpress

Optymalizacja z poziomu Wordpressa

Jeśli jedynym naszym zadaniem jest zarządzanie samą treścią z poziomu wordpressa, możemy wpłynąć na czas ładowania strony w następujący sposób:


  1. Unikanie korzystania z dużej liczby wtyczek działających na froncie, z których przeważnie każda ładuje swoje zasoby CSS i JS.
    Jeśli potrzebujemy umieścić we wpisie galerię zdjęć, czy osadzić film z YouTube, korzystajmy z wbudowanych w Wordpressa narzędzi, zamiast szukać odruchowo wtyczek w repozytorium.

  2. Sprawdzanie rozmiaru i wagi wgrywanych zdjęć - przed wgraniem obrazka do biblioteki mediów, powinno się go przepuścić przez narzędzie do kompresji JPEG. Przy użyciu kompresji stratnej z sensownym progiem jakości, jesteśmy w stanie zredukować wagę pliku nawet 10-krotnie, nie tracąc przy tym wiele na jakości.

    Nie wrzucajmy też stronę obrazków prosto z aparatu w rozdzielczości 10MP. Większość szablonów na na stałe określoną szerokość kontenera na treść, zwykle w przedziale 1200-1400px, więc nie ma potrzeby wgrywania obrazów o większej szerokości.

    Ratunkiem dla już istniejących bibliotek mediów mogą być wtyczki optymalizujące, które przeskanują i skompresują obrazki wgrane na stronę. Jednak wtyczki te w wersjach darmowych bardzo często mają ograniczenia dotyczące np. maksymalnej liczby obrazków kompresowanych jednocześnie, maksymalnego rozmiaru zdjęcia które może zostać przetworzone (np. 1MB) czy braku kompresji stratnej.

  3. Paginacja bloga, komentarzy oraz treści - jeśli nasza strona wyświetla artykuły na blogu lub umożliwia ich komentowanie, dobrym pomysłem może być ograniczenie liczby artykułów oraz komentarzy wyświetlanych jednocześnie do sensownej liczby. W końcu każdy taki element do dodatkowe treści, a często także obrazki które wymagają załadowania.

    Wordpress umożliwia także podzielenie treści strony oraz wpisu poprzez użycie tagu <!--nextpage-->. Taki zabieg może okazać się pomocny, jeśli nasz artykuł zawiera dużo ciężkich multimediów.  

  4. Włączenie wtyczki do cache - domyślnie, gdy użytkownik odwiedza stronę opartą o wordpressa, jest ona za każdym razem na bieżąco generowana przy pomocy skryptów PHP oraz zapytań do bazy danych. Instalacja wtyczki do cache pozwala na wygenerowanie statycznych stron HTML i wyświetlenie ich użytkownikowi bezpośrednio, co znacząco wpływa na redukcję TTFB.

    Jednak ta metoda sprawdzi się najlepiej, gdy nasza strona jest stosunkowo statyczna i nie zawiera wielu zmieniających się treści. Jeśli na przykład prowadzimy sklep korzystający z woocommerce, to korzystanie z cache nie tylko będzie niepraktyczne (konieczność przebudowy cache przy każdej aktualizacji cen czy stanów magazynowych), co wręcz niemożliwe dla zalogowanych klientów (każdy z nich ma przecież swoją własną listę zamówień, czy stronę z danymi konta).

  5. Wtyczki do łączenia i minifikacji zasobów - jeśli nasz serwer nie używa HTTP/2, duże korzyści może przynieść konfiguracja wtyczki, która połączy wszystkie ładowane pliki CSS oraz JS. W ten sposób możemy zaoszczędzić sporo czasu, znacząco zmniejszając liczbę zapytań do serwera.

    Pamiętajmy jednak, aby po każdej zmianie konfiguracji takiej wtyczki dokładnie przetestować stronę i sprawdzić komunikaty w konsoli, ponieważ w przypadku łączenia i kompresji kilku skryptów JS i ładowania ich na raz, często mogą pojawić się błędy. Zwykle można je wyeliminować dodając problematyczne pliki do listy ignorowanych - nie zostaną wtedy uwzględnione w procesie łączenia plików.

    Wszystkie zabiegi ingerujące w ładowane w Wordpressie zasoby CSS / JS działają tylko i wyłącznie z plikami wczytywanymi przy pomocy wbudowanych funkcji wp_enqueue_script oraz wp_enqueue_style - nie powinniśmy nigdy ładować tych plików bezpośrednio w kodzie HTML naszej strony!

  6. Rezygnacja z osadzania iframe - Każda osadzona w treści ramka iframe powoduje ładowania zupełnie osobnej strony WWW.


Konfiguracja wtyczki W3 Total Cache

Jedną z najpopularniejszych wtyczek używanych do tworzenia cache i szeroko pojętej optymalizacji Wordpressa jest ​​W3 Total Cache. W3C przyspiesza stronę generując statyczne pliki zamiast zawartości tworzonej dynamicznie pobieranej z bazy danych co zdecydowanie skraca czas ładowania strony.

Ze względu na ilość funkcji, które oferuje, jej pierwsza konfiguracja może być problematyczna dla nowych użytkowników. Poniżej zostały opisane najważniejsze ustawienia, które warto skonfigurować:


Zakładka General pozwala szybko włączać i wyłączać moduły konfigurowane w innych zakładkach.

  1. Page Cache - generuje statyczne pliki HTML dla naszego serwisu. Jeśli na stronie nie ma często zmienianych / dynamicznie generowanych treści (np. zaplanowane promocje na sklepie woocommerce) zdecydowanie włączamy tę opcję
  2. Minify - pozwala na minifikację kodu JS / CSS poprzez usunięcie znaków nowej linii, komentarzy itp. Zdecydowanie powinniśmy włączyć tę opcję, jednak warto później przetestować witrynę, i w razie problemów zmienić metody Minify. Jeśli planujemy używać np. Cloudflare, które również posiada tę funkcję, pozostawmy ją wyłączoną.
  3. Opcode Cache - opcja pozwalająca na przechowywanie wstępnie skompilowanych skryptów PHP w pamięci cache, aby ich wykonywanie było znacznie szybsze. Jeśli tylko na naszym serwerze są zainstalowane odpowiednie moduły, warto włączyć tą opcję
  4. Database Cache - włączenie tej opcji na serwerach współdzielonych, gdzie zwykle czynnikiem ograniczającym jest prędkość serwera, a nie bazy danych, potrafi spowolnić witrynę. Tę opcję najlepiej zostawić wyłączoną
  5. Object Cache - podobnie jak Database Cache, włączenie jej opcji na hostingu współdzielonym zwykle powoduje spowolnienie działania witryny. Wyłączamy
  6. Browser Cache - informuje przeglądarkę, aby korzystała z własnego cache podczas serwowania witryny. Opcję zdecydowanie włączamy.
  7. CDN - opcję włączmy tylko wtedy, gdy korzystamy z usług zewnętrznego CDN. W takim przypadku warto skonsultować sposób integracji tego narzędzia.
  8. Reverse Proxy - pozostawiamy wyłączone, gdyż wymaga dedykowanego serwera.
  9. User Experience - kilka opcji:
    Lazy Load Images - włączamy jeśli nie korzystamy z dedykowanych rozwiązań w szablonie
    Disable Emoji - włączamy jeśli nie będziemy używać emotikon
    Disable wp-embed script - włączamy, jeśli nie planujemy osadzać wpisów z innych blogów wordpress
    Disable jquery-migrate on the front-end - włączamy, ale warto później przetestować działanie strony i sprawdzić, czy w konsoli nie pojawiają się błędy
  10. Fragment Cache - Opcja przydatna, gdy na stronie posiadamy sekcje generowane dynamicznie, których nie chcielibyśmy cache’ować. Jednak zaimplementowanie jej wymaga odpowiedniego dostosowania kodu szablonu, a sama opcja jest dostępna tylko w wersji premium wtyczki.
  11. Pozostałe opcje zostawiamy w domyślnym stanie

Zakładka Page Cache - tutaj możemy zmienić zaawansowane ustawienia i warunki dla cache strony:

  1. General - w większości przypadków warto zostawić opcje domyślne.
  2. Cache Preload - opcja, która w regularnych odstępach czasu generuje świeże wersje cache. Warto ją włączyć, aby mieć pewność, że wyświetlana wersja strony nie jest przestarzała.
  3. Purge Policy - pozwala ustalić reguły czyszczenia cache po publikacji wpisów i aktualizacji treści stron. Domyślne opcje są w większości przypadków wystarczające.
  4. Pozostałe opcje zostawiamy w domyślnym stanie
  1. Zakładka Minify - pozwala zmienić ustawienia minifikacji plików HTML, CSS i JS
  1. General - pozostawiamy domyślne
  2. HTML & XML - włączenie pierwszej opcji powinno wystarczyć. Możemy także włączyć osadzenie inline dla styli CSS i skryptów JS, ale warto po tym zabiegu sprawdzić działanie strony
  3. JS - włączamy główną opcję, a następnie testujemy witrynę. W przypadku problemów z jej działaniem możemy wyłączyć combine, bądź zmienić ustawienia w sekcji Minify engine settings. Jeśli nasz serwer posiada wsparcie dla HTTP/2, włączamy opcję HTTP/2 push
  4. CSS - włączmy główną opcję. Jeśli nasz serwer posiada wsparcie dla HTTP/2, włączamy opcję HTTP/2 push
  5. Pozostałe opcje zostawiamy w domyślnym stanie

Zakładka Browser Cache

  1. General:
    Set Last-Modified header: włączone
    Set expires header: włączone
    Set cache control header: włączone
    Set entity tag (ETag): włączone
    Set W3 Total Cache header: włączone
    Enable HTTP (gzip) compression: włączone
    Enable HTTP (brotli) compression: włączone
    Prevent caching of objects after settings change: wyłączone
    Remove query strings from static resources: włączone
    Don't set cookies for static files: włączone
    Do not process 404 errors for static objects with WordPress: włączone
    Rewrite URL structure of objects: włączone
  2. Pozostałe opcje zostawiamy w domyślnym stanie

Pozostałe opcje w innych zakładkach pozostawiamy tak, jak zostay ustawione domyślnie.

Po zmianie każdej opcji warto sprawdzić poprawne działanie strony w innej przeglądarce, gdzie nie jesteśmy zalogowani do wordpressa. Można też odczekać chwilę i sprawdzić wpływ zmienionych ustawień na prędkość działania strony i wyniki Google PageSpeed czy GTMetrix.

Optymalizacja szablonu Wordpress


Jeśli tworzymy własny szablon Wordpress od początku (a zwykle to rozwiązanie jest przez nas wdrażane), warto pamiętać o kilku dobrych praktykach, które pozwolą na zmniejszenie czasu ładowania strony.

Poprawne ładowanie skryptów JS


Pamiętajmy, że skrypty JS powinny być ładowane w stopce strony, aby nie blokować ładowania jej treści. Skrypty w Wordpressie powinniśmy ładować korzystając z wbudowanej funkcji wp_enqueue_script( string $handle, string $src = '', string[] $deps = array(), string|bool|null $ver = false, bool $in_footer = false ), dla której w ostatnim argumencie powinniśmy sprecyzować, że skrypt ma zostać załadowany przed tagiem zamykającym </body>.

Warunkowe ładowanie zasobów

Tworząc rozbudowane strony dobrym pomysłem może być podział plików CSS i JS na moduły odpowiadające poszczególnym podstronom. W połączeniu z szablonami stron możemy wtedy skorzystać z instrukcji warunkowych, przykładowo ładując zasoby odpowiedzialne za podstronę kontaktu tylko na niej:

wp_enqueue_style(‘common’);

wp_enqueue_script(‘common’);


if( is_page_template(‘contact.php’) ){

wp_enqueue_style(‘contact’);

wp_enqueue_script(‘contact’;

}


Tę samą zasadę można użyć do wyłączenia niepotrzebnego ładowania styli i skryptów dostarczanych przez wtyczki. Przykładowo jeśli wiemy, że jedyna strona, na której będzie osadzony formularz kontaktowy contact-form-7, to szablon “Kontakt”, możemy zrezygnować z ładowania zasobów tej wtyczki na innych podstronach:


if( ! is_page_template(‘contact.php’) ){

wp_dequeue_style(‘contact-form-7’);

wp_dequeue_script(‘contact-form-7’);

}


Pamiętajmy jednak, by po takich zabiegach dokładnie przetestować stronę, gdyż zdarza się, że wybiórcze usunięcie zasobów danej wtyczki może powodować błędy JavaScript.

Podział CSS i lazy-load

Wydzielenie styli odpowiadających za sekcje widoczne od razu po wejściu na stronę i załadowanie ich od razu, inline, używając tagu <style> w sekcji <head> może poprawić wskaźniki FCP / LCP opisane w pierwszej części artykułu. Po załadowaniu tych kluczowych elementów, reszta stylów może zostać doładowana później, przy pomocy lazy-load. Takie podejście wymaga jednak dobrego rozplanowania struktury CSS już na początku jego tworzenia, aby samo wyodrębnienie tych stylów było możliwie bezproblemowe.


Podobnie jak przy arkuszach CSS, ładowanie lazy-load może przynieść znaczące oszczędności, jeśli chodzi o czas pierwszego wczytania strony. W przypadku użycia tej metody, obrazki będą doładowywane w miarę przewijania strony przez użytkownika, nie zabierając czasu i zasobów zaraz po otwarciu witryny. Pamiętajmy jednak, by nie używać go w przypadku bannerów umieszczonych w górnej części witryny, gdyż każde opóźnienie ich ładowania pogorszy czasy FCP / LCP.


W przypadku ładowania obrazków dodanych przez administratora w treściach wpisów w Wordpressie, możemy skorzystać z poniższego skryptu, który automatycznie ustawi atrybuty pod plugin lazy-load:

// Lazy Load

function prepare_lazyload_src($attr) {

 $attr['data-src'] = $attr['src'];

 $attr['src'] = '';

 $attr['class'] .= ' lazyload';

 return $attr;

}

add_filter( 'wp_get_attachment_image_attributes', 'prepare_lazyload_src');

Optymalizacja serweru (hosting)

Serwer blisko odbiorcy docelowego / CDN

Jeśli wiemy, że główni odbiorcy naszej strony będą ją odwiedzać np. z Polski, warto przy wybieraniu serwera kierować się również jego fizyczną lokalizacją. Sama odległość pomiędzy komputerem, z którego wysyłane są zapytania, a serwerem je obsługującym nie ma dużego wpływu na prędkość przesyłu danych, jednak duża liczba przeskoków (ang. hop) przez które muszą przejść pakiety może powodować opóźnienia odczuwalne przez użytkownika.


W przypadku, gdy nie mamy możliwości wybrania serwera z dogodną lokalizacją bądź chcemy, by strona działała szybko bez względu na miejsce, z którego jest ładowana, możemy rozważyć użycie tzw. CDN (Content delivery network). Systemy takie składają się z rozbudowanej sieci serwerów rozsianych po całym świecie, w których przechowywane są kopie statycznych plików ładowanych przez naszą stronę. Podczas wykonania zapytania do serwera, system CDN odsyła żądane zasoby z punktu znajdującego się najbliżej użytkownika, co znacząco zmniejsza opóźnienia.

Protokół HTTP/2

Do tej pory, w protokole HTTP 1.1, każdy żądany zasób ładowany był przy pomocy osobnego zapytania do serwera. Powodowało to, że znaczna część czasu potrzebnego na ładowanie strony, była wykorzystywana właśnie na obsługę tych zapytań, a same pliki nie mogły być pobierane jednocześnie.


Takie podejście zmieniło się wraz z wprowadzeniem standardu HTTP/2, w którym to przeglądarka nawiązuje z serwerem tylko jedno połączenie - jest ono utrzymywane aż do momentu zamknięcia strony, a zasoby ładowane są jednocześnie, zwykle przy pomocy jednego zapytania.


źródło: https://blog.cloudflare.com/http-2-for-web-developers/


Jeśli nasz dostawca na to pozwala, zdecydowanie powinniśmy włączyć obsługę protokołu HTTP/2 na serwerze. W takim wypadku powinniśmy także zrezygnować z wtyczek łączących arkusze CSS i skrypty JS w zbiorcze pliki, ponieważ taka operacja nie tylko nie przyniesie już żadnych korzyści, a może wręcz zaszkodzić - w przypadku drobnej zmiany np. w arkuszu CSS, przeglądarka pobierze sobie jedynie nową wersję zmienionego pliku, a pozostałe zaczyta z cache. Gdyby pliki były połączone, musielibyśmy od nowa ładować wszystkie style wymagane przez stronę.

Obsługa cache w przeglądarce

Bez względu na protokół używany na naszym serwerze, warto zaimplementować w nim odpowiednią obsługę cache w przeglądarce. Spowoduje to, że podczas ponownych wizyt na stronie przeglądarka nie będzie musiała pobierać zasobów z serwera, a zaczyta je z własnego lokalnego cache. Przykładowo, dla serwera Apache, można dodać w pliku .htaccess następujące dyrektywy:


<IfModule mod_expires.c>

 ExpiresActive On


# Images

 ExpiresByType image/jpeg "access plus 1 year"

 ExpiresByType image/gif "access plus 1 year"

 ExpiresByType image/png "access plus 1 year"

 ExpiresByType image/webp "access plus 1 year"

 ExpiresByType image/svg+xml "access plus 1 year"

 ExpiresByType image/x-icon "access plus 1 year"


 # Video

 ExpiresByType video/webm "access plus 1 year"

 ExpiresByType video/mp4 "access plus 1 year"

 ExpiresByType video/mpeg "access plus 1 year"


 # Fonts

 ExpiresByType font/ttf "access plus 1 year"

 ExpiresByType font/otf "access plus 1 year"

 ExpiresByType font/woff "access plus 1 year"

 ExpiresByType font/woff2 "access plus 1 year"

 ExpiresByType application/font-woff "access plus 1 year"


 # CSS, JavaScript

 ExpiresByType text/css "access plus 1 month"

 ExpiresByType text/javascript "access plus 1 month"

 ExpiresByType application/javascript "access plus 1 month"


 # Others

 ExpiresByType application/pdf "access plus 1 month"

 ExpiresByType image/vnd.microsoft.icon "access plus 1 year"

</IfModule>


W razie, gdyby zaszła potrzeba wymuszenia aktualizacji jakiegoś pliku, zawsze można skorzystać z dodatkowego parametru określającego jego wersję.


Przykładowe użycie takich parametrów dla ładowania skryptu, stylu i obrazka może wyglądać jak poniżej:


wp_enqueue_script('main', get_template_directory_uri() . '/js/app.js', array('jquery'), filemtime( get_template_directory() . '/js/app.js' ), true);

// automatyczne uaktualnianie wersji na podstawie daty modyfikacji pliku


wp_enqueue_style('main', get_template_directory_uri() . '/css/main.css', array(), filemtime( get_template_directory() . '/css/main.css' ), 'all');

// automatyczne uaktualnianie wersji na podstawie daty modyfikacji pliku


<img src=”<?php echo get_template_directory_uri();?>/assets/img/logo.png?v=2.0”>


Jak przyśpieszyć stronę internetową ?

Jest wiele metod poprawy prędkości ładowania i działania stron wordpress i każdą z nich powinniśmy dopasować do naszego konkretnego przypadku, typu strony i konfiguracji serwera. Jednak szybkość działania jest jednym z ważniejszych kryteriów odbioru strony zarówno przez użytkownika jak i algorytmy pozycjonujące. Pamiętajmy, aby regularnie testować kondycję naszej strony.

Gotowe szablony Wordpress

Jeżeli zależy nam na tym by użytkownik sprawnie otworzył naszą stronę i poruszał się po niej warto zadbać o wybór takich rozwiązań, które nie będą zbyt obciążały serweru i przeglądarki.

Szablony do każdego przeznaczenia (multipurpose)

Zamiast wybrać template z opcją multipurpose czyli dający możliwość konfiguracji wielu układów i layoutów strony głównej i podstron, wybierzmy prostszy motyw, który nie daje takiego wyboru, a przez co nie jest wyposażony w zbyt dużą ilość kodu JS i CSS.

Optymalizacja gotowych rozwiązań

Często bywa trudna lub nie jest możliwa do wykonania w takim stopniu jak dedykowanego wdrożenia wykonanego pod konkretne założenia projektowe i funkcjonalne. Zwykle rozwiązania gotowe oparte są o buildery jak Divi, Elementor. Dają one ogromne możliwości jednak kosztem jakości kodu który musi być przygotowany na wszystkie możliwości stąd często jest go po prostu za dużo, a wykorzystywany rzeczywisty jego zasób to 30-40%.

Optymalizacja prędkości i liczba zapytań do bazy danych oraz kod przeładowany różnego typu shortcodami ładującymi odpowiednie elementy do sekcji jest nieraz tak duży że technicznie nie ma możliwości optymalizacji tego rozwiązania.

Wtyczki i licencje

Często wtyczki zastosowane w gotowym szablonie Wordpress nie posiadają aktywnych licencji, co uniemożliwia ich aktualizowanie. Brak aktualizacji często prowadzi po czasie do włamania na stronę lub jej zawirusowania.

Brak logiki w panelu Wordpress

Sposób wdrożenia funkcji i działania może być mniej intuicyjny lub uciążliwy do prowadzenia aktywnie strony.