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 szukamy sposobów na to, jak możemy mieć wpływ na potrzeby deweloperów. Naszą zasadą jest spotkanie się z twórcami tam, gdzie są. Niedawne badanie przeprowadzone przez Stack Overflow wykazało, ż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, a nie przerzucanie 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 deweloperzy. 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ść witryn.
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. Chociaż jakość przeglądania stron internetowych można poprawić za pomocą przeglądarki, uważamy, że w niektórych przypadkach można to też osiągnąć 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: Chodzi o to, aby poprawić wydajność w internecie, ułatwiając pracę programistom. Nie wystarczy opublikować sprawdzonych metod dotyczących skuteczności, ponieważ często się one zmieniają i trudno jest firmom nadążać za tymi zmianami. Mają oni swoje priorytety biznesowe, które są prawdopodobnie 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 związku z tym wielokrotnie wysyłaliśmy im różne wersje tych samych wskazówek, aby ostrzegać 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 podobny do Dzikiego Zachodu. 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 skuteczność kampanii. 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 platformy 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 tworzone ręcznie. 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, czy też trzeba je zmienić. Może też pomóc w informowaniu całego ekosystemu o sposobach rozwiązywania problemów 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ępnych funkcji, z którymi możemy pracować.
Jeśli weźmiemy pod uwagę tylko popularność, to React, Vue i Angular to „wielka trójka”, którą warto rozważyć. Najczęściej jednak korzystamy z 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, które chcemy uzyskać. 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ć optymalizację po stronie serwera.
Angular znajduje się na liście głębokich partnerstw, ale nie jest meta-frameworkem. Angular to nieco szczególny przypadek, ponieważ jest dość popularny, ale nie ma uzupełniającego meta-frameworku, tak jak React i Vue. Dlatego współpracujemy bezpośrednio z tymi frameworkami 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 projekty graficzne, 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 najczęstszych 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 problemy napotkałeś/napotkałaś do tej pory lub jakie wnioski wyciągnąłeś/wyciągnęłaś?
Houssein: staramy się jak najlepiej przyczyniać się do rozwoju 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 o naruszenie praw innych osób. Mieliśmy szczęście współpracować z otwartymi na nowości deweloperami z ekosystemów 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 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 w konsekwencji nie wdrażamy 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 brak obsługi treści asynchronicznych, które 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 łatwym w użyciu interfejsem dla programistów, który dobrze pasuje do ich narzędzia frameworkowego.
W związku z tym wprowadziliśmy:
- Komponent obrazu Next.js.
- Komponent skryptu Next.js.
- Automatyczne umieszczanie czcionek w kodze HTML w procesie kompilacji Next.js.
- Dyrektywa dotycząca obrazów w Angularze.
- wtyczka ESLint do sprawdzania 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 wprowadzonym przez nas optymalizacji 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 dotycząca obrazów w Angularze (opracowana na podstawie naszych doświadczeń z tworzenia komponentu obrazu w Next.js) czy Gatsby, który wdraża nasze podejście do szczegółowego dzielenia kodu JavaScript na części.
Jednocześnie zdajemy sobie sprawę, że nie każda platforma ma zasoby i środki, 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 potrzeby tworzenia frameworków internetowych w 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: czeka nas wiele ekscytujących 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 ramach większej liczby frameworków.
- Debugowanie INP: po udostępnieniu danych Interakcja do kolejnego wyrenderowania (INP) pracujemy nad frameworkami, aby zidentyfikować 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 były one optymalnie ładowane z ramami i nie blokowały głównego wątku. 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, chcę przekazać kilka ciekawych informacji ze świata frameworków 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 koncentruje 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 dotyczyć nowych projektów, 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 odsłonie Insider.
Jak oceniasz ten numer The Chrome Dev Insider? Prześlij opinię.