Responsywny projekt to za mało, potrzebujemy responsywnej wydajności

Ostatnio natrafiałem na wiele responsywnych stron internetowych z wieloma problemami z wydajnością. Na większości z nich problemy są tak oczywiste, że są prawie bezużyteczne na niczym poza najnowszą generacją smartfonów. Biorąc pod uwagę fakt, że responsywność jako koncepcja ma na celu dotarcie do szerszego grona odbiorców, wydaje się to raczej nieproduktywne.

Największym wkładem w ten problem jest wciąż dominujący paradygmat projektowania komputerów stacjonarnych. Myślenie z perspektywy mobile-first wydaje się rozwiązać ten problem, ale samo to nie gwarantuje zadowalającej wydajności. Wydaje się, że wszyscy zbytnio polegamy na mniej lub bardziej wdzięcznej degradacji. Opieramy się na podkładkach i wypełniaczach, aby zapewnić brakującą funkcjonalność. Opieramy się na bibliotekach, które umożliwiają szybki rozwój i wspierają, gdy problemem jest kompatybilność przeglądarek.

„Dlaczego się martwić?” możesz zapytać. „Większość naszych gości ma smartfony o wysokiej wydajności z najnowszymi wersjami systemu operacyjnego. Poradzą sobie z naszymi stronami. Analitycy nam to mówią.

Przykro mi z powodu tej kłótni, ale myślę, że zasługuje na to, by głośno powiedzieć, że większość użytkowników Twojej witryny będzie mogła korzystać z Twojej witryny. Jeśli nie widzisz w swoich analizach Androida 2.3, czy to oznacza, że ​​nie ma użytkowników z tymi urządzeniami? A może oznacza to, że Twoja witryna nie ma nic do zaoferowania tym użytkownikom? Weź pod uwagę, że wiele urządzeń tej generacji wciąż znajduje się na półkach sklepowych, kupowanych zupełnie nowych nawet dzisiaj. Nie powinieneś odrzucać tego wprost jako technologii z przeszłości.

Dlatego chciałbym opowiedzieć o idealnych przypadkach i rzeczywistych celach tworzenia stron internetowych. Oraz o praktykach i paradygmatach, które przybliżają nas do tych celów.

Paradygmat projektowania „cegła pierwsza”

Znaczną część rocznej sprzedaży telefonów nadal zajmują telefony z internetem. Jeszcze większa część populacji nie kupuje telefonów każdego roku, ale mimo to ma w swoim posiadaniu jakieś urządzenie z obsługą sieci. Dodaj do tych liczb smartfony ostatniej generacji, które wciąż są w użyciu, dodaj rozpałki i inne urządzenia obsługujące Internet (urządzenia WAP, telewizory, tostery, koszulki i klocki). Dodaj je wszystkie, a możesz osiągnąć oszałamiającą sumę.

Rozważ przypadki użycia dla tej grupy odbiorców. Nie będą czytać długich artykułów, przeglądać i wyszukiwać informacji na swoich urządzeniach. Mogą jednak przejść przez okropności wpisywania adresu URL na klawiaturze numerycznej i poruszania się po stronie za pomocą klawiszy kierunkowych, aby uzyskać numer telefonu lub dwukrotnie sprawdzić adres w locie.

Jak trudno jest nam zatem zaimplementować układ sub-mobile-first, który będzie dostarczał tylko te informacje urządzeniom poniżej pewnego progu możliwości i wydajności?

Wdzięczna poprawa

Z łagodną degradacją jako minimalną najlepszą praktyką, stworzyliśmy ogólną zasadę, która (do pewnego stopnia) utrudnia myślenie poza nią. Gdy nastąpi już pełna wdzięku degradacja, z pewnością możemy powiedzieć, że nasza praca została wykonana i dobrze wykonana. Coraz częściej nawet nie musimy o tym myśleć, ponieważ jest już objęty różnymi używanymi frameworkami i bibliotekami. I wreszcie wypełnienie i podkładki całkowicie eliminują potrzebę pogorszenia funkcjonalności w niektórych przypadkach.

W miarę jak funkcjonalność ta staje się coraz bardziej dostępna, potrzeba myślenia o niej (nie mówiąc już o jej przekroczeniu) staje się coraz bardziej odległa.

Z punktu widzenia tego artykułu można to rozbić tak:

Niewłaściwa degradacja: Jeśli funkcja nie jest łatwo dostępna, implementacja kończy się niepowodzeniem w taki sposób, że staje się bezużyteczna lub niepraktyczna.

Łagodna degradacja: jeśli funkcja nie jest łatwo dostępna, zawodzi w sposób, który nadal zapewnia akceptowalną użyteczność.

Niewłaściwa poprawa: Jeśli funkcja nie jest łatwo dostępna, jest emulowana przez wypełnienie lub podkładkę.

Tam problem rozwiązany.

No chyba, że ​​weźmiesz pod uwagę wydajność tych samych urządzeń z niższej półki.

Ze względu na brak mocy obliczeniowej i możliwości przetwarzania danych ich młodszego rodzeństwa, są proszeni o przenoszenie znacznie większego obciążenia. Przyjmowanie wypełniaczy jako rozwiązania stwarza iluzję, że wszystkie nowoczesne funkcjonalności są teraz dostępne na wszystkich urządzeniach i można z nich korzystać bez obaw.

I tak na wszelki wypadek wdrażasz modernizr i wypełniasz wszystko. Najmniej kompetentne urządzenie w końcu ładuje największą ilość danych i wykonuje największą ilość przetwarzania. Zapewniając w ten sposób „najlepsze” wrażenia użytkownika końcowego.

Pomysł wdzięcznego ulepszenia odwróciłby tę koncepcję, zaczynając od najniższych wymagań dotyczących funkcji i wczytując aktualizacje, aż do uzyskania optymalnej równowagi między wydajnością a użytecznością w oparciu o możliwości urządzenia. W ten sposób ruch danych i wymagania dotyczące przetwarzania zostałyby przeniesione na urządzenia najlepiej nadające się do ich obsługi.

Jasne, w tej chwili koncepcja jest nadmiernie złożona: nie jest wspierana przez większość frameworków i bibliotek, w większości nie jest omawiana, a odniesień do takich praktyk jest niewiele, odległych i zlokalizowanych na mikrofunkcjach. Ale w pewnym momencie tak było ze wszystkimi koncepcjami i funkcjonalnościami.

Może, ale czy musi?

Inną najlepszą praktyką przy tworzeniu stron internetowych jest sprawdzenie, czy funkcja jest dostępna na urządzeniu przed jej aktywacją.

Pamiętaj jednak, że możesz zainstalować najnowszą wersję Google Chrome na swoim starym telefonie z Androidem i będzie ona twierdzić, że może uruchamiać animacje CSS, WebGL, efekty paralaksy w tle i wiele innych funkcji. Ale tak naprawdę, naprawdę , nie może. Tak bardzo, że przeglądarka ulegnie awarii, a całe urządzenie przestanie odpowiadać do tego stopnia, że ​​będzie musiało zostać ponownie uruchomione, aby odzyskać kontrolę.

Ten problem zaczął ostatnio w znaczący sposób wpływać na aplikacje na Androida (z punktu widzenia użytkownika). Jedna z najbardziej zauważalnych degradacji w tym sensie wpłynęła na aktualizację aplikacji Google Talk/Hangouts, która przekształciła ich usługę z najlżejszej dostępnej aplikacji do czatu w prawie bezużyteczną aplikację z powodu problemów z wydajnością na starszych urządzeniach. (Aby jeszcze raz podkreślić ten punkt: „starszy” oznacza tutaj, że nadal można go kupić od ręki, zupełnie nowy w prawie każdym sklepie). Ten sam problem dotyczył aplikacji YouTube i Twitter (z mojego doświadczenia) i najwyraźniej wielu innych.

Poświęć więc chwilę na etapie planowania, aby ocenić wartość kluczowej funkcji o wysokiej wydajności w porównaniu z najnowocześniejszym makijażem. Lub przynajmniej pozostaw ostatnią generację swojej aplikacji/usługi/treści w jakiejś formie dla starszych użytkowników. A propos…

Pozwól użytkownikom zrezygnować z Bleeding Edge

Czy zdarzyło Ci się kiedyś próbować korzystać z Gmaila na starym urządzeniu lub przez słabe połączenie? Ten link „załaduj podstawowy HTML” z pewnością się przyda.

Dlaczego Twoja nowoczesna, responsywna, animowana, zorientowana na dotyk witryna internetowa nie ma takiej funkcjonalności?

Pomyśl o tym: zażądałeś, aby był responsywny, dzięki czemu możesz dotrzeć do większej liczby potencjalnych klientów. Zrobiłeś to nowatorskie, aby pozostawić jak najlepsze pierwsze wrażenie. Dzięki temu mniej potencjalnych klientów może dotrzeć nawet do podstawowych informacji o Tobie i Twoich usługach. Jeśli wdzięczna poprawa jest dla Ciebie zbyt kosztowną koncepcją, dlaczego nie zaoferujesz swoim odwiedzającym przynajmniej opcji dostępu do wersji tekstowej treści, jeśli wersja „WOW” jest zbyt duża dla ich urządzeń.

Czy naprawdę potrzebujesz całej biblioteki?

Wreszcie, ostatnią dobrą praktyką, którą chciałbym nieco wykroczyć poza standard, jest „użyj albo strać”. Śledzenie, które biblioteki i moduły są faktycznie używane i uwzględnianie tylko ich, jest czasami nużące, ale utrzymywanie całego zestawu narzędzi na każdej stronie jest po prostu niechlujne.

Ostatnio zacząłem śledzić, ile funkcji faktycznie używam po dołączeniu biblioteki. A najczęściej używam narzędzia jQuery. Często stwierdzam, że użyłem tylko jednej lub dwóch funkcjonalności (takich jak $.extend lub $.ready), a co gorsza, że ​​użyłem go tylko do pobrania elementów według klasy lub ID. Czasami tak to zostawiam, innym razem wracam do kodu, aby usunąć lub odłączyć zależność.

Czy nie byłoby fajnie, gdybyś mógł automatycznie analizować, co i jaka część biblioteki została wykorzystana i schudnąć na podstawie wyników?

Wiele bibliotek i aplikacji oferuje opcję dostosowania wyposażenia przed rozpoczęciem korzystania z niego. Ale wciąż mam wrażenie, że standaryzacja zautomatyzowanej architektury kompilacji „użyj lub strać” w naszych bibliotekach nie powinna być zbyt daleko poza naszym zasięgiem.

Mam alergię na podejście „uwzględnij wszystko”. Ale używanie go w połączeniu z taką funkcjonalnością może zmienić podejście do czegoś podobnego do płytki prototypowej: nadmiernie elastycznego narzędzia programistycznego, które jest minimalizowane nie tylko pod względem składni, ale także samej rzeczywistej funkcjonalności.

Wymagana byłaby tylko deweloperska wersja biblioteki, która poprzez test jednostkowy zależnej funkcjonalności umożliwiłaby śledzenie używanych funkcji i wyprowadzanie minimalnej zależności lub przynajmniej skali wykorzystania (np. pytanie, czy dołączyłem jQuery na 8% jego funkcjonalności lub 80%). Dane wyjściowe zależności można następnie wykorzystać do wybierania, agregowania i minimalizowania danych wyjściowych do produkcji.

Ale co mogę z tym zrobić?

Przede wszystkim zaangażuj się w problem . Pomyśl o tym, porozmawiaj o tym z rówieśnikami i spróbuj dostrzec problem w rzeczywistych scenariuszach.

Wypróbuj to. Wykop telefon ostatniej generacji, który schowałeś gdzieś w szufladzie. Wypróbuj go na własnych stronach internetowych i sprawdź, czy treści można używać nawet zdalnie. Idź odwiedzić krewnych z przeszłości w kraju i spróbuj być dla nich ewangelistą technologicznym. Sprawdź, czy ich opóźnienie w adopcji technologii jest rzeczywiście ułatwione przez problemy z dostępnością.

Jeśli jesteś kupującym zlecającym witrynę internetową, poproś o (przynajmniej) pomoc na niskim poziomie w tej sprawie. Pamiętaj: celem nie jest stworzenie pełnego portu wszystkich Twoich funkcji na urządzenia niskiego poziomu. Jedyne, o co się prosi, to to, że ci użytkownicy otrzymają Twoje dane kontaktowe zamiast awarii ich urządzenia.

Odłóż na to rzeczywiste zasoby: najprostsze rozwiązanie problemu nie powinno zająć więcej niż dzień lub dwa i trochę przyszłościowego myślenia. Pamiętaj o najbardziej podstawowych powodach, dla których warto stworzyć stronę internetową (nie mówiąc już o tworzeniu strony responsywnej).

Jeśli jesteś programistą pakietów pracującym nad biblioteką, frameworkiem, pakietem lub jakimkolwiek innym oprogramowaniem do osadzenia: to Ty możesz zrobić tutaj największą różnicę. Jeśli możesz ułatwić lub włączyć te koncepcje do swojej platformy, wpłyniesz na cały krajobraz tworzenia stron internetowych. Jeśli włączysz go do swojego projektu opakowania, daj mi znać, a będę ewangelizować dla Ciebie.

I wreszcie, **jeśli jesteś programistą lub projektantem**, nie poprzestawaj na sprawdzonych metodach. Zawsze staraj się spojrzeć trochę poza ten horyzont. Ciężka praca jest na Tobie, aby promować te koncepcje, o które nikt jeszcze nie prosił, które są nieobsługiwane i nieudokumentowane, z korzyścią dla Twoich klientów i użytkowników.

Ostatecznie, jeśli chcesz słyszeć, jak ktoś opowiada o tym godzinami i znaleźć się w pobliżu Zagrzebia, daj mi znać. Możemy iść na filiżankę kawy.