Nazywam się Paul Kinlan i prowadzę zespół ds. relacji z deweloperami w Chrome. W ramach moich obowiązków współpracuję z zespołem pasjonatów, którzy zajmują się przedstawianiem perspektywy programistów naszym zespołom ds. usług i inżynierów. Naszym celem jest zwiększenie zadowolenia programistów.
Zdajemy sobie sprawę, że „zadowolenie” to ambitny i subiektywny wskaźnik do śledzenia i ulepszania, dlatego stale zastanawiamy się, jak możemy mieć wpływ na potrzeby deweloperów. Naszą zasadą jest spotkanie się z twórcami tam, gdzie są. Niedawne badania przeprowadzone przez Stack Overflow wykazały, że 75% programistów korzysta z ramek lub jakiegoś rodzaju abstrakcji. Zastanawialiśmy się więc, jak najlepiej służyć deweloperom, którzy już podjęli decyzje dotyczące ich pakietu technologicznego lub nie mają nad nim kontroli. Jak zwiększyć ich produktywność bez zwiększania kosztów?
Mały zespół w Chrome pracował nad projektem o nazwie Aurora, którego celem było korzystanie z abstrakcji innych firm na platformie internetowej, takich jak frameworki i biblioteki. Ich celem jest bezpośrednie zwiększanie skuteczności tych abstrakcji, zamiast przerzucania tego obowiązku na klientów, czyli programistów stron internetowych.
W trzeciej edycji cyklu Chrome Dev Insider rozmawiałem z Addy Osmani, Karą Erickson i Housseinem Djirdeh z zespołu Project Aurora, aby dowiedzieć się więcej o tym, jak podchodzili do tego projektu i co ich czeka w przyszłości.
Wskazówki: praca z ramami innych firm
Zacznijmy od początków tego projektu. Jak to się zaczęło?
Addy: Aurora zaczęła od prostego pomysłu: „Spotkajmy się z deweloperami tam, gdzie są, i pomóżmy im dotrzeć do miejsca, do którego chcą dojść”. Na przykład możemy pomóc w ulepszeniu wydajności popularnego zestawu technologicznego, który wybrali. Obecnie wielu deweloperów aplikacji korzysta z React, Vue lub Angular albo z metaramek* takich jak Next.js i Nuxt (oraz oczywiście z wielu innych... Svelte, Lit, Preact, Astro. Lista jest długa). Zamiast wymagać od programistów, aby stali się ekspertami (np. w zakresie wydajności), możemy zapewnić im sukces, dodając do tych pakietów więcej sprawdzonych metod. Dzięki temu tworzenie witryn z myślą o internecie będzie miało pozytywny wpływ na jakość stron.
Aurora wybiera kilka popularnych frameworków i meta-frameworków, z którymi nawiązuje współpracę. Dokumentujemy nasze wnioski (np. jak tworzyć dobre komponenty obrazów), aby inni mogli szybko stosować się do naszych wskazówek i próbować skalować inne frameworky i narzędzia za pomocą Funduszu Frameworków Chrome. Jakość przeglądania stron internetowych można poprawić za pomocą przeglądarki, ale w niektórych przypadkach można to też zrobić za pomocą frameworków. Mamy nadzieję, że pomoże nam to w osiągnięciu naszego celu, którym jest zapewnienie wszystkim wyższej jakości usług internetowych.
Kara: Aby to wyjaśnić, powiem, że chodzi o to, aby poprawić wydajność w internecie dzięki ulepszeniu środowiska programisty. Nie wystarczy publikować sprawdzonych metod dotyczących skuteczności, ponieważ często się zmieniają i firmom trudno jest nadążać za tymi zmianami. Mają oni swoje priorytety biznesowe, które są dla nich ważniejsze niż skuteczność.
Naszym zdaniem deweloperzy mają ograniczony czas na optymalizację wydajności, dlatego chcemy ułatwić im tworzenie wydajnych aplikacji. Współpraca z popularnymi frameworkami internetowymi pozwoli nam zapewnić deweloperom lepszy interfejs abstrakcji, który ułatwi im pracę dzięki komponentom wyższego poziomu i ostrzeżeniom dotyczącym zgodności. Każdy, kto korzysta z tych popularnych narzędzi, będzie mógł korzystać z tych korzyści. Teoretycznie, jeśli zalecane porady ulegną zmianie, możemy zaktualizować nasze komponenty, a deweloperzy nie będą musieli się martwić o to, aby być na bieżąco.
Houssein: Dołączyłem do Google jako specjalista ds. deweloperów, a kilka lat później przeszedłem do zespołu inżynierów oprogramowania. Większość moich wcześniejszych działań polegała na uczeniu programistów stron internetowych różnych sposobów tworzenia wrażeń dla użytkowników. W zależności od sytuacji otrzymywali oni różne wersje tych samych wskazówek, aby ostrzec ich przed typowymi problemami, które mogą mieć wpływ na wydajność i użyteczność ich witryn. Gdy zaczęliśmy myśleć o projekcie Aurora, zapytaliśmy się: czy możemy pójść w kierunku, w którym nigdy nie będziemy musieli mówić deweloperom, co mają robić, ponieważ ich zestaw narzędzi zadba o wszystko za nich?
Jeśli dobrze rozumiem, to jest Was 6 inżynierów? Pewnie nie możesz pracować ze wszystkimi możliwymi frameworkami ani bibliotekami. Jak więc wybrać osoby, z którymi chcesz współpracować? I kim są?
Addy: Internet jest w wielu aspektach jak Dzikie Zachody. Możesz wybrać dowolną platformę, pakiet, bibliotekę i usługę zewnętrzną. Wprowadza to kilka poziomów złożoności, które mogą mieć wpływ na dobrą lub złą skuteczność. Jednym z najlepszych sposobów na poprawę skuteczności jest znalezienie warstw, które chętnie wyrażają swoje opinie i dodają je do treści.
Na przykład frameworki internetowe (Next.js, Nuxt.js i w pewnym stopniu Angular) starają się uwzględniać więcej opinii i wartości domyślnych niż rozwiązania ręcznie tworzone. To jeden z powodów, dla których chętnie z nimi współpracujemy. W przypadku tych modeli warto ustawić domyślne lepsze wartości dla wczytywania obrazów, czcionek i skryptów, aby poprawić wyniki podstawowych wskaźników internetowych.
Jest to też dobry sposób na sprawdzenie, czy sprawdzone metody są skuteczne lub czy należy je zmienić, a także na przekazanie całej społeczności informacji o tym, jak rozwiązywać problemy związane z optymalizacją.
Kara: musimy też wziąć pod uwagę popularność. Jeśli chcemy mieć jak największy wpływ na internet, najlepiej jest pracować z ramami i bibliotekami, które mają dużą społeczność programistów. Dzięki temu możemy dotrzeć do większej liczby deweloperów i aplikacji. Nie może to być tylko popularność. Ostatecznie jest to połączenie popularności, opinii na temat biblioteki i dostępnego zestawu funkcji, z którym możemy pracować.
Jeśli weźmiemy pod uwagę tylko popularność, „wielką trójką” stanowią React, Vue i Angular. Najczęściej używamy Next.js, Nuxt i Angular. Dzieje się tak, ponieważ biblioteki widoku, takie jak React i Vue, skupiają się głównie na renderowaniu, więc niemożliwe jest bezpośrednie tworzenie w nich wszystkich funkcji. Dlatego ściślej współpracujemy z metaramami opartymi na tych platformach: Next.js i Nuxt. Na tym poziomie abstrakcji możemy tworzyć wbudowane komponenty. Mają też wbudowane serwery, dzięki czemu możemy stosować optymalizacje po stronie serwera.
Angular znalazł się na liście głębokich partnerstw, ale nie jest meta-frameworkem. Angular jest w pewnym sensie szczególnym przypadkiem, ponieważ jest dość popularny, ale nie ma uzupełniającego meta-frameworku, tak jak React i Vue. Dlatego współpracujemy z nimi bezpośrednio i w miarę możliwości dodajemy funkcje za pomocą ich interfejsu wiersza poleceń.
Warto też wspomnieć, że współpracujemy z kilkoma innymi projektami, takimi jak Gatsby, w których przypadku regularnie synchronizujemy projekt, ale nie aktywnie nie przyczyniamy się do tworzenia kodu.
Jak to wygląda w praktyce? Jakie było Twoje podejście do rozwiązania tego problemu?
Kara: W praktyce mamy kilka frameworków, z którymi ściśle współpracujemy. Poświęcimy trochę czasu na sprofilowanie aplikacji za pomocą tego frameworku i znalezienie typowych problemów związanych ze skutecznością. Następnie współpracujemy z zespołem platformy, aby opracować eksperymentalne funkcje, które rozwiążą te problemy, i wprowadzić je do repozytorium OSS.
Bardzo ważne jest dla nas sprawdzenie, czy wpływ na wydajność jest zgodny z naszą prognozą, dlatego współpracujemy też z firmami zewnętrznymi, aby przeprowadzić testy wydajności w wersji produkcyjnej. Jeśli wyniki będą zachęcające, pomożemy tej funkcji osiągnąć „stabilność” i możliwe, że stanie się ona domyślną.
To nie jest takie proste, jak się wydaje. Jakie wyzwania stanęły Ci na drodze do tej pory?
Houssein: Jedną z ważniejszych rzeczy, które staramy się robić jak najlepiej, jest przyczynianie się do popularnych repozytoriów open source, które mają wiele konkurencyjnych priorytetów. To, że jesteśmy zespołem Google, nie oznacza, że nasze funkcje będą miały priorytet. Staramy się jak najlepiej dostosować się do typowego procesu zgłaszania i wdrażania nowych funkcji bez narażania się na zarzuty. Mieliśmy szczęście współpracować z otwartymi na nowości deweloperami w ekosystemach Next.js, Nuxt i Angular. Jesteśmy wdzięczni, że firma ta wysłuchała naszych obaw dotyczących ekosystemu internetowego i jest gotowa współpracować z nami na wiele sposobów.
W przypadku wielu frameworków, z którymi pracujemy, nasza ogólna misja jest taka sama: jak zapewnić deweloperom lepsze wrażenia użytkowników i jak zapewnić im wygodę? Zdajemy sobie sprawę, że w społeczności są setki, jeśli nie tysiące, osób, które przyczyniają się do rozwoju i utrzymania frameworków i pracują nad różnymi projektami, które się nawzajem przenikają.
Kara: Ponieważ zależy nam na weryfikacji wpływu na skuteczność i działaniu na podstawie danych, proces ten zajmuje trochę więcej czasu. Jesteśmy na nieznanym terytorium, więc czasami eksperymentujemy z optymalizacją, która nie przynosi oczekiwanych rezultatów, i nie kończymy tworzenia zaplanowanej funkcji. Nawet jeśli dana funkcja się sprawdzi, dodatkowe czynności związane z weryfikacją jej skuteczności wymagają czasu i wydłużają harmonogram.
Znajdowanie partnerów produkcyjnych do testowania naszych funkcji może być też trudne. Jak już wspomnieliśmy, są to firmy, które mają swoje priorytety, więc mogą mieć problemy z wdrożeniem nowych inicjatyw, jeśli nie są one dobrze dopasowane do istniejących projektów, które muszą być realizowane w pierwszej kolejności. Poza tym firmy, które są najbardziej zainteresowane pomocą, zwykle już inwestują w efektywność, więc nie są właściwie naszą grupą docelową. Staramy się zbierać opinie od dużej części społeczności, która nie może inwestować w wydajność, ale jest najmniej skłonna do kontaktu z nami.
Na czym polegały optymalizacje, które do tej pory przeprowadzałeś/przeprowadzałaś?
Houssein: po przeanalizowaniu tysięcy aplikacji stwierdziliśmy, że największe problemy ze skutecznością są zwykle spowodowane nieprawidłowymi wzorcami w kodzie aplikacji, a nie samym frameworkiem. Na przykład przesyłanie niepotrzebnie dużych obrazów, zbyt późne wczytywanie niestandardowych czcionek, pobieranie zbyt dużej liczby żądań stron trzecich, które blokują główny wątek, oraz nieobsługa sposobu, w jaki treści asynchroniczne mogą powodować przesuwanie się innych elementów na stronie. Wszystkie te problemy mogą wystąpić niezależnie od tego, którego narzędzia używasz, więc pomyśleliśmy, że możemy wprowadzić domyślne optymalizacje, które dobrze sobie z nimi radzą, ale z dodatkiem wygodnej funkcji dla programistów, która dobrze pasuje do ich narzędzia.
W związku z tym wprowadziliśmy:
- Komponent obrazu Next.js.
- Komponent skryptu Next.js.
- Automatyczne wstawianie czcionek w procesie kompilacji Next.js.
- Dyrektywa dotycząca obrazów w Angularze.
- wtyczka ESLint do weryfikacji zgodności Next.js, która zawiera praktyczne wskazówki dla programistów;
Nasze działania zainspirowały inne ramy i narzędzia do wdrażania podobnych optymalizacji. Nie zezwalamy m.in. na:
- Moduł obrazu Nuxt
- Zastąpienia danych o czcionkach w Nuxt
- Komponent skryptu Nuxt (w trakcie tworzenia)
- Komponent Gatsby Script
Czy możesz podzielić się pozytywnymi wynikami swojej pracy z niektórymi z tych graczy?
Houssein: dzięki optymalizacji, którą wprowadziliśmy, wiele witryn odnotowało poprawę wydajności. Jednym z moich ulubionych przykładów jest Leboncoin, który obniżył wartość LCP z 2,4 s na 1,7 s po przejściu na komponent obrazu Next.js. Wiele innych funkcji jest obecnie w fazie eksperymentowania i testowania, a my będziemy nadal dzielić się wnioskami i doświadczeniami z tych działań tutaj.
Rozumiem, że skupiasz się na tych, które są najbardziej popularne, ale czy i inne frameworki lub biblioteki, z którymi nie pracujesz aktywnie, mogą też na tym skorzystać?
Addy: wiele optymalizacji wydajności, nad którymi pracuje Aurora, można powielać w dowolnej platformie. Weź pod uwagę na przykład nasze komponenty Obraz lub Skrypt, które często kodują istniejący zestaw sprawdzonych metod. Staramy się udokumentować, jak tworzyć takie komponenty i jak wyglądają w każdej platformie. Mamy nadzieję, że to dobry początek do skopiowania pomysłu.
Odnieśliśmy sukcesy, wykorzystując wiedzę z jednego ekosystemu (np. React i Next.js) w innych. Na przykład nowa dyrektywa obrazów w Angularze (opracowana na podstawie naszych doświadczeń z tworzenia komponentu obrazu w Next.js) czy Gatsby wprowadzający nasze podejście do szczegółowego dzielenia kodu JavaScript na fragmenty.
Jednocześnie zdajemy sobie sprawę, że nie każda platforma ma odpowiednią przepustowość i finansowanie, aby umożliwić twórcom tworzenie podobnych funkcji związanych z wydajnością lub inwestowanie w inne optymalizacje, które ich zdaniem są ważne dla użytkowników. Fundusz na rzecz platform internetowych Chrome to nasz sposób na sponsorowanie prac nad wydajnością w ekosystemie JavaScriptu, aby umożliwić projektom wypłacanie wynagrodzenia ich współtwórcom i dalsze zwiększanie wydajności w ekosystemie.
Jakie plany ma Twój zespół?
Kara: mamy w planach wiele ciekawych projektów. Najważniejsze zmiany:
- Zmniejszanie CLS związanego z czcionką: przesunięcia układu są dość częste, gdy wczytuje się czcionka internetowa i zastępuje czcionkę zastępczą. Testujemy zastępowanie danych dotyczących czcionki i właściwość „size-adjust”, aby domyślnie zmniejszyć CLS związany z czcionką w Next.js. Współpracowaliśmy też z zespołem Nuxt i planujemy w przyszłości udostępnić tę funkcję w większej liczbie frameworków.
- Debugowanie INP: po udostępnieniu danych Interakcja do kolejnego wyrenderowania (INP) pracujemy nad frameworkami, aby zbadać najczęstsze przyczyny problemów z INP w społecznościach i zaproponować rozwiązania. Współpracujemy w tej sprawie z zespołem Angular i mamy nadzieję, że wkrótce będziemy mogli przedstawić pierwsze wyniki.
- Optymalizacja popularnych skryptów zewnętrznych: wczytywanie skryptów zewnętrznych w niewłaściwym momencie może mieć znaczny negatywny wpływ na wydajność. Ponieważ istnieje kilka bardzo popularnych bibliotek innych firm, sprawdzamy, czy możemy zaoferować dla nich obudowy, aby zapewnić ich optymalne wczytywanie z wykorzystaniem ram i uniknięcie blokowania wątku głównego. Jako punkt wyjścia do zbadania tego problemu używamy stworzonego przez nas komponentu skryptu Next.js.
Deweloperzy mogą śledzić nasze postępy na tej stronie.
O tym się mówi
Zanim się pożegnam, chciałbym przekazać kilka ciekawych informacji o ramówkach, które są obecnie opracowywane w Google.
W lipcu zespół Chrome ogłosił najnowszą rundę finansowania w wysokości 500 tys. USD na potrzeby funduszu na ramy i narzędzia, który skupia się na finansowaniu projektów mających na celu poprawę wydajności, wygody użytkowników i wygody programistów w internecie. Przyszłe finansowanie będzie uwzględniać nowe projekty, więc pamiętaj, aby przesłać prośbę.
Oczywiście w społeczności dzieje się też mnóstwo innych ciekawych rzeczy. Ekosystem jest pełen nowych frameworków, takich jak Fresh od Deno, oraz świetnych narzędzi, takich jak samouczek wprowadzający od Svelte, który nie tylko zawiera demo w przeglądarce, ale także używa interfejsu Web Container API do uruchamiania Node.js natywnie w przeglądarce. Tyle świetnych rzeczy!
Cieszę się, że ekosystem się rozwija, przesuwa granice możliwości przeglądarki i pomaga deweloperom tworzyć produkty, które działają dla wszystkich. To ekscytujący czas dla programistów stron internetowych.
Do zobaczenia w następnej edycji Insider.
Jak oceniasz ten numer The Chrome Dev Insider? Prześlij opinię.