Продолжаем повышать производительность сайта

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

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

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

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

Давайте рассмотрим несколько инструментов, которые можно использовать для автоматизации измерений.

Автоматизация PageSpeed с помощью psi

Как вы, наверное, догадались из названия, psi это автоматизированный шлюз в PageSpeed Insights. Его можно использовать различными способами. Существует плагин Grunt, пример того, как это можно использовать с Gulp, интерфейс командной строки и программный API. По сути, это означает, что psi можно использовать практически с любой системой сборки, с которой вам комфортно работать.

Как вы видите, psi позволяет запускать любой сайт через их систему, и вы получаете отличный отчет в своем терминале, или отклик JSON, если вы используете программный API. Вы можете задать psi опцию threshold, определяя предельно низкий балл, который бы проходил тест. Если значение threshold не удовлетворено, тогда сборка не сработает, и ваше приложение не будет внедрено, если вы использовали какой-либо механизм непрерывного внедрения. Это отличный способ повышения производительности!

Автоматизация WebPageTest

WPT также можно автоматизировать через пакет npm webpagetest-api. Здесь процесс немного более сложный, так как вам все равно нужно выждать очередь, прежде чем вы сможете получить результат. Вы можете написать надстройку для webpagetest-api, которая будет ждать очереди за вас, но пакет сам по себе не способен ждать самостоятельно. Как только вы получите результаты, вы увидите безумный поток данных, который наштампует вам WPT, что делает его бесценным инструментом, несмотря на то, что тестирование может показаться немного громоздким.

Главное не забывайте, что нужно запускать сразу несколько тестов в WPT, чтобы гарантировать корректность результатов, которые он выдает. В частности, попробуйте протестировать свое приложение из различных точек и через различные типы связи.

В качестве альтернативы, используйте YSlow

Если предыдущих двух сервисов вам оказалось недостаточно, можете также использовать grunt-yslow. Это один из старейших существующих инструментов для оценки производительности, который создала компания Yahoo. Проблема его старости заключается в том, что он не учитывает некоторые последние рекомендации, которые есть в инструментах от Google. Несмотря на это, это один из немногих инструментов, которые можно запускать и в качестве расширения браузера, и непосредственно через командную строку (или с помощью Grunt), поэтому он тоже чего-то стоит.

Обратите внимание на то, как YSlow подает вам разряд, общий балл производительности, и всего несколько правил, которые вам следует обойти и посмотреть, насколько хорошо будет работать ваше приложение в реальном мире.

Планирование ресурсов и grunt-perfbudget

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

• Контрольные точки, такие как время до первого твита , время загрузки или в более широком понимании сколько времени занимает загрузка контента;
  
  • SpeedIndex индикатор, генерируемый WPT, который сообщает, насколько быстро происходит визуальная загрузка страницы;
    
  • Количественные показатели, такие как количество запросов, вес изображений и простота отслеживания точек данных;
    
  • Показатели, основанные на правилах один из простейших способов измерения производительности за счет отслеживания баллов, полученных из YSlow, WPT или PageSpeed.

Используя описанные выше пакеты, вы можете делать все это и даже больше, но если вам нужен более простой способ реализации, вам будет достаточно и grunt-perfbudget. Эта задача Grunt включает множество вариантов, позволяющих вам выбрать именно те показатели, которые важны для вашего приложения. Благодаря этому, WPT сообщает, удовлетворяются ли требования ресурсов производительности.

Обратите внимание, что задача может занять некоторое время ввиду очередности в WPT. При этом вы можете выбрать тип соединения и точки расположения, из которых можно тестировать, поэтому это также очень удобно делать при использовании grunt-perfbudget!