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

Пол Кинлан

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, если мы посмотрим только на популярность, 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, могут быть воспроизведены в любой платформе. Взгляните, например, на наши усилия по созданию компонентов изображения или сценария: они часто систематизируют существующий набор лучших практик. Мы пытаемся документировать, «как» создавать такие компоненты и как они выглядят в каждой структуре. Надеюсь, это хорошее начало для копирования идеи.

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

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

Итак, какие планы ждут вашу команду?

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

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

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

В новостях

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

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

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

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

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

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