„Wyeliminuj blokujący renderowanie kod JavaScript” – pozbywamy się komunikatu w WordPressie

7 Comments





Zapewne wielu z Was testowało swoją witrynę za pomocą narzędzia PageSpeed Insights od Google. W większości przypadków, a może i u każdego z Was, pojawiał się komunikat:

„Wyeliminuj blokujący renderowanie kod JavaScript i CSS z części strony widocznej na ekranie”

Dlaczego w ogóle mielibyśmy to robić? Google szybko nam wyjaśnia nam przyczyny komunikatu i tutaj mamy coś o JS:

Zanim przeglądarka wyrenderuje stronę, musi ją przeanalizować. Jeżeli w trakcie analizy napotka blokujący zewnętrzny skrypt, musi się zatrzymać i pobrać zasoby JavaScript. Każda taka operacja to dodatkowy transfer danych w obie strony, który oznacza opóźnienie pierwszego wyrenderowania.

A poniżej tekst odnoszący się do arkuszy stylów:

Zewnętrzne pliki CSS blokują przeglądarki, zanim na ekranie zostanie odwzorowana zawartość strony. Wydłuża to czas oczekiwania sieci i czas wyświetlania strony.

Oznacza to nic innego jak to, że część strony internetowej widoczna bez konieczności przewijania zaraz po załadowaniu strony w przeglądarce powinna zostać pokazana użytkownikowi tak szybko jak to tylko możliwe, bez zbędnego oczekiwania na ładowanie się plików JavaScript czy CSS. Moglibyśmy tę sprawę załatwić wklejając Inline potrzebne do tego regułki i funkcje, ale w większości wypadków jest to niemożliwe, gdyż większość użytkowników WordPressa nie jest programistami jak i nie powinni bez choćby podstawowej wiedzy grzebać w kodzie tego CMSa. Co więcej, mało osób ma w ogóle świadomość istnienia plików JavaScript czy CSS, ale to już inna bajka.

Jak sobie z tym problemem poradzić? Otóż można by było skorzystać z gotowych wtyczek, ale po co śmiecić sobie zbędnymi dodatkami jak są znacznie łatwiejsze sposoby.

Metoda z asynchronicznym ładowaniem

Co to nam da? Otóż jeśli nie wiecie, to każda przeglądarka wczytuje kolejne elementy naszej strony synchronicznie, jeden po drugim i natrafiając na spory pliczek JavaScript można spowolnić ładowanie witryny, gdyż przeglądarka będzie musiała go najpierw pobrać i że tak powiem przemielić zanim zajmie się następnymi elementami, a to z kolei może sprawić, że załaduje się logo naszej strony i nic więcej, gdyż na menu musimy czekać (o ile jest generowane przez JavaScript) jak i na całą resztę strony, bo przeglądarka na razie zajmuje się naszym menu. Nieco to uprościłem, ale mam nadzieje, że zrozumieliście.

Wyobraźcie sobie, że macie w sekcji head strony taką linijkę:

Plik będzie ładował się synchronicznie w dodatku z zewnętrznego serwera. W tym przypadku najprościej by było wstawić treść tego pliku Inline:

I tym razem będzie on ładował się asynchronicznie. Jednak nie polecam takiego rozwiązania, gdyż przeglądarka domyślnie zablokuje ładowanie CSS’ów, ponieważ nie ma zielonego pojęcia co wydarzy się po przemieleniu wklejonego kodu JavaScript, który de facto może zmieniać same style.

Na szczęście pojawiło się lepsze rozwiązanie wraz ze standardem HTML5 i mając linijkę

wystarczy ją podmienić na

I to rozwiązanie nie jest wolne od problemów i niekiedy mogą one być dość poważne, gdy od jednego pliku JavaScript zależy ładowanie kolejnego. W tym rozwiązaniu nie mamy żadnej gwarancji na prawidłową kolejność wczytywania się plików JavaScript. Także to co nam jest potrzebne od razu może załadować się na końcu, a to co zbędne dostaniemy na starcie.

Tym samym wdrażając ową metodę warto sprawdzać za każdym razem czy strona ładuje się prawidłowo i to zarówno na desktopach jak i urządzeniach mobilnych. Jeśli zauważycie jakieś konflikty czy błędy to nie dodawajcie async na siłę, gdyż może to dać efekt odwrotny do zamierzonego i co więcej, może to wydłużyć, zamiast skrócić ładowanie się strony.

Sposób drugi, przenieś wszystko na dół strony

W tym przypadku musimy przejść w panelu administracyjnym WordPressa do Wygląd > Edytor > Funkcje motywu (functions.php).

Następnie wciskamy na klawiaturze Ctrl+F, a później wpisujemy w pole wyszukiwania „wp_enqueue_script”. Szukamy w pliku funkcji linijek, w których użyto owej funkcji.

Funkcja ta ma pięć parametrów, z czego jedynie pierwszy jest wymagany „$handle”:

Nas interesuje jednak ostatni parametr „$in_footer”, który decyduje o tym, gdzie będzie w kodzie ładowany skrypt JavaScript, jeśli damy false, zostanie on w headerze, a gdy damy true to wyląduje na samym dole kodu, w stopce. Dla przykładu na swoim blogu znalazłem pierwszą linię jak poniżej:

Jak widać mamy tutaj wartość „false”, którą należy zmienić na „true”, a następnie KONIECZNIE sprawdzić czy strona ładuje się prawidłowo na urządzeniach mobilnych jak i na desktopie. Policzcie u siebie ilość użytych parametrów, jeśli jest ich trzy, czyli

to najpierw musicie dać wartość pustą jako czwarty parametr

a dopiero w piątym wpisujemy false bądź true.

Jest to moim zdaniem najmniej inwazyjna metoda, ale mimo wszystko wymaga od użytkownika skupienia i przede wszystkim skopiowania zawartości pliku functions.php do choćby notatnika, aby w razie problemów móc ją bezproblemowo przywrócić.

Każda z wymienionych powyżej metod pozwoli Wam się pozbyć komunikatu „Wyeliminuj blokujący renderowanie kod JavaScript” albo choć ograniczyć ilość JavaScript’ów w nim występujących. Jeśli chodzi o pliki CSS to jest to temat na zupełnie oddzielny artykuł, gdyż z nimi już nie pójdzie nam tak łatwo.

ZNAJDZIESZ NAS NA FACEBOOKU

Otrzymuj informacje o nowościach

Polecamy także inne artykuły

Zobacz wszystkie artykuły
7 Comments
    • Bartosz
    • 25 czerwca 2015
    Odpowiedz

    Kinga, tak jest to możliwe, jeśli twoja templatka jest zbudowana w inny sposób i skrypty ładowane są po prostu w index.php lub header.php za pomocą „<script.."

    • Kinga
    • 18 czerwca 2015
    Odpowiedz

    Ja np. nie mogę wyszukać wp_enqueue_script, tak jakby go nie było. Jest to możliwe?

    • Jan Kamiński
    • 17 czerwca 2015
    Odpowiedz

    Dziękuję za ciekawe warianty!

    • insanebear
    • 17 czerwca 2015
    Odpowiedz

    Żeby wyeliminować ten błąd w przypadku plików *.css można skorzystać z @import. Trzeba jednak pamiętać że strony internetowe tworzy się dla ludzi i nie wszystko co nam podpowiada narzędzie PageSpeed Insights od Google będzie dla nas korzystne 🙂

      • Jacek Jagusiak
      • 17 czerwca 2015
      Odpowiedz

      Święte słowa, ale to co się da i nie psuje całej witryny, warto opóźniać;)

    • PanDizajn
    • 17 czerwca 2015
    Odpowiedz

    Niestety ale kazda z tych metod niedziala w przypadku stylow css, do ktorych pagespeed rowniez sie czepia.

      • Jacek Jagusiak
      • 17 czerwca 2015
      Odpowiedz

      Dlatego napisałem na końcu artykułu, że o stylach CSS będzie oddzielny wpis.

 

Leave a Comment