Chrome Dev Summit 2017 w pigułce

C

Artykuł ten powstał w oparciu o wszystkie nagrania z konferencji Chrome Dev Summit 2017. Dobre dziesięć godzin konkretnego mięsa. Opiszę co ciekawsze, więc polecam usiąść wygodnie z dobrą kawą i zacząć czytać, by nie tracić czasu 🙂

tl;dr: Google chce byśmy budowali serwisy zgodnie z PWA, zmniejszali wielkość plików javascript, korzystali z web componentów oraz dobrze konfigurowali autouzupełnianie formularzy. Zapowiedzieli tylko kilka funkcji związanych z płatnościami, uwierzytelnianiem, Chrome Dev Toolami oraz użytecznością samego Chrome’a.

Na konferencjach Google zazwyczaj widzi się trzy rzeczy:

  • promowanie webowych technologii, których chcą byśmy używali
  • ogłaszanie nowych funkcjonalności
  • dzielenie się praktycznymi poradami dla web developerów

Ale czasami „ogłaszają” coś, co już kiedyś ogłaszali próbując na siłę wypromować swoją technolgię. Czasami zalecają coś, co wcale nie jest praktyczne albo jeszcze nie jest praktyczne, ponieważ jest dopiero w becie lub, o zgrozo, działa tylko w Chromie.

Co Google chce byś robił

    • Twórz Progresive Web Apps. A dokładniej mówiąc, Service Workery, które czynią cuda kiedy jesteśmy w offline. Googlowi bardzo na tym zależy, gdyż iOS obecnie tego nie wspiera. Apple co prawda na początku tego roku rozpoczęło pracę nad SW, natomiast fartem będzie, jeśli obsługa Service Workerów pojawi się w iOS 12.
    • Zmniejszaj wielkość javascriptu na stronie. Google rekomenduje 5-cio sekundowy budżet interakcji, po którym, strona musi być funkcjonalna, nawet na Androidach za mniej niż 400 zł. Przykład braku interakcji do końca ładowania poniżej:

      Developerzy z dużych korpo są zazwyczaj przyzwyczajeni do nowych iPhone’ów czy wypasionych Androidów, na których nie da się dostrzec braku interakcji w rekomendowanym przez Google budżecie. Na tanich telefonach, Google szacuje, że zazwyczaj można sobie pozwolić na góra 1 MB zminimalizowanego, nieskompresowanego javascriptu lub 150 KB skompresowanego gzipem. Trudno przekonać developerów do tych ograniczeń, ponieważ wymaga to gruntownej przebudowy struktury js’a czy nawet pozbycia się, powszechnie lubianych frameworków.
    • Używaj Web Componentów. Pomimo iż API Web Componentów ma ciekawsze alternatywy (chociażby React) i jest nieprzyjemne w używaniu, Google sądzi, że pomoże w realizacji zmniejszania objętości javascriptu.
    • Popraw formularze by wspierały autouzupełnianie, włącznie z logowaniem i płatnościami. Nadal mnie szokuje, jak wiele stron e-commerce nie wspiera autouzupełnianych formularzy, w szczególności na mobile. Tym bardziej szok, w momencie, w którym Chrome wspiera Payment Request API.
      Przykład Payment Request API

Google ogłosiło

Płatności: podobne do tego co było, ale inne

Mowa oczywiście o Google Payment API. Po zamianie Google Checkout z Google Wallet, a następnie z Android Pay, nowy twór z dumą ogłaszają jako „Najnowszy sposób na płacenie z Google” 🙄

Google Payment API działa tylko w Chrome dla Androida: integruje się ze „standardowym”, ale słabo obsługiwanym Payment Request API. Mam nadzieję, że z czasem support obejmie wszystkie platformy.

W tym samym czasie ogłosili także, że Payment Request API wspiera Chrome na wszystkich platformach, a nie tylko, jak dotychczas Androida.

Autoryzacja: podobna do tego co już mają, ale inna

Ogłosili dwie nowe funkcje, „Automatyczne logowanie” i „Logowanie jednym kliknięciem”.

Oczywiście, od wielu lat możesz logować się za pomocą „Google Sign In”. W tej wersji jest to animowany toast, który pojawia się u dołu ekranu, umożliwiając użytkownikowi zalogowanie się w Google.

Usprawnienia Chrome Dev Tools

Pokazali przede wszystkim: inspekcję siatki CSS Grid, lokalne nadpisania styli, nowy monitor podglądu wydajności (w czasie rzeczywistym), czy ulepszenia konsoli (filtrowanie i grupowanie podobnych zdarzeń). Ciężko jest to opisać, dlatego proponuję obejrzeć film z prezentacji.

Raport użyteczności Google Chrome

Raport dotyczący zadowolenia użytkowników z korzystania z Google Chrome to utworzony przez firmę BigQuery zestaw danych dotyczących rzeczywistych danych monitorowania użytkowników dla 1000 najlepszych witryn. Mam nadzieję, że ktoś zrobi z tym coś fajnego 🙂

Samo gadanie

Każde przemówienie trwało po 30 min. Przyznaję, że były dziwne i bardzo niespójne, często jedno wystąpienie dzieliło kilku mówców, a ich rozmowy nie miały ze sobą wiele wspólnego

Nawet gdy był jeden mówca, często miałem wrażenie, że miał on listę rzeczy do wyrzucenia z siebie, niezależnie od jakości wypowiedzi.

  • Keynote(Ben Galbraith i Dion Almaer): Service Workers, HTTPS, autouzupełnianie, autoryzacja, web media API, Web Komponenty, CSS Grid, ES6 + ES2016, WASM, MDN Web Docsy, Dev Tools
  • Zacznijmy przygodę z PWA(Ewa Gasperowicz): zdecyduj co poprawić z pomocą narzędzi analitycznych, takich jak Lighthouse, ustal priorytety dla PWA (praktyczne porady, takie jak optymalizacja obrazów, korzystanie z pamięci podręcznej przeglądarki, dzielenie kodu i HTTPS), a następnie zaimplementuj i przeprowadź ponowną analizę
  • Fast by Default(Addy Osmani, Ilya Grigorik i Bryan McQuade): Swoją drogą, „fast by default” – bardzo fajne określenie, pewnie nie raz wykorzystam 🙂 Kolejna, ogromna lista materiałów do omówienia. Jest też zrzut ekranu, z dużą ilością dobrych porad, z których ŻADEN nie został omówiony szczegółowo. Szkoda, bo jest o czym mówić. Było sporo wywodów matematycznych prowadzących do „150kb budżetu wielkości javascriptu”. Później, losowo, Ilya i Bryan ogłosili Chrome User Experience Report. Wrócił Addy, gdzie mówił ofont-display: optionalnavigator.connection.effectiveTypelink rel=preload. Addy zakończył przemówienie case’ami na temat PWA Pinteresta i Tindera, ta prezentacja, podobnie jak wszystkie inne, dotyczyła wszystkiego, czyli w zasadzie nie dotyczyła niczego.

Best practices for loading

  • WordPress + PWA(Surma i Dan Walmsley): Surma(tak, jedno słowo jako imię i nazwisko :D) pokazał prototyp PWA zbudowanego na WordPressie. Dan z Automattic powiedział także, że JetPack wstępnie zaczął wspierać już PWA.
  • Stopniowe ulepszanie E-Commerce(Sam Dutton i Rowan Merewood): O wiele bardziej spójna rozmowa, pełna praktycznych porad. Z ciekawszych porad: pierw pokazuj najważniejszą treść(kluczowe zdjęcie produktu, nie pasek menu), utrzymuj jeden poziom wagi strony(deklaruj rozmiary obrazów), optymalizuj obrazy, używaj Intersection Observer do przewijania listingów, używaj obrazów zastępczych, np. image-trace-loader. Używaj linku rel = prefetch do ładowania predykcyjnego. Wyszukiwanie po stronie klienta offline możesz rozwiązać za pomocą Luny. Oznaczaj swoje formularze, aby zostały automatycznie wypełnione.
  • Silnik Javascript V8 dziś i w przyszłości(Thomas Nattestad): V8’ka stała się jeszcze szybsza🎉. Ponadto nowe funkcje ES6 i ES2016 są w pełni obsługiwane z maksymalną wydajnością, dlatego warto skorzystać z babel-preset-env, aby móc automatycznie korzystać z nowoczesnych funkcji JS w najnowszej wersji Chrome.

Z ciekawszych rzeczy to by było na tyle. Pozwoliłem sobie pominąć mało ciekawe rzeczy wraz z panelem Q&A.

O autorze

Filip Nowacki

Swoją przygodę z IT rozpocząłem mając 13 lat, kiedy to stworzyłem swoją pierwszą stronę internetową. Pracowałem jako backend & mobile developer, rozwijając kilka ogólnopolskich produktów o zasięgu blisko 15 milionów użytkowników. Obecnie pracuję w #fintech dla największych banków w Polsce. Prywatnie jestem maniakiem optymalizacji, testów A/B, motoryzacji i architektury aplikacji.

1 komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.