Zwiększanie wydajności responsywnych stron internetowych

Od gru 31, 2022

Był czas, kiedy można było śmiało odróżnić stronę internetową na komputery i stronę mobilną. Tak bardzo, że cała branża wyrosła wokół zmiany przeznaczenia witryn stacjonarnych na urządzenia mobilne.

Przez jakiś czas byłeś nikim, jeśli nie miałeś osobnej witryny mobilnej w osobnej domenie. Potem wszystko zaczęło się zmieniać.

Wyświetlacze mobilne poprawiły się nie do poznania. Podobnie stało się z przeglądarkami mobilnymi. Tablety wrzuciły kolejny element do równania. Pojawiło się 4G. Wyświetlacze Retina oferowały użytkownikom końcowym nowy poziom przejrzystości.

Nagle granica między komputerem stacjonarnym a telefonem komórkowym zaczęła się zacierać.

Jednocześnie rosła różnorodność rozmiarów i rozdzielczości wyświetlaczy komputerów stacjonarnych.

I rosnący ból głowy dla projektantów stron internetowych.

Dawno minęły czasy, kiedy trzeba było obsłużyć tylko kilka rozmiarów widocznego obszaru. Sprawy się komplikowały.

Na szczęście pomoc była pod ręką w postaci zapytań o media i koncepcji responsywnego projektowania.

Dzięki zapytaniom o media możliwe stało się różnicowanie stylów i układu – a nawet treści – w zależności od szerokości widocznego obszaru i rozdzielczości ekranu użytkownika. Oczywiście zapytania o media nie są bynajmniej jedynym narzędziem w torbie sztuczek responsywnego projektanta, ale można śmiało powiedzieć, że stanowią podstawę tej techniki.

To była świetna wiadomość dla urządzeń mobilnych. Responsywny projekt oznaczał, że możesz skutecznie dostarczać różne wersje tej samej witryny na różne urządzenia. Wszystko bez tworzenia osobnej witryny mobilnej w innej domenie.

Содержание показать

A co z wydajnością?

Właściciele witryn zaczynają zdawać sobie sprawę, że użytkownikom końcowym zależy na wydajności. Zwłaszcza sprzedawcy detaliczni zaczynają doceniać fakt, że skrócenie czasu ładowania o milisekundy może przełożyć się na miliony w bilansie.

Na szczęście responsywne witryny oferują jedną wyraźną przewagę wydajności w porównaniu z ich dedykowanymi kuzynami mobilnymi: wyeliminowane jest przekierowanie do domeny mobilnej.

Jednak pomimo tego responsywny projekt zyskał reputację słabej wydajności.

W pewnym sensie jest to raczej niesprawiedliwe, ale warto przyjrzeć się dodatkowym wyzwaniom związanym z wydajnością, jakie responsywny projekt stawia nieostrożnym…

Zdjęcia

Pliki obrazów są duże. A ponieważ są duże, często są winne powolnego ładowania. Są zatem dobrym miejscem do rozpoczęcia dla każdego, kto próbuje zoptymalizować wydajność witryny.

Niestety, jedno z pierwszych rozwiązań responsywnego dostarczania obrazów nie było zbyt dobre pod względem wydajności.

Technika jest pięknie prosta. Po prostu użyj max-width: 100%, aby upewnić się, że obrazy są skalowane do szerokości elementu zawierającego:

img
{
max-width: 100%;
}

Ponieważ kontener kurczy się, aby dopasować go do mniejszych rzutni, wszystkie znajdujące się w nim obrazy będą się kurczyć. Łatwy!

Ale jest problem. Rozmiar obrazu może się zmniejszyć na ekranie, ale rozmiar pliku pozostaje taki sam. Jest to dalekie od ideału z punktu widzenia wydajności. Możesz przesyłać obraz o wymiarach 800 x 800 pikseli, tylko po to, aby był wyświetlany w rozmiarze 80 x 80 pikseli: innymi słowy, możesz przesyłać setki (lub tysiące) niepotrzebnych bajtów. Nie tylko ładowanie obrazu zajmie dużo czasu, ale wszystkie te nadmiarowe bajty mogą wyczerpać cenny limit danych użytkownika końcowego.

Jednak nie jest to jedyny – ani nawet najlepszy – sposób dostarczania responsywnych obrazów. Po pierwsze, obraz, który działa przy szerokości 800 pikseli, niekoniecznie będzie działał tak dobrze w różnych ułamkach tego rozmiaru.

Aby sobie z tym poradzić, możesz użyć zapytania o media, aby wyświetlić różne wersje obrazu w zależności od rozmiaru rzutni, używając zapytania o media i wyświetlenia: brak.

CSS:

@media (min-width: 601px) {
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#largeImage
{
display:none;
}
}

HTML:

Umożliwia to wyświetlanie różnych wersji obrazu, a nie tylko tego samego obrazu w różnych rozmiarach. Nie zmniejsza to jednak liczby bajtów. W rzeczywistości całkowity rozmiar strony będzie większy, ponieważ wszystkie obrazy zostaną załadowane, niezależnie od tego, czy są wyświetlane, czy nie.

Lepszą alternatywą – jeśli jest to praktyczne – jest użycie obrazów tła zamiast elementów. Jest to preferowane, ponieważ obrazy, do których odwołuje się CSS, są ładowane tylko wtedy, gdy są używane (o ile nie są identyfikatorami URI danych):

@media (min-width: 601px) {
#largeImage
{
width:400px;
height:400px;
background-image:url(/images/largeImage.webp);
}
#croppedImage
{
display:none;
}
}
 
@media (max-width: 600px) {
#croppedImage
{
width:200px;
height:200px;
background-image:url(/images/croppedImage.webp);
}
#largeImage
{
display:none;
}
}

Działa to dobrze: odwiedzający pobierają tylko te obrazy, których potrzebują, kiedy i kiedy ich potrzebują. Problem polega na tym, że jest nieporządny, skutecznie traktując treść jako styl. W związku z tym potencjalnie stwarza problem z utrzymaniem, a także może powodować ignorowanie ważnych obrazów przez wyszukiwarki.

Zamiast tego, dlaczego nie użyć SVG (skalowalnej grafiki wektorowej): formatu obrazu, który skaluje się z natury? Obrazy SVG mają również tę zaletę, że można je łatwo stylizować za pomocą CSS (zobacz ten świetny samouczek na temat tworzenia responsywnych plików SVG za pomocą CSS). Jest to idealne rozwiązanie dla ikon i logo, ale niestety nie będziesz mógł używać plików SVG do zdjęć – w tym przypadku będziesz musiał skorzystać z formatów rastrowych, takich jak JPEG.

Inną opcją jest użycie jednego z wielu rozwiązań JavaScript w celu dostarczenia responsywnych obrazów. Jest to popularny sposób na zrobienie tego, ale dodaje kolejną warstwę złożoności. Co więcej, ponieważ JavaScript blokuje konstrukcję DOM, każde rozwiązanie wykorzystujące JavaScript może potencjalnie wstrzymać renderowanie. Tak więc, chociaż istnieje kilka bardzo sprytnych wtyczek, po prostu wprowadzając JavaScript do równania, do pewnego stopnia godzisz się na mniejsze zło.

Do niedawna były to jedyne opcje.

Teraz jednak elementy i oraz atrybuty srcset i size wreszcie wprowadzają do sieci naprawdę responsywne obrazy. Nowa specyfikacja zaczyna również zyskiwać wsparcie w przeglądarkach, z pełnym wsparciem w Chrome i Operze oraz obsługą przełączania rozdzielczości w Safari. Dopóki inne przeglądarki nie nadrobią zaległości, istnieje doskonały kod JavaScript polyfill.

W tym wspaniałym nowym świecie możesz użyć srcset, aby ustawić listę obrazów kandydujących do wybrania przez przeglądarkę. Następnie możesz użyć zapytania o media w atrybucie rozmiary, aby określić rozmiar, w jakim obraz będzie wyświetlany. Używając elementu wraz z zapytaniami o media wewnątrz jednego lub więcej elementów, możesz określićróżny zakres obrazów dla różnych warunków (np. dla rzutni o określonej szerokości użyj obrazka a, b lub c, a dla większych rzutni użyj obrazka x, y lub z). Jest to przydatne, jeśli chcesz dostarczyć przyciętą wersję obrazu dla użytkowników z małymi ekranami.

Dokładne szczegóły dotyczące korzystania z nowej składni wykraczają poza zakres tego artykułu, ale doskonały samouczek można znaleźć na stronie alistapart.

Być może jedyną wadą tej nowej specyfikacji jest to, że jest dość rozwlekła, co może oznaczać rozdęty HTML na stronach z dużą ilością obrazów. Jednak korzyści znacznie przewyższają wady.

Ładowanie CSS, którego (koniecznie) nie potrzebujesz

Chociaż zapytania o media umożliwiają stosowanie różnych reguł CSS w zależności od ustawionych kryteriów, nie można uciec od faktu, że użytkownicy końcowi będą musieli pobrać wszystkie CSS, które mogą mieć zastosowanie. Dzieje się tak nawet wtedy, gdy umieścisz CSS w oddzielnych plikach i umieścisz zapytanie o media w

elemencie.

Na przykład oba poniższe arkusze stylów zostaną załadowane niezależnie od szerokości rzutni:

To nie jest błąd przeglądarki. Kryteria stosowane w zapytaniach o media często dotyczą rzeczy, które zmieniają się podczas wizyty na stronie. Na przykład odwiedzający może zdecydować się na zmianę rozmiaru okna przeglądarki lub obrócenie tabletu/urządzenia mobilnego. Wynikająca z tego zmiana w wyświetlaniu powinna przebiegać płynnie, a wysłanie prośby o kolejny plik CSS byłoby dalekie od ideału. Jest to szczególnie prawdziwe w przypadku urządzeń mobilnych, które starają się zamknąć łącza radiowe przy najbliższej okazji, aby oszczędzać energię baterii. Potencjalna konieczność ponownego ustanowienia tego połączenia, gdy zmienia się rozmiar widocznego obszaru, może być złą wiadomością dla żywotności baterii.

Jednak Chrome stara się radzić sobie z tymi różnymi plikami w inteligentny sposób. Podczas gdy wszystkie pliki zostaną pobrane, tylko ten z aktualnie pasującym zapytaniem o media zablokuje renderowanie. Wszystkie inne zostaną załadowane z niższym priorytetem.

Niestety, inne przeglądarki nie są tak zobowiązujące. Na przykład w przeglądarce Firefox nieużywane pliki CSS nie tylko blokują renderowanie — blokują także ładowanie innych obiektów na stronie.

Poniższy wykres wodospadu ilustruje tę kwestię. Obrazy na tej stronie nie zaczną się ładować, dopóki nieużywany plik CSS nie zostanie całkowicie pobrany:

Można to obejść, używając JavaScript do warunkowego ładowania CSS, ale, jak już widzieliśmy, JavaScript wiąże się z kosztami wydajności.

`Co to wszystko oznacza dla wydajności witryny responsywnej w porównaniu z witryną mobilną?`

Cóż, użytkownicy mobilni i użytkownicy komputerów stacjonarnych w responsywnej witrynie będą musieli pobrać ten sam CSS.

Będzie ich więcej niż w witrynie przeznaczonej wyłącznie na komputery stacjonarne lub urządzenia mobilne.

Co więcej, dedykowana witryna mobilna jest bardziej skłonna do korzystania z lżejszej, uproszczonej wersji CSS na komputery stacjonarne (chociaż obecnie jest to być może mniej prawdziwe, ponieważ użytkownicy coraz bardziej oczekują bogatszych wrażeń na coraz bardziej wyrafinowanych ekranach mobilnych).

Więc jeśli inne rzeczy są równe, wygląda na to, że jest coś w argumencie, że responsywna prawdopodobnie będzie wolniejsza niż strona mobilna z powodu wymaganego dodatkowego CSS. Jednak dopóki projektanci są świadomi potencjalnych pułapek, powinni być w stanie tworzyć szybko ładujące się arkusze stylów dla responsywnej witryny. W szczególności dobrze jest:

unikaj używania identyfikatorów URI danych dla obrazów – binarne obrazy tła będą (normalnie) ładowane tylko wtedy, gdy będą potrzebne, ale wszystkie identyfikatory URI danych zostaną załadowane niezależnie od tego.
Zachowaj lekkość – ponieważ cały CSS musi zostać pobrany, ważne jest, aby był wydajny. Oznacza to unikanie powielania i upewnianie się, że globalne reguły są ustalane poza CSS opartym na zapytaniu o media.

`RESS (responsywne projektowanie stron internetowych + komponenty po stronie serwera)`

RESS to hybryda między projektowaniem responsywnym a adaptacyjnym, która polega na wąchaniu agenta użytkownika na serwerze w celu przyjrzenia się charakterystyce urządzenia klienckiego i dostarczenia odpowiedniej dla niego treści.

Jeśli jednym z zarzutów wobec responsywnego projektowania jest to, że obejmuje ono dostarczanie wszystkich treści na wszystkie urządzenia, dlaczego nie złagodzić tego, wycinając część tych treści tam, gdzie to możliwe?

To może mieć wiele sensu. Jeśli istnieje obraz, którego nigdy nie będziesz chciał wyświetlać na urządzeniach, których ekran jest mniejszy niż określony rozmiar, równie dobrze możesz go nie wysyłać na te urządzenia, oszczędzając przepustowość i skracając czas ładowania.

Co więcej, jeśli używasz zapytań o media, o których wiesz, że nie mogą być spełnione na niektórych urządzeniach, istnieje przynajmniej argument przemawiający za podzieleniem CSS na różne pliki i ładowaniem ich warunkowo.

Warto pamiętać, że cały ten proces nie jest „darmowy" pod względem wydajności. Oczywiście trzeba wykonać pewne prace na serwerze, co wymaga czasu – prawdopodobnie nie na tyle, aby przeważyć nad korzyściami, ale warto o tym pamiętać.

`Werdykt`

Czy strony responsywne są powolne?

Zależy co rozumiesz przez powolny.

Czy najszybsza responsywna witryna, którą możesz stworzyć, może być wolniejsza niż najszybsza dedykowana witryna mobilna, jaką możesz zrobić?

Prawdopodobnie.

Widzieliśmy również, że istnieje kilka pułapek. Jeśli nie będziesz ostrożny, łatwo zmusisz użytkowników do pobrania wielu zbędnych obrazów i CSS, przez co Twoja responsywna witryna będzie działać znacznie wolniej niż powinna.

Jednak wcale tak nie musi być. Stworzenie responsywnej witryny, która jest tak szybka, jak powinna, i zapewnia doskonałe wrażenia użytkownika, jest całkowicie możliwe. A ponieważ zarówno standardy, jak i przeglądarki zaczynają nadążać za tym, co programiści chcą dostarczać, powinno być coraz łatwiej.

Źródło nagrywania: instantshift.com