(Перевод) Контрольный список по оптимизации производительности внешнего интерфейса на 2019 г. — часть 1

оптимизация производительности

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

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

Поскольку полный текст слишком длинный, чтобы публиковать все содержимое за один раз, его планируется разделить на три главы: верхнюю, среднюю и нижнюю. Первая часть включает (планировать и измерять,Ставьте реалистичные целииОпределить среду), средняя часть включает (Оптимизация ресурсов,Оптимизация сборкииОптимизация доставки), следующая часть включает (HTTP / 2,тестирование и мониторингиБыстрое решение).

Оригинальный адрес ссылки:Front-End Performance Checklist 2019
Оригинальный автор:Vitaly Friedman
Переводчик:велосипедист
Это ежегодная статья по оптимизации производительности внешнего интерфейса со всем, что вам нужно знать для создания быстрого интерфейса, ежегодно обновляемая с 2016 года.

Веб-производительность является серьезной проблемой в мире интерфейсов, поэтому еще важнее знать, где мы находимся с точки зрения производительности и каковы наши узкие места в производительности. Это дорогой JavaScript, медленная доставка веб-шрифтов или большие изображения, замедляющие загрузку страниц? Оптимизация веб-производительности включает в себя: Tree-shaking, поднятие Scope, разделение кода, наблюдатель Intersection, отправку сервера, клиентские подсказки (клиентские подсказки), HTTP/2, сервис-воркеры и т. д. Но самое главное, мы должныС чего начать улучшение производительности интерфейсаа такжеКак создать долгосрочный механизм оптимизации производительности интерфейса?

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

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

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

(Вы также можете просто скачатьPDF-версия контрольного списка оптимизации производительности внешнего интерфейса(166кб) илиЗагрузите версию Apple Pages(275 кб) или.docx-файл(151 кб). Желаю всем более плавного и плавного пути по пути оптимизации производительности интерфейса! ! ! )

содержание

Подготовьтесь: планируйте и измеряйте

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

1. Повышайте осведомленность об оптимизации производительности

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

При отсутствии договоренности между отделом разработки/дизайна и бизнес-подразделением оптимизация производительности производиться не будет. Изучите отзывы пользователей после экспериментов с продуктом, чтобы увидеть, как улучшения производительности могут помочь решить эти распространенные проблемы.

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

Эллисон Макнайт в ее оСоздавайте долгосрочные оптимизации производительностиВ докладе был представлен подробный пример того, как она помогла Etsy оптимизировать производительность.

создатель оптимизации производительностиБрэд Фрост и Джонатан ФилдингКалькулятор оптимизации производительностиМожет помочь вам установить размер, до которого необходимо оптимизировать производительность.

2. Цель: быть как минимум на 20% быстрее своего самого быстрого конкурента.

Согласно исследованиям в области психологии, если вы хотите, чтобы пользователи чувствовали, что ваш сайт работает быстрее, чем сайт вашего конкурента, вам нужно быть как минимум на 20% быстрее. Изучите своих основных конкурентов, узнайте об их эффективности на мобильных и настольных устройствах и установите порог, по которому вы сможете их обойти. Чтобы получить точные результаты и цели, начните с изучения своей аналитики, чтобы увидеть, что делают ваши пользователи. Затем вы можете смоделировать опыт тестирования 90-го процентиля.

Чтобы лучше понять, как обстоят дела у ваших конкурентов, вы можете использоватьОтчет об удобстве использования Chrome(CrUX, готовый набор данных RUM, Илья ГригорикВидео введение),Speed Scorecard(также доступна оценка влияния на доход),Сравнение тестов реального взаимодействия с пользователемилиSiteSpeed CI(по результатам комплексного тестирования).

Уведомление: при использованииPage Speed Insights(устарело), ​​вы можете получить данные о производительности CrUX для конкретных страниц, а не только для агрегатов. Эти данные для настройкицелевая страницаилиинформация о продуктеЦели эффектов, такие как активы, очень полезны. Если вы используете CI для бюджета тестирования и CrUX для постановки целей, вам нужно убедиться, что ваша тестовая среда соответствует CrUX (спасибо, Патрик Минан!).

После сбора данных создайтеТаблицы, вычитание 20% из результата данных является вашей целью (т.е.бюджет производительности). Теперь у вас есть некоторые измеримые данные перед тестированием. Учитывая эти данные (бюджет производительности), попытайтесь добиться максимально быстрого взаимодействия с наименьшим количеством сценариев, и мы достигли нашей цели.

Необходимые ресурсы для старта:

Как только у вас будет готовый бюджет, используйтеWebpack Performance HintsиBundlesize,Lightouse CI,PWMetricsилиSitespeed CIВключите их в процесс сборки, чтобы обеспечить соблюдение бюджетов для запросов на вытягивание и предоставьте историю оценок в PR-комментариях. Если вам нужно что-то нестандартное, вы можете использоватьwebpagetest-charts-api, API конечной точки для построения диаграмм на основе результатов WebPagetest.

Например, какPinterestНапример, вы можете создать пользовательскийeslintПравило, запрещающее импорт из файлов и каталогов, которые, как известно, являются зависимостями и раздувают этот пакет. Настройка, которой можно поделиться в командеБезопасностьСписок пакетов.

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

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

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

3. Выберите правильные показатели

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

В любом случае, не сосредотачивайтесь на времени загрузки всей страницы (например,onLoadиDOMContentLoadedвремя), но отдавайте приоритет загрузке страницы, как ее воспринимает пользователь. То есть сосредоточиться на немного другом наборе показателей.

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

Вот некоторые из наиболее важных:

  • Кардинальные метрики( Количественные показатели ) в основном используются для измерения количества запросов, весов и показателей производительности. Он подходит для некоторых проектов, которые поднимают тревогу или отслеживают изменения с течением времени, но он не очень удобен для пользователя.
  • Основные показатели(Вехи) относится к статусу использования проекта в определенном жизненном цикле в процессе загрузки проекта, например, время, необходимое для достижения определенного узла жизни, или время, необходимое для завершения взаимодействия. Хотя эта метрика не фиксирует, что происходит между двумя разными жизненными циклами, она подходит для мониторинга и описания взаимодействия с пользователем.
  • показатели рендеринга( Показатели рендеринга ) используется для оценки скорости рендеринга содержимого страницы. Подходит для измерения и настройки производительности рендеринга, но не для измерения момента появления важного контента и взаимодействия с ним.
  • специальные показатели( Пользовательские показатели ) – это определенные настраиваемые события, используемые для оценки проекта. например твиттерTime To First Tweetи ПинтерестPinnerWaitTime. Он подходит для точного описания опыта пользователя и не подходит для сравнения с оппонентами по этому стандарту.

Вот некоторые из наиболее конкретных и актуальных показателей:

  • первое допустимое время рендеринга-- First Meaningful Paint (FMP) относится к тому моменту, когда основной контент появляется на странице, что дает вам представление о том, как быстро сервер выводит какие-либо данные. Длинный FMP в основном означает, что JavaScript блокирует основной поток, конечно, это также может быть вызвано проблемами с бэкэндом или сервером.
  • время взаимодействия(TTI) — это когда макет страницы стабилизировался, основные шрифты страницы видны, а основной процесс достаточен для обработки пользовательского ввода — основных отметок времени, которые пользователь может щелкнуть и взаимодействовать с пользовательским интерфейсом. Используется, чтобы узнать, сколько времени требуется пользователю, чтобы открыть веб-сайт без задержки.
  • входной ответ(FID) — это время, необходимое интерфейсу для ответа пользователю при реализации интерактивной операции.
  • индекс скорости-- Индекс скорости измеряет, насколько быстро содержимое страницы визуально заполняется, чем ниже показатель, тем лучше. Оценка индекса скорости рассчитывается на основе скорости вашего зрительного прогресса, это всего лишь расчетное значение, и оно чувствительно к размеру визуального окна, поэтому вам нужно определить тест, который соответствует массам (спасибо, Борис!) .
  • Затраченное процессорное времяОтносится к показателю времени ЦП, который показывает, насколько занят основной поток, обрабатывающий полезную нагрузку. Он показывает, как часто и как долго основной поток блокируется для рисования, рендеринга, сценариев и загрузки. По опыту janky, высокое время ЦП означает, что пользователи испытывают заметную задержку между своими действиями и их реакциями. С WebPageTest вы можетеНа вкладке Chrome выберите Capture Dev Tools Timeline., чтобы показать подробные оценки, когда основной поток запускается на любом устройстве с помощью WebPageTest.
  • Влияние веса рекламыЕсли основной доход вашего сайта поступает от рекламы, то код с рекламным бизнес-модулем вызывает особую озабоченность. Пэдди ГантисценарийСоздаются два URL-адреса (один обычный URL-адрес и один URL-адрес блокировки рекламы), предлагающие создать сравнение видео через WebPageTest и сообщить о разнице.
  • Метрики отклоненияДанные результатов измерения прибора могут сообщить нам о надежности прибора.Точно так же мы можем проанализировать данные результатов теста, а затем сделать баланс. В результатах данных стандарт, который сильно различается, должен быть сброшен, и это также помогает нам понять, труднее ли надежно измерить определенные страницы по какой-либо другой причине (например, сторонним скриптам). Кроме того, при развертывании новой версии браузера сравнение разницы в производительности между новой и старой версиями также является хорошим способом измерения отклонения.
  • специальные показателиТо есть это определяется потребностями вашего бизнеса и опытом клиентов. Это требует от вас анализа важных пикселей, ключевых скриптов, необходимых CSS и других связанных ресурсов, а также прогнозирования того, как быстро страница будет отображаться для пользователя. Для этого стандарта вы можете контролироватьВремя рендеринга герояили используйтеPerformance API, чтобы отметить отметку времени для важных событий в бизнесе. Кроме того, вы можете выполнить произвольный JavaScript в конце теста,Затем используйте результаты, чтобы определить пользовательские показатели для WebPagetest..

Steve Souders Каждая метрика подробно описана. Во многих случаях данные, которые мы измеряем, представляют собой данные об использовании программы в определенной среде, но входной ответ представляет собой фактический пользовательский опыт, на практике пользовательский опыт значительно отстает. Следовательно, относительно более точно поддерживать непрерывное измерение и сбор данных о поведении пользователей для формулирования метрик.

Предпочтительная метрика может варьироваться в зависимости от контекста приложения: например, для пользовательского интерфейса Netflix TV: входной ответ,использование памятиа ТТИ критичнее, для Википедии,Показатели первого/последнего визуального изменения и затраченного процессорного времениболее важный.

Примечание. Ни FID, ни TTI не учитывают поведение прокрутки; прокрутка может происходить независимо, поскольку это не основной поток, поэтому для многих сайтов, потребляющих контент, эти показатели могут быть относительно незначительными.

Ориентированные на пользователя показатели производительности обеспечивают лучшее понимание фактического взаимодействия с пользователем.входной ответ(FID) — это новая метрика, которая пытается достичь этого (спасибо, Патрик!).

4. Собирайте данные с устройств, используемых репрезентативным пользователем.

Чтобы собрать точные данные, нам необходимо как можно полнее выбрать тестируемые устройства. предпочтительноMoto G4или устройство Samsung среднего класса, или обычное устройство, такое как Nexus 5X. Если у вас нет под рукой устройства, вы можете использовать дросселирование ЦП (замедление в 5 раз), чтобы ограничить скорость сети (например, 150 мс задержка туда-обратно, ниже 1,5 Мбит/с и выше 0,7 Мбит/с), чтобы эмулировать мобильную работу на настольное устройство. Наконец, переключитесь на обычные 3G, 4G и Wi-Fi. Чтобы сделать производительность более заметной, вы даже можете использовать2GилиДроссельная сеть 3G, для более быстрого тестирования.

Представляем самый медленный день недели. Facebook запустил2G Tuesdays, чтобы улучшить видимость и чувствительность низких соединений.

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

  • Инструменты пассивного мониторинга, которые могут имитировать взаимодействие пользователей на основе запросов (синтетические тесты, такие как Lighthouse, WebPageTest)
  • **Инструменты активного мониторинга** – это инструменты, которые непрерывно регистрируют и оценивают действия пользователей (настоящий мониторинг пользователей,какSpeedCurve,New Relic- Оба инструмента также предоставляют комплексные тесты)

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

используяВремя навигации,время ресурса,время рисования,долгая задачаНаряду со встроенным RUM API пассивные и активные инструменты мониторинга производительности в совокупности дают полную картину производительности приложений. Например, вы можете использоватьPWMetrics,Calibre,SpeedCurve,mPulse,BoomerangиSitespeed.io, которые являются отличным выбором для инструментов мониторинга производительности.

Примечание. Всегда безопаснее выбирать ограничитель на уровне сети вне браузера, например, у DevTools есть проблемы с взаимодействием с HTTP/2 push из-за того, как он реализован (спасибо, Йоав, Патрик!). Для Mac OS мы можем использоватьNetwork Link Conditioner, Windows может использоватьWindows Traffic Shaper, Linux может использоватьnetem, FreeBSD может использоватьdummynet.

Lighthouse, инструмент проверки производительности, интегрированный в DevTools.

5. Настройте чистый профиль пользователя для тестирования

При тестировании в инструменте мониторинга необходимо отключить антивирус и фоновые задачи ЦП, удалить фоновые передачи полосы пропускания и очистить профиль пользователя. Нам нужно обратить внимание на предотвращение использования браузеров (Firefox,Chrome), что приводит к искажению результатов.

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

6. Делитесь контрольными списками производительности с коллегами

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

Ставьте реалистичные цели

7. Время отклика регулируется на уровне 100 мс, а частота кадров — на уровне 60 кадров в секунду.

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

RAIL, модель производительности, ориентированная на пользователя.

При этом каждый кадр анимации должен завершаться за 16 мс, в результате получается 60 кадров в секунду (1 секунда ÷ 60 = 16,6 мс) — предпочтительно 10 мс. Поскольку браузеру нужно время, чтобы отобразить новый кадр на экране, ваш код должен завершиться в течение 16,6 мс после срабатывания.Будьте оптимистичны в отношении дизайна страницыиИспользуйте свое свободное время с умом. Очевидно, что эти цели относятся к производительности во время выполнения, а не к производительности под нагрузкой.

8. SpeedIndex

Хотя этого может быть трудно достичь, хорошей конечной целью является рендеринг первого эффективного рендеринга менее чем за 1 с иSpeedIndexниже 1250. Поскольку мы моделируем задержку в оба конца 400 мс и скорость передачи 400 КБ на эталонном телефоне Android за 200 долларов (например, Moto G4) и медленной сети 3G, наша цель —Время взаимодействия менее 5 секунд, а время повторного посещения составляет менее 2 с.

Обратите внимание, что когда дело доходит до интерактивного времени, лучше прийтиРазличие между первым бездействием ЦП и временем до взаимодействияво избежание недопонимания между ними. Первый — это самая ранняя точка, которая появляется после того, как основной контент был отрендерен (окну требуется не менее 5 секунд, прежде чем страница начнет отвечать). Последнее является точкой, в которой ожидается, что страница всегда будет реагировать на ввод.

Первые 14–15 КБ загрузки HTML являются наиболее важными фрагментами полезной нагрузки — и единственной доставляемой частью бюджета для первого кругового пути (который получается менее чем за 1 секунду при задержке в 400 мс туда и обратно). Вообще говоря, для достижения вышеуказанных целей мы должны работать в пределах критического размера файла. После максимального сжатого бюджета в 170 КБ (распакованного 0,8–1 МБ) на разбор и компиляцию уходит до 1 с (в зависимости от типа ресурса). Немного выше, чем это нормально, но держите эти значения как можно ниже.

Тем не менее, можно увеличить размер бюджета привязки. Например, вы можете установить бюджет производительности в активности основного потока браузера, например, время отрисовки перед началом рендеринга илиОтслеживание внешнего процессора. рисунокCalibre,SpeedCurveиBundlesizeЭти инструменты могут помочь вам контролировать свой бюджет и интегрироваться в процесс сборки.

Из быстрого значения по умолчанию: Эдди ОсманиСовременные рекомендации по загрузке.

Бюджет производительности должен быть скорректирован с учетом сетевых условий среднего мобильного устройства.. (Изображение предоставлено Кэти Хемпениус)

Определить среду

9. Выберите и создайте инструменты сборки в соответствии с реальной ситуацией

Не зацикливайтесь на этих крутых инструментах сборки.. Создайте среду в соответствии с вашим проектом, будь то Grunt, Gulp, Webpack, Parcel или комбинация инструментов. Пока этот инструмент сборки позволяет вам быстро получать результаты и гарантирует, что ваш процесс сборки не будет проблемой, вы можете выбрать этот инструмент сборки.

Из всех инструментов сборки Webpack кажется наиболее зрелым, с сотнями доступных плагинов для оптимизации размера сборки. Начать работу с Webpack может быть сложно, если вы новичок. Итак, если вы хотите начать работу с webpack, вот несколько отличных ресурсов, которые помогут вам:

10. Используйте прогрессивное улучшение по умолчанию

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

11. Выберите надежный эталон производительности

Загрузка с таким количеством неизвестных эффектов - работа в сети, тепловое регулирование, перезапуск кеша, сторонние скрипты, режим блокировки парсера, чтение и запись на диск, IPC jank, установка плагинов, ограничения процессора, аппаратного обеспечения и памяти, кеши L2/L3, различия в RTTS , изображения, поведение при загрузке веб-шрифтов,Среди них стоимость сценария Javascript является самой большой., веб-шрифты блокируют рендеринг по умолчанию и загрузку изображений, что приводит к чрезмерному потреблению памяти. С узкими местами производительностиТрансфер с сервера на клиент, мы, как разработчики, должны более тщательно подумать обо всех этих неизвестных.

С бюджетом в 170 КБ, который уже включает критический путь HTML/CSS/JavaScript, маршрутизаторы, управление состоянием, утилиты, фреймворки и логику приложения, нам пришлось тщательноПроверьте стоимость передачи по сети, время синтаксического анализа/компиляции и время выполнениячтобы выбрать нашу рамку.

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

Эдди ОсманиБыстро по умолчанию: лучшие практики для современной загрузки

12. Оценивайте каждый фреймворк и каждую зависимость

Не каждому проекту нужен фреймворк,Также не каждая страница в одностраничном приложении должна загружать фрейм.. В случае с Netflix удаление React, нескольких библиотек из клиента и соответствующего кода приложения сократило общий объем JavaScript как минимум на 200 КБ, что позволилоNetflixВремя взаимодействия при выходе из домашней страницы Время взаимодействияукорачивается более чем на 50%. Затем команда использует время, которое пользователь проводит на странице входа, для предварительной выборки React (Нажмите здесь, чтобы узнать подробности).

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

Inian Parameshwaran Измерено воздействие на производительность 50 лучших фреймов.(противFirst Contentful Paint-- время от перехода до отображения браузером первой части контента из DOM). Иниан обнаружил, что Vue и Preact являются самыми быстрыми как на настольных компьютерах, так и на мобильных устройствах, за ними следует React (слайд-шоу). Вы можете изучить свои фреймворки-кандидаты и предлагаемые архитектуры, а также выяснить, как работает большинство решений, например рендеринг на стороне сервера или рендеринг на стороне клиента.

Вопросы стоимости эталонной производительности. в соответствии сАнкур СетипунктИсследовательская работа,** Независимо от того, насколько хорошо вы его оптимизируете, ваше приложение React никогда не будет загружаться быстрее, чем 1,1 с на среднем телефоне в Индии. Для запуска вашего приложения Angular всегда требуется не менее 2,7 с. Пользователям вашего приложения Vue нужно подождать не менее 1 секунды, чтобы начать его использовать. Хотя вы можете не ориентироваться на Индию как на ключевой рынок, пользователь, который посещает ваш сайт с плохим подключением к Интернету, должен иметь такой же опыт. Конечно, ваша проектная группа может пожертвовать эталонной производительностью ради простоты сопровождения и производительности разработчиков, но вы должны убедиться, что это решение является хорошо продуманным.

Вы можете оценить Сашу Грейфа, отслеживая функции, доступность, стабильность, производительность, экосистему пакетов, сообщество, кривую обучения, документацию, инструменты, послужной список, команду, совместимость, безопасность и многое другое.12-бальная система подсчета очковframework (или любую библиотеку JavaScript) на . Прежде чем сделать свой выбор, подумайте хотя бы о стоимости общего размера + времени начального синтаксического анализа: легковесные варианты, такие как Preact, Inferno, Vue, Svelte или Polymer, хорошо себя зарекомендовали. Базовый размер фреймворка будет определять ограничения для кода вашего приложения.

Хорошей отправной точкой является выбор хорошего стека по умолчанию для вашего приложения.Gatsby.js(реагировать),Preact CLIиPWA Starter KitПредоставляет разумные значения по умолчанию для быстрой загрузки на среднем мобильном оборудовании.

Источник изображения:Addy Osmani

13. Рассмотрите возможность использования режима PRPL и архитектуры оболочки приложения.

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

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

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

14. Оптимизируйте производительность API

API — это каналы связи, по которым приложения предоставляют данные внутренним и сторонним приложениям через так называемые конечные точки. существуетПри проектировании и создании API, нам нужен разумный протокол для поддержки связи между сервером и сторонними запросами.Representational State Transfer ( REST) является относительно полным и разумным выбором: он определяет набор ограничений, которым разработчики могут следовать для доступа к контенту производительным, надежным и масштабируемым способом. Веб-служба, соответствующая ограничениям REST, называется веб-службой RESTful.

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

Если многим ресурсам требуются данные API, API может вызвать узкие места в производительности.GraphQLобеспечивает производительность решение этих проблем. GraphQL — это серверный язык запросов API для выполнения запросов к системе типов, определяемых данными. В отличие от REST, где GraphQL может получить все данные в одном запросе и определить данные, от которых он зависит, REST извлекает слишком много необходимых данных.

Кроме того, поскольку GraphQL использует схему (метаданные, которые сообщают, как структурировать данные). Он может организовать данные в лучшую структуру.Мы можем использовать GraphQL для удаления кода JavaScript для управления состоянием., в результате чего более чистый код приложения на стороне клиента работает быстрее.

Если вы хотите начать изучать GraphQL, у Эрика Бэра есть две замечательные статьи в его журнале действительно Smashing:Вводное руководство по GraphQL 1: зачем нам новый API; Вводное руководство по GraphQL 2: разработка дизайна API(Спасибо, Леонардо!)

Разница между REST и GraphQL иллюстрируется разговором между Redux + REST слева и Apollo + GraphQL справа. (Изображение из:Hacker Noon).

15. Используете ли вы AMP или Instant Articles

В зависимости от приоритетов и стратегий вашей организации вы можете рассмотреть возможность использования GoogleAMP, ФейсбукInstant Articlesили яблокоApple News. Вы можете добиться высокой производительности и без них, но AMP предоставляет бесплатную платформу производительности сети доставки контента (CDN), а мгновенные статьи улучшат вашу видимость и производительность на Facebook.

Для пользователей основным преимуществом этих технологий является обеспечение производительности, поэтому иногда они предпочитают ссылки AMP-/Apple News/Instant Pages вместообщепринятыйи потенциально раздутые страницы. Для сайтов с большим объемом контента, которые обрабатывают много контента третьего метода, эти параметры значительно ускоряют время рендеринга.

если они не. Например, по словам Тима Кадлека,Документы AMP, как правило, быстрее, чем их аналоги, но это не обязательно означает, что страница является производительной; AMP не является самым большим отличием с точки зрения производительности..

Для веб-мастеров эти стили доступны на разных платформах иУлучшенная видимость в поисковых системах. Вы также можете повторно использовать AMP в качестве источника данных PWA для созданияПрогрессивные веб-AMP. В чем недостаток? Очевидно, что в огороженной области разработчики могут создавать и поддерживать отдельную версию от контента, предотвращая мгновенные статьи и новости Apple.нет фактических URL-адресов. (Спасибо, Эдди, Джереми.)

16. Используйте CDN с умом

В зависимости от объема имеющихся у вас динамических данных вы можетеаутсорсингдаватьгенератор статических сайтов, отправьте его в CDN и оттуда обслуживайте статическую версию, избегая запросов к базе данных. Вы даже можете выбрать на основе CDNСтатическая хостинговая платформа, чтобы вы могли обогатить свою страницу, добавив интерактивные компоненты на страницу (JAMStack). На самом деле, некоторые из этих генераторов (например,ReactвышеGatsby)в действительностикомпилятор веб-сайта, который предоставляет множество функций автоматической оптимизации. По мере того, как компилятор продолжает добавлять оптимизации, скомпилированный вывод становится меньше и быстрее.

Обратите внимание, что сети CDN также могут размещать и разгружать динамический контент, поэтому нет необходимости ограничивать сферу услуг CDN статическими ресурсами. (еще одна вещь, которую вы должны иметь в виду), независимо от того, выполняет ли ваша CDN сжатие контента (GZip), преобразование контента, транспорт HTTP/2 и ESI (язык разметки, который можно использовать для разделения веб-страниц на отдельные кэшируемые объекты) ) и другие операции, нам все же необходимо просмотреть вышеперечисленные операции, потому что вышеперечисленные операции будут не только агрегировать статический и динамический контент на странице на границе CDN (там, где сервер ближе всего к пользователю), но и выполнять другие задания.

Примечание. Согласно исследованию Патрика Минана и Энди Дэвиса, HTTP/2на многих CDNодеялоэффективно сломать, поэтому нам не следует слишком оптимистично относиться к улучшению его производительности.

Категории