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

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

Есть два типа подходов, которые можно использовать:

  • Обнаружение высокого уровня: вы начинаете с общих показателей и тестов, чтобы получить представление об общей производительности сайта. Это ни в коем случае не поверхностная работа. Необходимо достичь двух очень конкретных целей: получить четкое представление о состоянии веб-сайта и вычеркнуть общие проблемы. Как правило, он отвечает на вопросы требуется ли исправление? Соблюдает ли этот веб-сайт базовый бюджет производительности? Соответствует ли он установленным лучшим практикам? Есть ли gzip? Он обслуживается через HTTP 2? Статические активы обслуживаются через CDN? И так далее и тому подобное.
  • Устранение неполадок, связанных с конкретной проблемой или аспектом: в большинстве случаев это является продолжением предыдущего. Он адаптирован к имеющейся проблеме, и его трудно свести к контрольному списку того, что нужно искать. Как правило, вы в конечном итоге погружаетесь вглубь временной шкалы, пытаясь выяснить, что является основной причиной проблем, которые вы определили на предыдущем шаге.

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

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

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

Я читаю каждый комментарий, вносите свой вклад в беседу своими мыслями!