Nasi przyjaciele z WP Engine niedawno wprowadzili piękną nową stronę główną zbudowaną za pomocą Beaver Builder. Udostępniliśmy link do strony w grupie Beaver Builders na Facebooku i kilka osób zauważyło, że ogólny czas ładowania strony był dość długi. Nasz dobry przyjaciel i niezwykły programista WordPress, Jon Brown, przyszedł na ratunek ze świetnym wyjaśnieniem.

Rozmowa na Facebooku

Pozwolę sobie szybko sparafrazować tę rozmowę:

Zaniepokojony Beaver Builder: Wykonałem test ładowania strony za pomocą narzędzia testującego XYZ i ładowanie zajęło prawie 10 sekund!

Jon: Szybkość i wydajność to wybór projektu i ma kluczowe znaczenie dla konwersji sprzedaży, ale to nie znaczy, że nie jest to kompromis w stosunku do innych, WIĘCEJ wartościowych narzędzi.

Widzę, że ludzie często patrzą na oceny literowe i całkowity czas ładowania, nie rozumiejąc wodospadu. To zwiedzie Cię na manowce, chyba że przeglądasz bardzo proste strony…

Te klasy narzędzi testujących są naprawdę prymitywne i ignorują wiele praktycznych realiów. Powiedzą, żeby unikać przekierowań, jeśli dotyczą one reklam, skryptów śledzących i innych rzeczy, które koniecznie działają w ten sposób. Często ignorują HTTP/2 i zalecają ograniczenie żądań i łączenie zasobów, które nie miałyby znaczenia, a nawet mogłyby zaszkodzić… Nie skupiają się na indeksie prędkości i renderowaniu w części widocznej na ekranie…

Prawdziwe ładowanie strony wynosi <1,5 s

Kopmy głębiej

Zapytałem Jona, czy zechciałby zadać jeszcze kilka pytań na temat występu, a on łaskawie się zgodził. Oto moje (Robby'ego) pytania i odpowiedzi Jona.

Aha, czy wspominałem, że Jon prowadzi niestandardowy sklep programistyczny o nazwie 9seeds, więc można go zatrudnić, aby pomógł Ci udoskonalić wydajność Twojej witryny WordPress!

1. Wspomniałeś o „wodospadie”. Czy możesz wyjaśnić nieco więcej o tym, czym jest wodospad?

Istnieje wiele narzędzi pozwalających ocenić wydajność witryny. Wiele z nich zawiera raport zawierający łatwą do zrozumienia ocenę literową. Te oceny literowe są jednak dość tępym narzędziem i choć miło jest, gdy dostajesz wszystko, nie jest to szczególnie wnikliwe, nie mówiąc już o pomocne, gdy nie widzisz prosto As. Jedyna ocena literowa, którą uważam za pomocną, dotyczy kompresji obrazu, co jest łatwym rozwiązaniem, uruchom obrazy za pomocą optymalizatora.

Zbyt często widzę, jak laicy i nowicjusze programiści są zaślepieni literami. Na wydajność interfejsu WWW wpływa wiele czynników i naprawdę należy przyjrzeć się „kaskadowi”, który jest po prostu wykresem przedstawiającym wszystkie żądania HTTP, kiedy się rozpoczęły i kiedy zostały zakończone. Do ich generowania używam WebPageTest.org.

„Kaskada” to miejsce, w którym „widzisz”, jaki konkretny zasób ładuje się zbyt długo i/lub który blokuje ładowanie innych rzeczy.

Na koniec zdaj sobie sprawę, że proste As może wymagać wyborów projektowych (takich jak usunięcie suwaków) i wyeliminowania zasobów stron trzecich (takich jak Google Analytics, HotJar itp.), które są cenniejsze dla właściciela witryny niż uzyskanie A. Nie każdą witrynę można zmusić do wyprostuj się Jak bez bolesnych wyrzeczeń.

2. Jako wybrane narzędzie testowe poleciłeś WebPageTest. Dlaczego wolisz to i czym różni się od narzędzi takich jak Pingdom, GTmetrix (i/lub Google Page Speed?)?

Osobiście nigdy nie znalazłem nic lepszego i bardziej elastycznego w robieniu tego niż WebPageTest.org. Jednak w przeszłości korzystałem również z GTMetrix, Pingdom, Google Page Speed ​​i innych i wszystko było w porządku. Niektóre z nowych, jak Lighthouse, są naprawdę fajne w przypadku progresywnych aplikacji internetowych (nie w 99% witryn WordPress). Z pewnością jednak nie mówię ludziom, żeby zmieniali narzędzia, używali narzędzia, które znają i rozumieją. Jeśli nie znasz żadnego narzędzia, WPT jest świetnym darmowym narzędziem do nauki. Po prostu wyjdź poza oceny literowe i zacznij rozumieć, co jest przyczyną tych ocen.

3. Czy w związku z „ograniczaniem żądań i łączeniem zasobów” nie jest to już najlepsza praktyka? Dlaczego?

W czasach, gdy większość witryn korzystała z protokołu HTTP, a nie HTTPS, a wszystkie serwery internetowe korzystały z protokołu HTTP/1.1, serwery internetowe mogły wysyłać równolegle tylko określoną liczbę zasobów. Każdy zasób (obraz, skrypt, arkusz stylów) został wysłany osobno i każdy miał własne koszty ogólne, które spowalniały działanie. Połączenie wszystkiego, co możliwe, zmniejszyło liczbę żądań HTTP i zapewniło ogromne korzyści w zakresie wydajności.

W ciągu ostatnich kilku lat wszędzie nastąpił ogromny nacisk na protokół HTTPS, a serwery internetowe zaczęły obsługiwać nowy protokół HTTP/2. HTTP/2 ma ogromne zalety, takie jak wstępne pobieranie i wstępne ładowanie, ale może także wysyłać wszystkie te małe zasoby równolegle, więc nie ma potrzeby ich łączenia. W rzeczywistości może lepiej tego nie robić, aby każdy mały zasób mógł być buforowany niezależnie.

Należy pamiętać, że ma to zastosowanie tylko wtedy, gdy Twój serwer internetowy obsługuje protokół HTTP/2 i jest to możliwe tylko wtedy, gdy Twoja witryna korzysta z protokołu HTTPS.

To powiedziawszy, wszystkie witryny, nad którymi obecnie pracujemy, korzystają z protokołu HTTPS i działają na serwerach obsługujących protokół HTTP/2, więc na tym etapie nawet nie myślę już o łączeniu zasobów i na pewno nie tęsknię za tym!

4. Czy są jakieś inne „mity” lub przestarzałe zalecenia dotyczące wydajności, które odradzasz?

Najważniejszym jest po prostu to, że każda witryna może działać poprawnie bez bolesnych ustępstw, takich jak zmiany w projekcie lub eliminowanie zasobów stron trzecich, nad którymi nie masz kontroli. Jednak to naprawdę OK, ponieważ powinieneś zacząć patrzeć na coś, co nazywa się Indeksem Prędkości! WPT ma dobry opis na ten temat, ale zasadniczo bierze pod uwagę to, kiedy „powyżej części” jest postrzegane przez użytkownika jako w pełni załadowane. Liczy się szybkość działania, a nie fakt, że strona jest naprawdę kompletna. To była jedna z rzeczy związanych z nowym projektem strony głównej WP Engine, indeks prędkości był niesamowity. To właśnie odroczone skrypty zajmowały dużo czasu, aby się załadować i ukończyć.

5. Czy masz jakieś inne narzędzia, wskazówki lub triki zwiększające wydajność, które poleciłbyś komuś?

Narzędzia, na których polegam przez lata:

• WebPageTest.org – Mój ulubiony!
• ImageOptim – aplikacja komputerowa do kompresji plików JPG/PNG
• ImageAlpha – aplikacja komputerowa do kompresji plików PNG (głównie poprzez zmniejszenie liczby kolorów)
• CloudFlare – bezpłatny jako ogromny globalny CDN i podstawowy WAF. Plus imponujące płatne funkcje profesjonalne, takie jak optymalizacja obrazu w locie, optymalizacja tras i inne.

Wtyczki:

• WP Rocket – Nawet na WP Engine używamy WP Rocket, to po prostu działa.
• Imagify.io – Optymalizacja obrazu w oparciu o WordPress/chmurę.
• BeaverBuilder – nie zapłacono mi za to, abym to mówił! Jesteśmy wzywani do przeprowadzania audytów wydajności w wielu witrynach i często zauważamy poważne problemy z interfejsem i backendem w przypadku innych popularnych narzędzi do tworzenia stron. Nie będę wymieniać nazwy, ale nie w przypadku Beaver Builder, dlatego używamy go w naszej własnej witrynie jako Dobrze!

Jeszcze raz dziękuję Jon za poświęcenie czasu na przedstawienie nam bardziej nowoczesnego podejścia do wydajności. Chciałem dać jeszcze jedną szansę agencji Jona, 9seeds. Jeśli szukasz pomocy przy jakimkolwiek niestandardowym rozwoju WordPressa, zadzwoń do nich!

O Jonie Brownie

Wędrowiec. Programista WordPressa. Fotograf. Wątroba Życia.