Nazywam się Paul Kinlan i jestem deweloperem Chrome. W ramach mojej pracy pracuję z zespołem pasjonatów internetu, których zadaniem jest przybliżenie zespołom produktowym i inżynierom perspektywy prawdziwych programistów, a także wskaźnik „gwiazdki północnej” w celu zwiększenia zadowolenia programistów.
Zdajemy sobie sprawę, że „satysfakcja” to ambitny i subiektywny wskaźnik, który trzeba monitorować i ulepszać. Dlatego stale powtarzamy te działania, koncentrując się na potrzebach deweloperów. Wiodącą zasadą, którą stwierdziliśmy, jest „spotykaj deweloperów tam, gdzie się znajdują”. Niedawne badanie Stack Overflow wykazało, że 75% deweloperów pisze o korzystaniu ze platform lub z jakiegoś rodzaju abstrakcji. Zastanawiamy się, jak najlepiej służyć deweloperom, którzy już podejmowali decyzje dotyczące ich stosu technologicznego lub nie mają nad nim żadnej kontroli. Jak możemy zwiększyć ich produktywność bez zwiększania nakładów pracy?
Niewielki zespół z Chrome pracuje nad projektem o nazwie Aurora, którego celem jest współpraca z zewnętrznymi abstrakcjami platformy internetowej, takimi jak platformy i biblioteki. Celem firmy jest przełożenie wzrostu skuteczności bezpośrednio na te abstrakcje, zamiast na klientów, czyli programistów stron internetowych.
Przy okazji trzeciej edycji newslettera Chrome Dev Insider rozmawiałam z twórcami Addy Osmani, Kary Erickson i Houssein Djirdeh z zespołu Project Aurora, aby dowiedzieć się więcej o tym, jak podchodzą do tego projektu i co czeka przed nimi.
Informacja od wtajemniczonych: praca z platformami zewnętrznymi
Zacznijmy od genezy tego projektu. Jak do tego doszło?
Addy: Na początku Aurora miała prosty pomysł: spotkajmy się z programistami tam, gdzie się znajdują, i pomóżmy im osiągnąć zamierzone cele. Na przykład możesz pomóc popularnemu stosie technologicznym, który chce zwiększyć wydajność. Obecnie wielu deweloperów aplikacji tworzy aplikacje za pomocą React, Vue czy Angular – lub metastruktur*, takich jak Next.js czy Nuxt, (i oczywiście wielu innych... Svelte, Lit, Preact, Astro. Lista dłuższa). Zamiast oczekiwać, że ci deweloperzy staną się specjalistami (np. w zakresie wydajności), możemy zapewnić im sukces, domyślnie stosując w tych pakietach więcej sprawdzonych metod. W ten sposób witryny o lepszej jakości są tylko efektem ubocznym tworzenia witryn internetowych.
Aurora wybiera kilka powszechnie używanych platform i metastruktur, z którymi współpracuje. Dokumentujemy nasze wnioski (np. jak utworzyć dobry komponent obrazu), aby inni użytkownicy mogli szybko korzystać z innych platform i narzędzi w ramach Funduszu Chrome Frameworks. Choć można poprawić jakość korzystania z internetu za pomocą przeglądarki, sądzimy, że ten cel można też (w niektórych przypadkach) osiągnąć również za pomocą platform. Mamy nadzieję, że pomoże nam to w realizacji celów związanych z poprawą jakości internetu dla wszystkich użytkowników.
Kara: Chodzi o poprawę wydajności stron internetowych przez zwiększenie wygody programistów. Nie wystarczy nagłośnić sprawdzonych metod, ponieważ często się zmieniają, a firmom trudno za nimi nadążyć. Mają własne priorytety biznesowe, które prawdopodobnie będą mieć wyższy priorytet niż skuteczność.
Zastanawiamy się więc, czy deweloperzy mają mało czasu na dbanie o wydajność. Chcemy, aby mogli łatwiej (i szybciej) tworzyć wydajne aplikacje. Jeśli współpracujemy z popularnymi platformami internetowymi, znajdujemy się w odpowiednim punkcie abstrakcji, aby poprawić komfort programistów dzięki komponentom wyższego poziomu, ostrzeżeniam o zgodności itp. Każdy, kto korzysta z tych popularnych narzędzi, będzie miał dostęp do tych korzyści. Teoretycznie, jeśli zalecane porady się zmienią, będziemy mogli aktualizować nasze komponenty, a deweloperzy nie muszą zaprzątać sobie głowy tym, aby być na bieżąco.
Houssein: Kilka lat później dołączyłem do Google jako przedstawiciel ds. rozwoju oprogramowania. Wiele mojej wcześniejszej pracy dotyczyło nauczania programistów stron internetowych na wiele różnych sposobów zapewniania użytkownikom doskonałych wrażeń. Powtarzały się różne wskazówki, aby ostrzec deweloperów przed najczęstszymi problemami, które mogą mieć wpływ na wydajność i użyteczność ich witryn. Gdy zaczęliśmy myśleć o projekcie Aurora, zastanowiliśmy się, czy możemy podążać w kierunku, w którym nigdy nie będziemy musieli mówić programistom, co powinni zrobić, ponieważ ich łańcuch narzędzi zajmuje się wszystkim za nich.
Jeśli dobrze rozumiem, składa się z sześciu inżynierów zespół? Założę się, że nie da się pracować z każdą możliwą biblioteką lub platformą. Jak więc wybrać, z kim współpracować? Kim są?
Addy: internet jest pod wieloma względami podobny do Dzikiego Zachodu. Możesz wybrać dowolną platformę, narzędzie do tworzenia pakietów, biblioteki i rozwiązania innych firm. Powoduje to powstawanie kilku warstw złożoności, które mogą się przekładać na wysoką lub niską skuteczność. Jednym z najlepszych sposobów na szybkie zwiększenie skuteczności jest zachęcenie ich do wyrażania opinii i dodawanie do nich większej liczby opinii.
Na przykład platformy internetowe (Next.js, Nuxt.js i w pewnym stopniu Angular) dopuszczają się większej liczby opinii i ustawień domyślnych niż rozwiązania z własnej obsługi. To jeden z powodów, dla których uwielbiamy z nimi współpracować. W tych modelach warto mieć silniejsze ustawienia domyślne wczytywania obrazów, czcionek i skryptów, które poprawiają podstawowe wskaźniki internetowe.
Jest to również dobry sposób na sprawdzenie, czy nowoczesne sprawdzone metody sprawdzają się w danej sytuacji lub czy wymagają przemyśleń, a także może pomóc w pozyskaniu informacji dla całego ekosystemu o tym, jak rozwiązywać problemy z optymalizacją.
Kara: Realistycznie trzeba też brać pod uwagę popularność. Jeśli chcemy mieć jak największy wpływ na internet, idealnie możemy współpracować z platformami i bibliotekami, w których jest już duża społeczność deweloperów. W ten sposób możemy dotrzeć do większej liczby deweloperów i innych aplikacji. Nie może to być jednak tylko popularność. Ostatecznie jest to połączenie popularności, stopnia opinii biblioteki i dostępnego zestawu funkcji, z którym możemy pracować.
Jeśli weźmiemy pod uwagę np. samą popularność, React, Vue i Angular to „duża trójka”, którą trzeba wziąć pod uwagę. Najczęściej współpracujemy z Next.js, Nuxt i Angular. Dzieje się tak, ponieważ biblioteki widoku danych, takie jak React i Vue, skupiają się głównie na renderowaniu, więc nie można wbudować bezpośrednio w nie wszystkich interesujących nas funkcji. Dlatego współpracujemy z popularnymi metastrukturami, które są na ich podstawie: Next.js i Nuxt. Na tym poziomie abstrakcji możemy tworzyć wbudowane komponenty. Mają też wbudowane serwery, dzięki czemu możemy uwzględnić optymalizacje po stronie serwera.
Być może zauważycie, że Angular znalazł się na tej liście głębokich partnerstw, ale nie jest to schemat. Angular jest w pewnym momencie wyjątkowym tytułem, ponieważ cieszy się dość dużą popularnością, ale nie ma uzupełniającego się systemu graficznego, tak jak robią to React i Vue. Współpracujemy z nimi bezpośrednio i w miarę możliwości wprowadzamy nowe funkcje za pomocą interfejsu wiersza poleceń.
Warto zauważyć, że utrzymujemy kilka stałych relacji z innymi projektami, np. Gatsby, w ramach których regularnie przeprowadzamy synchronizację w trakcie projektowania, ale nie zajmujemy się aktywnie kodem.
Jak to wygląda w praktyce? Jakie było Twoje podejście do rozwiązania tego problemu?
Kara: W praktyce mamy kilka platform, z którymi ściśle współpracujemy. Poświęcimy trochę czasu na profilowanie aplikacji korzystających z tej platformy i znajdowanie typowych problemów z wydajnością. Następnie wraz z zespołem ds. platformy projektujemy eksperymentalne funkcje rozwiązujące te problemy i udostępniamy kod bezpośrednio w repozytorium OSS, aby je wdrożyć.
Naprawdę istotne jest dla nas sprawdzenie, czy wpływ na wydajność jest zgodny z prognozami, dlatego współpracujemy z firmami zewnętrznymi, aby przeprowadzać testy wydajności w środowisku produkcyjnym. Jeśli wyniki będą zachęcające, pomożemy tej funkcji uzyskać „stabilną” i w razie potrzeby ustawić ją jako domyślną.
To wszystko nie może być tak proste, jak się wydaje. Jakie były Wasze dotychczasowe wyzwania lub wnioski?
Houssein: chcemy jak najpełniej korzystać z możliwości, jakie zapewniamy w popularnych repozytoriach open source o wielu różnych priorytetach. To, że pracujemy w Google, nie oznacza, że priorytetowe funkcje będą priorytetowe. Dlatego staramy się postępować zgodnie z typowym procesem proponowania i udostępniania nowych funkcji bez konieczności podejmowania jakichkolwiek działań. Mieliśmy ogromne szczęście współpracować z osobami opiekującymi się obsługą w ekosystemach Next.js, Nuxt i Angular. Cieszymy się, że są otwarci na nasze obawy dotyczące ekosystemu internetowego i chcą współpracować z nami na wiele sposobów.
W przypadku wielu platform, z którymi pracujemy, nasza ogólna misja jest taka sama. Jak deweloperzy mogą od razu zadbać o wygodę użytkowników, a jednocześnie zapewnić im świetne wrażenia? Zdajemy sobie sprawę i szanujemy, że setki, a może nawet tysiące osób pracujących w społeczności i opiekunowie koncepcji, pracują nad różnymi projektami, które się ze sobą łączą.
Kara: Zależy nam na weryfikacji wpływu na skuteczność i podejmowaniu działań na podstawie danych, dlatego ten proces trwa trochę dłużej. Jesteśmy na niezbadanym obszarze, więc czasami eksperymentujemy z optymalizacją, która się nie sprawdza, i nie kończymy na tworzeniu zaplanowanej funkcji. Nawet jeśli dana funkcja jest już dostępna, wykonanie kilku dodatkowych kroków w celu sprawdzenia skuteczności wymaga czasu i wydłuża ramy czasowe.
Znalezienie partnerów w branży produkcyjnej do testowania naszych funkcji również może być trudne. Jak już wspomnieliśmy, są to firmy i ma własne priorytety, więc może być trudno dopasować je do nowych inicjatyw, które nie będą pasowały do istniejących projektów, które muszą zająć pierwsze miejsce. Poza tym firmy, które najbardziej są zainteresowane pomocą, zazwyczaj już teraz inwestują w zwiększanie skuteczności, więc nie są naszymi docelowymi odbiorcami. Staramy się zbierać opinie od dużej grupy użytkowników, którzy nie mogą zainwestować w skuteczność, ale są one najmniej prawdopodobne, że skontaktują się z nami.
Na jakich rodzajach optymalizacji się skupiasz?
Houssein: po przeanalizowaniu tysięcy aplikacji stwierdziliśmy, że największe problemy z wydajnością wynikają zwykle z antywzorców w kodzie aplikacji, a nie na samej platformie. Dotyczy to na przykład wysyłania niepotrzebnie dużych obrazów, zbyt późnego wczytywania czcionek niestandardowych, pobierania zbyt wielu żądań zewnętrznych, które blokują wątek główny, i braku obsługi tego, w jaki sposób asynchroniczna zawartość może powodować przesunięcie innych elementów na stronie. To wszystkie problemy, które mogą wystąpić niezależnie od używanego narzędzia. Pomyśleliśmy więc, czy możemy wprowadzić domyślne optymalizacje, które dobrze z nimi radzą, ale jednocześnie będą działać w sposób, który dobrze wpasowuje się w ich narzędzia.
W związku z tym wysłaliśmy:
- Komponent obrazu Next.js.
- Komponent skryptu Next.js.
- Automatyczne wstawianie czcionki w procesie kompilacji Next.js.
- Dyrektywa Angular dotycząca obrazu.
- Wtyczka Next.js ESLint pod kątem zgodności z przydatnymi wskazówkami dla deweloperów.
Nasza praca zainspirowała inne struktury i narzędzia do wprowadzenia podobnych optymalizacji. Nie zezwalamy m.in. na:
- Moduł obrazu Nuxt
- Nuxt zastąpienia danych czcionki
- Komponent skryptu Nuxt (w toku)
- Komponent skryptu Gatsby
Czy możesz podzielić się z nimi pozytywnymi efektami swojej pracy?
Houssein: dzięki wprowadzonym przez nas optymalizacjom skuteczność wielu witryn wzrosła. Jednym z moich ulubionych przykładów jest firma Leboncoin, która obniżyła LCP z 2,4 s do 1,7 s po przejściu na komponent obrazu Next.js. Obecnie jest ich znacznie więcej w fazach eksperymentów i testów. O wnioskach i wynikach będziemy informować tutaj.
Rozumiem, że skupiasz się na tych, które cieszą się największą popularnością, ale czy inne platformy lub biblioteki, z którymi nie współpracujesz, również mogą odnieść korzyści?
Addy: wiele optymalizacji wydajności, nad którymi współpracuje Aurora, można powielać w dowolnej platformie. Przyjrzyj się na przykład wysiłkom związanym z komponentami obrazu lub skryptu. Często kodują one istniejące zestawy sprawdzonych metod. Staramy się udokumentować proces tworzenia takich komponentów i ich wygląd w ramach każdej struktury. Mamy nadzieję, że to dobry początek do kopiowania pomysłu.
Zaobserwowaliśmy, że wnioski wyciągnięte z jednego ekosystemu (np. React i Next.js) trzeba wykorzystać w innych. Na przykład nowa dyrektywa w sprawie obrazu Angular (oparta na wnioskach z tworzenia komponentu obrazu Next.js) lub Gatsby dzieli się naszym podejściem do szczegółowego podziału kodu JavaScript.
Jednocześnie zdajemy sobie sprawę, że nie wszystkie platformy mają wystarczającą przepustowość lub środki finansowe, dzięki którym darczyńcy mogą tworzyć podobne funkcje zwiększające wydajność lub zainwestować w inne optymalizacje, które ich zdaniem są ważne dla użytkowników. Fundusz Chrome Web Frameworks Fund pozwala nam sponsorować prace nad wydajnością ekosystemu JavaScript, aby umożliwić projektom wynagrodzenie za ich wkład i zwiększyć wydajność ekosystemu.
Jakie ma plany na przyszłość dla Twojego zespołu?
Kara: Przed nami wiele ciekawych projektów. Najważniejsze zmiany:
- Zmniejszanie CLS związanej z czcionkami: po wczytaniu czcionki internetowej, która zastępuje czcionkę zastępczą, układ dość często się przesuwa. Badamy możliwość użycia zastąpień danych dotyczących czcionki i właściwości „size-customize” w celu domyślnego ograniczenia CLS związanego z czcionkami w Next.js. Skonsultowaliśmy się też z zespołem Nuxt w tej sprawie i zamierzamy w przyszłym roku uwzględnić ten pomysł w większej liczbie platform.
- Debugowanie INP: po udostępnieniu danych Interaction to Next Paint (INP) pracujemy z platformami, aby zbadać najczęstsze główne przyczyny problemów z INP w ich społecznościach i zaproponować ich rozwiązania. Współpracujemy w tej kwestii ściśle z firmą Angular i mamy nadzieję, że wkrótce przekażemy Ci jakieś wyniki.
- Optymalizacja popularnych skryptów innych firm: wczytywanie skryptów innych firm w niewłaściwym momencie może mieć znaczny negatywny wpływ na wydajność. Istnieje kilka bardzo popularnych dostawców zewnętrznych, dlatego szukamy możliwości udostępnienia ich kodów, aby upewnić się, że są one optymalnie wczytywane za pomocą platform i nie blokują wątku głównego. Podstawą tego badania jest utworzony przez nas komponent skryptu Next.js.
Deweloperzy mogą śledzić nasze postępy na tej stronie.
O tym się mówi
Na koniec chcę Ci przekazać kilka ciekawych informacji o platformach i platformach Google.
W lipcu zespół Chrome ogłosił ostatnią rundę finansowania w wysokości 500 tys. USD do funduszu Frameworks and Tools przeznaczona na finansowanie projektów mających na celu zwiększenie wydajności, wygody użytkowników i wrażeń programistów w internecie. Przyszłe finansowanie będzie obejmować nowe projekty, dlatego pamiętaj, by przesłać swoją prośbę.
No i oczywiście w społeczności dzieje się też dużo niezwykłych rzeczy. Ekosystem jest pełen nowych platform, takich jak Fresh firmy Deno, i niezwykłych funkcji, takich jak samouczek wprowadzający w aplikacji Svelte. Jest to nie tylko wersja demonstracyjna w przeglądarce, ale również interfejs Web Container API do natywnego uruchamiania środowiska Node.js w przeglądarce. Tyle dobrych rzeczy!
Z radością obserwuję, jak ekosystem opracowuje nowe możliwości w przeglądarce i pomaga deweloperom tworzyć usługi dla wszystkich. Dziś jest dobry czas dla programisty stron internetowych.
Aż do następnego dziennikarza – Hwylfawr.
Jak oceniasz to wydanie The Chrome Dev Insider? Prześlij opinię.