Chrome Dev Insider: повышение производительности с помощью экосистемы фреймворка

Пол Кинлан

Меня зовут Пол Кинлан , и я руковожу отделом по работе с разработчиками Chrome. В рамках своей работы я работаю с командой увлеченных сторонников веб-технологий, которым поручено донести точку зрения реальных разработчиков до наших команд по продуктам и инжинирингу, используя метрику «полярная звезда» для повышения удовлетворенности разработчиков .

Мы признаем, что «удовлетворение» — это амбициозная и субъективная метрика для отслеживания и улучшения, поэтому мы постоянно итерируемся в том, как мы можем оказать влияние, сосредоточившись на потребностях разработчиков . Руководящий принцип, которому мы сочли полезным следовать, — « встречайте разработчиков там, где они находятся ». Недавнее исследование Stack Overflow показало, что 75% разработчиков сообщают об использовании фреймворков или абстракций какого-либо рода. Поэтому мы задаемся вопросом, как нам лучше всего обслуживать разработчиков, которые уже приняли решения о своем технологическом стеке или не контролируют его? Как нам сделать их более производительными, не добавляя дополнительных накладных расходов?

Небольшая команда здесь, в Chrome, работает над проектом под названием Aurora , с целью работы со сторонними абстракциями веб-платформы, такими как фреймворки и библиотеки. Их цель — помочь принести прирост производительности непосредственно в эти абстракции, вместо того, чтобы перекладывать бремя на своих клиентов — веб-разработчиков.

В третьем выпуске Chrome Dev Insider я поговорил с Эдди Османи , Карой Эриксон и Хуссейном Джирдехом из команды Project Aurora, чтобы узнать больше об их подходе к этому проекту и о том, что их ждет впереди.

Инсайдерская информация: работа со сторонними фреймворками

Давайте начнем с зарождения этого проекта. Как он появился?

Эдди: Aurora начала с простой идеи: давайте встречаться с разработчиками там, где они находятся, и помогать им достигать того, чего им нужно. Например, помогать популярному технологическому стеку, который они выбрали, повышать производительность. Многие разработчики приложений в наши дни создают приложения с использованием React, Vue или Angular — или мета-фреймворков*, таких как Next.js и Nuxt — (и, конечно, многих других... Svelte, Lit, Preact, Astro. Список можно продолжать!). Вместо того чтобы ожидать, что эти разработчики станут глубокими экспертами (например, в производительности), мы могли бы гарантировать, что они попадут в яму успеха, включив больше передовых практик по умолчанию в эти стеки. Таким образом, более качественные сайты являются побочным эффектом простого создания для Интернета.

Aurora выбирает несколько широко используемых фреймворков и метафреймворков для сотрудничества, мы документируем наши знания (например, как создать хороший компонент изображения), чтобы другие могли быстро последовать нашему примеру и попытаться масштабироваться с помощью других фреймворков и инструментов через Chrome Frameworks Fund. Хотя можно улучшить качество веб-опыта через браузер, мы считаем, что эта цель также может (в некоторых случаях) быть достигнута с помощью фреймворков. Мы надеемся, что это поможет нам в достижении наших целей более качественного веба для всех.

Кара: Если говорить шире, идея заключается в том, чтобы улучшить производительность в сети, улучшив опыт разработчиков. Недостаточно просто публиковать лучшие практики производительности, потому что они часто меняются, и компаниям сложно за ними поспевать. У них есть свои собственные бизнес-приоритеты, которые, скорее всего, будут важнее производительности.

Поэтому мы думаем, что если у разработчиков ограниченное время на производительность, давайте упростим (и ускорим) для них создание производительного приложения. Если мы сотрудничаем с популярными веб-фреймворками, мы находимся на правильном уровне абстракции для улучшения опыта разработчика с помощью компонентов более высокого уровня, предупреждений о соответствии и т. д. Любой, кто использует эти популярные инструменты, получит доступ к этим преимуществам. И теоретически, если рекомендуемые советы изменятся, мы сможем обновить наши компоненты под капотом, и разработчикам не придется беспокоиться о том, чтобы оставаться в курсе событий.

Хуссейн: Я присоединился к Google в качестве Developer Advocate, а затем несколько лет спустя перешел на должность инженера-программиста. Большая часть моей предыдущей работы заключалась в обучении веб-разработчиков различным способам создания отличного пользовательского опыта. Раз за разом предоставлялись вариации одного и того же руководства, чтобы предупредить разработчиков о распространенных проблемах, которые, скорее всего, повлияют на производительность и удобство использования их сайтов. Когда мы начали думать о проекте Aurora, мы спросили себя: можем ли мы двигаться в направлении, где нам никогда не придется говорить разработчикам, что делать, потому что их инструментарий позаботится обо всем за них?

Если я правильно понял, вы команда из кого, из шести инженеров? Держу пари, вы не можете работать со всеми возможными фреймворками или библиотеками. Так как же вы выбираете, с кем работать? И кто они?

Эдди: Во многих отношениях Интернет похож на Дикий Запад. Вы можете выбрать практически любой фреймворк, сборщик, библиотеки и сторонние организации, которые захотите. Это вводит несколько уровней сложности, которые могут способствовать хорошей или плохой производительности. Один из лучших способов сдвинуть иглу производительности — найти эти уровни удобными для самоуверенности и добавить к ним больше мнений.

Например, веб-фреймворки (Next.js, Nuxt.js и в некоторой степени Angular) пытаются запечь больше мнений и значений по умолчанию, чем более вручную скроенное решение. Это одна из причин, по которой мы любим работать с ними! Наличие более сильных значений по умолчанию для загрузки изображений, шрифтов и скриптов для улучшения Core Web Vitals имеет смысл в этих моделях.

Это также служит хорошим способом подтвердить, где современные передовые методы работают, а где, возможно, необходимо переосмыслить, и может помочь информировать всю экосистему о том, как подходить к решению задач оптимизации.

Кара: Реалистично, мы также должны учитывать популярность. Если мы хотим иметь максимально возможное влияние на веб, работа с фреймворками и библиотеками, которые имеют большое существующее сообщество разработчиков, является идеальным вариантом. Таким образом мы можем охватить больше разработчиков и больше приложений. Но это не может быть просто популярность. В конечном счете, это пересечение популярности, того, насколько самоуверенна библиотека, и доступного набора функций, с которым мы можем работать.

Например, если рассматривать только популярность, React, Vue и Angular — это «большая тройка», которую следует учитывать. Но мы больше всего работаем с Next.js, Nuxt и Angular. Это связано с тем, что библиотеки представлений, такие как React и Vue, в основном сосредоточены на рендеринге, поэтому невозможно напрямую встроить в них все нужные нам функции. Поэтому мы более тесно работаем с самоуверенными метафреймворками, построенными поверх них: Next.js и Nuxt. На этом уровне абстракции мы можем создавать встроенные компоненты. У них также есть встроенные серверы, поэтому мы можем включать оптимизации на стороне сервера.

Вы могли заметить, что Angular был в этом списке глубоких партнерств, но это не метафреймворк. Angular — это своего рода особый случай, потому что он довольно популярен, но не имеет дополнительного метафреймворка, как React и Vue. Поэтому мы работаем с ними напрямую и вносим функции через их CLI, где это возможно.

И стоит отметить, что у нас есть несколько постоянных отношений с другими проектами, такими как Gatsby, где мы довольно регулярно синхронизируемся по дизайну, но не активно вносим свой вклад в код.

Так как же это выглядит на практике? Какой был ваш подход к решению этой проблемы?

Кара: На практике у нас есть несколько фреймворков, с которыми мы тесно сотрудничаем. Мы тратим некоторое время на профилирование приложений, использующих этот фреймворк, и выясняем общие проблемы производительности. Затем мы работаем с командой фреймворка над разработкой экспериментальных функций для устранения этих проблем и вносим код непосредственно в репозиторий OSS для их реализации.

Для нас очень важно подтвердить, что влияние на производительность соответствует нашим прогнозам, поэтому мы также работаем с внешними компаниями для проведения тестирования производительности в производстве. Если результаты будут обнадеживающими, мы поможем функции стать «стабильной» и, возможно, сделаем ее функцией по умолчанию.

Все это не может быть так просто, как вы говорите. С какими трудностями или уроками вы столкнулись до сих пор?

Хуссейн: Одна важная вещь, которую мы пытаемся сделать в меру своих возможностей, — это внесение вклада в популярные репозитории с открытым исходным кодом, у которых много конкурирующих приоритетов. То, что мы команда Google, не обязательно означает, что наши функции будут приоритетными, поэтому мы стараемся изо всех сил соответствовать типичному процессу предложения и поставки новых функций, не наступая никому на пятки. Нам очень повезло работать с восприимчивыми сопровождающими в экосистемах Next.js, Nuxt и Angular. Мы благодарны за то, что они были открыты для того, чтобы выслушать наши опасения по поводу веб-экосистемы и готовы сотрудничать с нами более чем одним способом.

Со многими фреймворками, с которыми мы работаем, наша общая миссия та же самая: как разработчики могут получить улучшенный пользовательский опыт из коробки, одновременно наслаждаясь отличным опытом разработчика? Мы знаем и уважаем, что есть сотни, если не тысячи, участников сообщества и сопровождающих фреймворков, каждый из которых работает над различными проектами, которые пересекаются друг с другом.

Кара: Кроме того, поскольку мы заботимся о проверке влияния на производительность и действуем на основе данных, процесс занимает немного больше времени. Мы находимся на неизведанной территории, поэтому иногда мы экспериментируем с оптимизацией, которая не срабатывает, и мы не создаем запланированную функцию. Даже когда функция срабатывает, эти несколько дополнительных шагов для проверки производительности требуют времени и увеличивают сроки.

Поиск партнеров по производству для тестирования наших функций также может быть сложным. Как уже упоминалось, это предприятия и у них есть свои собственные приоритеты, поэтому им может быть сложно вписаться в новые инициативы, если они не соответствуют существующим проектам, которые должны быть в первую очередь. Кроме того, компании, наиболее заинтересованные в помощи, как правило, уже тратят время на инвестиции в производительность, поэтому они не являются нашей целевой аудиторией. Мы пытаемся собрать отзывы от большой части сообщества, которая не может инвестировать в производительность, но они вряд ли обратятся к нам.

Продолжая, на каких видах оптимизации вы сосредоточились?

Хуссейн: Проанализировав тысячи приложений, мы обнаружили, что самые большие проблемы с производительностью обычно возникают из-за антишаблонов в коде приложения, а не из-за самой структуры. Например, отправка неоправданно больших изображений, слишком поздняя загрузка пользовательских шрифтов, получение слишком большого количества сторонних запросов, которые блокируют основной поток, и отсутствие обработки того, как асинхронный контент может привести к смещению других вещей на странице. Все эти проблемы могут возникнуть независимо от того, какой инструмент вы используете, поэтому мы подумали — можем ли мы встроить некоторые оптимизации по умолчанию, которые хорошо справляются с ними, но с аккуратным интерфейсом разработчика, который хорошо вписывается в их инструментарий структуры?

Исходя из этого, мы выпустили:

Наша работа вдохновила другие фреймворки и инструменты для реализации подобных оптимизаций. Это включает в себя, но не ограничивается:

Можете ли вы поделиться положительными результатами вашей работы с некоторыми из этих игроков?

Хуссейн: Многие сайты увидели улучшения производительности благодаря оптимизации, которую мы отправили. Один из моих любимых примеров — Leboncoin , который сократил свой LCP с 2,4 до 1,7 с после перехода на компонент изображения Next.js. В настоящее время еще много таких сайтов находятся на этапах экспериментов и тестирования, и мы продолжим делиться здесь полученными знаниями и победами.

Хорошо, я понимаю, что вы сосредоточены на тех, которые пользуются наибольшей популярностью, но есть ли способы, которыми другие фреймворки или библиотеки, с которыми вы не работаете активно, также могут получить выгоду?

Эдди: Многие из оптимизаций производительности, над которыми сотрудничает Aurora, могут быть воспроизведены любым фреймворком. Взгляните на наши усилия по компонентам Image или Script, например, они часто кодифицируют существующий набор лучших практик. Мы стараемся документировать «как» создавать такие компоненты и как они выглядят в каждом фреймворке. Надеюсь, это хорошее начало для копирования идеи.

Мы увидели некоторые хорошие успехи в извлечении знаний из одной экосистемы (например, React и Next.js) и переносе их в другие. Например, новая директива Angular Image (основанная на наших знаниях, создающих компонент изображения Next.js) или Gatsby, отправляющий наш подход к гранулярному фрагментированию JavaScript.

В то же время мы понимаем, что не у каждого фреймворка будет пропускная способность или финансирование для участников, чтобы создавать аналогичные функции производительности или инвестировать в другие оптимизации, которые они считают важными для своих пользователей. Фонд Chrome Web Frameworks — это способ для нас спонсировать работу по производительности в экосистеме JavaScript, чтобы позволить проектам платить своим участникам и позволить работе по производительности масштабироваться дальше в экосистеме.

Какие планы у вашей команды на будущее?

Кара: У нас впереди много интересных проектов! Некоторые основные моменты:

  • Уменьшение CLS, связанного со шрифтом: довольно часто можно увидеть сдвиги макета, когда веб-шрифт загружается и заменяет резервный шрифт. Мы изучаем использование переопределений метрик шрифта и свойства "size-adjust" для уменьшения CLS, связанного со шрифтом, по умолчанию в Next.js. Мы также консультировались с командой Nuxt по этому вопросу и планируем распространить эту идею на большее количество фреймворков в следующем году.
  • Отладка INP: Теперь, когда метрика Interaction to Next Paint (INP) была выпущена, мы работаем с фреймворками, чтобы исследовать наиболее распространенные первопричины проблем INP для их сообществ и предлагать исправления. Мы тесно сотрудничаем с Angular в этом вопросе и надеемся вскоре получить некоторые результаты, которыми можно будет поделиться!
  • Оптимизация распространенных 3P-скриптов: загрузка сторонних скриптов в неподходящее время может оказать существенное негативное влияние на производительность. Поскольку есть несколько 3P, которые очень распространены, мы ищем, можем ли мы предложить некоторые оболочки для них, чтобы гарантировать, что они оптимально загружаются с помощью фреймворков и не блокируют основной поток. Мы используем компонент скрипта Next.js, который мы создали, в качестве отправной точки для этого исследования.

Разработчики могут следить за нашим прогрессом на этом сайте .

В новостях

Прежде чем закончить, я хотел бы поделиться с вами парой интересных новостей из мира фреймворков, которые происходят в Google.

В июле команда Chrome объявила о последнем раунде финансирования в размере $500 тыс. для фонда Frameworks and tools , который фокусируется на финансировании проектов, направленных на улучшение производительности, пользовательского опыта и опыта разработчиков в Интернете. Будущее финансирование будет учитывать новые проекты, поэтому не забудьте отправить свой запрос .

И, конечно, в сообществе происходит ТОННА удивительных вещей. Экосистема полна новых фреймворков, таких как Fresh от Deno, и потрясающих впечатлений, таких как обучающее руководство Svelte, которое не только является демонстрацией в браузере, но и использует API веб-контейнера для запуска Node.js в браузере. Так много всего хорошего!

Я искренне рад, что экосистема объединяется, продвигая возможности браузера и помогая разработчикам создавать продукты, которые подходят всем. Это захватывающее время для веб-разработчика.

До следующего инсайдера, Хвила Фаура.

Что вы думаете об этом выпуске The Chrome Dev Insider? Поделитесь своим отзывом .