Jeden rozmiar dla niektórych: przewodnik po rozwiązaniach do projektowania responsywnych stron internetowych

Ponieważ urządzenia mobilne i tablety zbliżają się do ostatecznej dominacji nad światem, projektowanie stron internetowych i technologia są w wyścigu, aby dostosować się do stale rosnącej liczby rozmiarów ekranów. Jednak opracowywanie narzędzi, które sprostają wyzwaniom tego zjawiska, niesie ze sobą zupełnie nowy zestaw problemów, a jednym z najnowszych modnych słów, które się pojawiły, jest „responsywna sieć”. Wyzwaniem jest sprawienie, by sieć działała na większości, jeśli nie na wszystkich, urządzeniach bez pogorszenia doświadczenia użytkownika. Zamiast projektować treści na komputery stacjonarne lub laptopy, informacje muszą być dostępne dla telefonów komórkowych, tabletów lub dowolnej powierzchni podłączonej do sieci. Jednak ta ewolucja responsywnego projektowania stron internetowych okazała się trudna i czasami bolesna.

Chociaż umieszczenie informacji tekstowych może być niemal trywialne, trudna część pojawia się, gdy bierzemy pod uwagę treści, takie jak responsywne obrazy, infografiki, filmy itp., które kiedyś były projektowane wyłącznie z myślą o komputerach stacjonarnych. Pojawia się nie tylko pytanie o prawidłowe wyświetlanie treści, ale także o to, jak sama treść jest konsumowana na różnych urządzeniach. Użytkownicy smartfonów różnią się od użytkowników komputerów stacjonarnych. Należy również wziąć pod uwagę takie rzeczy, jak plany danych i szybkość przetwarzania. Google zaczął podkreślać witryny przyjazne dla urządzeń mobilnych w swoich wynikach wyszukiwania, a niektórzy spekulują, że doprowadzi to do znacznego wzrostu PageRank dla takich witryn. Wcześniejsze rozwiązania rozwiązały ten problem, wdrażając subdomeny tylko dla urządzeń mobilnych (i przekierowania), ale to zwiększyło złożoność i szybko wyszło z mody. (Nie każda witryna jest w stanie pozwolić sobie na tę trasę.)

W poszukiwaniu responsywnych obrazów internetowych

W tym momencie programiści i projektanci muszą upewnić się, że obciążenie ich witryny jest zoptymalizowane, aby sprostać użytkownikom witryn mobilnych. Ponad 20% ruchu w sieci to obecnie użytkownicy mobilni, a liczba ta wciąż rośnie. Ponieważ obrazy mają największy udział w danych dotyczących zawartości strony, priorytetem staje się zmniejszenie tego obciążenia. Podjęto kilka prób uproszczenia responsywnej zmiany rozmiaru obrazu projektu, w tym rozwiązań zarówno po stronie serwera, jak i front-end. Aby omówić te responsywne rozwiązania graficzne, musimy najpierw zrozumieć obecne niedociągnięcia w łączeniu obrazów.

Znacznik <img> ma tylko atrybut źródła, który łączy się bezpośrednio z samym obrazem. Nie ma możliwości określenia prawidłowego typu obrazu potrzebnego bez żadnych dodatków.

Czy nie możemy po prostu mieć wszystkich rozmiarów obrazów zawartych w HTML i użyć reguł CSS, aby display:none dla wszystkich, ale poprawny obraz? To najbardziej logiczne rozwiązanie w idealnym logicznym świecie. W ten sposób przeglądarka może zignorować wszystkie niewyświetlane obrazy i teoretycznie nie pobierać ich. Jednak przeglądarki są zoptymalizowane poza zwykłą logikę. Aby strona renderowała się wystarczająco szybko, przeglądarka wstępnie pobiera linkowaną treść, zanim nawet niezbędne arkusze stylów i pliki JavaScript zostaną w pełni załadowane. Zamiast ignorować duże obrazy przeznaczone na komputery stacjonarne, w końcu pobraliśmy wszystkie obrazy i spowodowało to jeszcze większe ładowanie strony. Technika CSS-only działa tylko w przypadku obrazów przeznaczonych jako obrazy tła, ponieważ można je ustawić w arkuszu stylów (za pomocą zapytań o media).

Więc co ma zrobić strona internetowa?

Rozwiązania do responsywnego skalowania obrazu zaplecza

Wyłączając witryny/subdomeny wyłącznie na urządzenia mobilne, pozostaje nam sniffowanie klienta użytkownika (UA) i używanie go do wyświetlania użytkownikowi obrazów o odpowiednim rozmiarze. Jednak każdy programista może potwierdzić, jak zawodne może być to rozwiązanie. Nowe ciągi UA pojawiają się cały czas, co sprawia, że ​​utrzymywanie i aktualizowanie wyczerpującej listy jest uciążliwe. I oczywiście nie bierze to nawet pod uwagę przede wszystkim zawodności łatwo sfałszowanych ciągów UA.

Obrazy adaptacyjne

Warto jednak rozważyć niektóre rozwiązania po stronie serwera. Adaptive Images to świetne rozwiązanie dla tych, którzy preferują responsywną poprawkę obrazu zaplecza. Nie wymaga żadnych specjalnych znaczników, ale zamiast tego używa małego pliku JavaScript i wykonuje większość ciężkiej pracy w swoim pliku zaplecza. Używa serwera skonfigurowanego w PHP i nginx. Nie polega również na wąchaniu UA, ale zamiast tego sprawdza szerokość ekranu. Adaptive Images świetnie sprawdza się przy zmniejszaniu obrazów, ale jest również przydatne, gdy duże obrazy wymagają ukierunkowania artystycznego, tj. redukcji obrazu za pomocą technik takich jak przycinanie i obracanie, a nie tylko skalowania.

Sencha Dotyk

Sencha Touch to kolejne rozwiązanie responsywnego projektowania obrazu zaplecza, chociaż lepiej jest określać je jako rozwiązanie innej firmy. Sencha Touch odpowiednio zmieni rozmiar obrazu, powąchając UA. Poniżej znajduje się podstawowy przykład działania usługi:

 <img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">

Istnieje również możliwość określenia rozmiarów obrazu, na wypadek gdybyśmy nie chcieli, aby Sencha zmieniał rozmiar obrazu automatycznie.

W ostatecznym rozrachunku rozwiązania po stronie serwera (i stron trzecich) wymagają zasobów do przetworzenia żądania przed odesłaniem prawidłowego obrazu. Zabiera to cenny czas, a to z kolei spowalnia podróż na żądanie-odpowiedź. Lepszym rozwiązaniem może być, gdyby urządzenie samo określiło, które zasoby bezpośrednio zażądać, a serwer odpowiednio zareaguje.

Rozwiązania front-endowe

W ostatnim czasie po stronie przeglądarki wprowadzono duże ulepszenia dotyczące responsywnych obrazów.

Element <picture> został wprowadzony i zatwierdzony w specyfikacji HTML5 przez W3C. Obecnie nie jest powszechnie dostępny we wszystkich przeglądarkach, ale wkrótce będzie dostępny natywnie. Do tego czasu używamy wypełniaczy JavaScript dla elementu. Wypełnienia są również doskonałym rozwiązaniem dla starszych przeglądarek, w których brakuje tego elementu.

Istnieje również przypadek atrybutu srcset , który jest dostępny dla kilku przeglądarek opartych na webKit dla elementu <img> . Może to być używane bez JavaScriptu i jest świetnym rozwiązaniem, jeśli przeglądarki inne niż webKit mają być ignorowane. Jest to przydatna przerwa w nietypowym przypadku, w którym inne rozwiązania nie spełniają oczekiwań, ale nie należy ich traktować jako kompleksowego rozwiązania.

Wypełnianie zdjęć

Picturefill to biblioteka wypełniaczy dla elementu <picture> . Jest to jedna z najpopularniejszych bibliotek wśród rozwiązań front-endowych do responsywnych problemów z rozmiarami i skalowaniem obrazów. Istnieją dwie wersje; Picturefill v1 naśladuje element <picture> przy użyciu span , podczas gdy Picturefill v2 używa elementu <picture> wśród przeglądarek, które już go oferują, i zapewnia wypełnienie dla starszych (na przykład dla IE >= IE9). Ma pewne ograniczenia i rozwiązania, w szczególności dla Androida 2.3 — co, nawiasem mówiąc, jest przykładem tego, gdzie z pomocą przychodzi atrybut img srcset . Poniżej znajduje się przykładowy znacznik do używania Picturefill v2:

 <picture> <source media="(min-width: 768px)"> <source media="(max-width: 767px)"> <img alt="My Kitty Cat"> </picture>

Aby poprawić wydajność użytkowników z ograniczonymi planami transmisji danych, Picturefill można połączyć z leniwym ładowaniem. Jednak biblioteka może oferować szerszą obsługę przeglądarek i rozwiązywać dziwne przypadki, zamiast polegać na łatkach.

Imager.js

Imager.js to biblioteka stworzona przez zespół BBC News do tworzenia responsywnych obrazów z innym podejściem niż to, które stosuje Picturefill. Podczas gdy Picturefill próbuje przenieść element <picture> do nieobsługiwanych przeglądarek, Imager.js skupia się na pobieraniu tylko odpowiednich obrazów, jednocześnie obserwując szybkość sieci. Zawiera również leniwe ładowanie bez polegania na bibliotekach innych firm. Działa poprzez użycie elementów zastępczych i zastąpienie ich elementami <img> . Poniższy przykładowy kod wykazuje to zachowanie:

 <div> <div class="image-load" data-src="http://example.com/images/kitty_{width}.jpg" data-alt="My Kitty Cat"></div> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

Wyrenderowany kod HTML będzie wyglądał tak:

 <div> <img src="http://example.com/images/kitty_480.jpg" data-src="http://example.com/images/kitty_{width}.jpg" alt="My Kitty Cat" class="image-replace"> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

Obsługa przeglądarek jest znacznie lepsza niż w przypadku Picturefill kosztem bycia bardziej pragmatycznym rozwiązaniem niż przyszłościowe.

Tasowanie źródła

Tasowanie źródła podchodzi do problemu responsywnego obrazu pod nieco innym kątem niż reszta bibliotek front-end. Przypomina coś ze szkoły myślenia „mobile first”, gdzie domyślnie obsługuje najmniejszą możliwą rozdzielczość. Po wykryciu, że urządzenie ma większy ekran, zamienia źródło obrazu na większy obraz. Wydaje się, że jest to bardziej hack, a mniej pełnoprawna biblioteka. Jest to świetne rozwiązanie głównie dla witryn mobilnych, ale oznacza, że ​​podwójne pobieranie zasobów na komputery stacjonarne i/lub tablety jest nieuniknione.

Niektóre inne godne uwagi biblioteki JavaScript to:

• HiSRC - Wtyczka jQuery do responsywnych obrazów. Problemem może być zależność od jQuery.
• Mobify.js — bardziej ogólna biblioteka dla responsywnych treści, w tym obrazów, arkuszy stylów, a nawet JavaScript. „Przechwytuje” DOM przed załadowaniem zasobów. Mobify to potężna, wszechstronna biblioteka, ale może być przesadą, jeśli celem są tylko responsywne obrazy.

Streszczenie

Ostatecznie to od programisty zależy, które podejście do responsywnego projektowania obrazów internetowych będzie pasować do bazy użytkowników. Oznacza to, że zbieranie i testowanie danych da lepsze wyobrażenie o przyjmowanym podejściu.

Podsumowując, poniższa lista pytań może być pomocna do rozważenia przed podjęciem decyzji o odpowiednim responsywnym rozwiązaniu graficznym.

• Czy starsze przeglądarki stanowią problem? Jeśli nie, rozważ zastosowanie bardziej nowoczesnego podejścia (np. Picturefill, atrybut srcset )
• Czy czas odpowiedzi jest krytyczny? Jeśli nie, wybierz rozwiązanie innej firmy lub rozwiązanie zaplecza.
• Czy rozwiązania mają być własne? Rozwiązania firm trzecich będą oczywiście wykluczone.
• Czy w witrynie, która próbuje przejść na obrazy responsywne, znajduje się już wiele obrazów? Czy istnieją obawy dotyczące walidacji lub tagów semantycznych (a raczej tagów niesemantycznych)? Będzie to wymagało rozwiązania zaplecza do kierowania żądań obrazów do czegoś takiego jak obrazy adaptacyjne.
• Czy ukierunkowanie artystyczne jest problemem (szczególnie w przypadku dużych obrazów z dużą ilością informacji)? Biblioteka taka jak Picturefill będzie lepszym rozwiązaniem w takim scenariuszu. Ponadto każde rozwiązanie zaplecza również będzie działać.
• Czy istnieje obawa o brak JavaScript? Żadne z rozwiązań front-endowych nie będzie wchodziło w rachubę, co pozostawia opcje back-endowe lub strony trzecie, które opierają się na sniffowaniu UA.
• Czy czasy odpowiedzi na urządzeniach mobilnych mają pierwszeństwo przed czasami odpowiedzi na komputerach stacjonarnych? Biblioteka taka jak tasowanie źródła może być bardziej odpowiednia.
• Czy istnieje potrzeba zapewnienia responsywnego zachowania w każdym aspekcie witryny, a nie tylko w obrazach? Mobify.js może działać lepiej.
• Czy osiągnięto idealny świat? Użyj display:none podejścia!