Наши друзья из WP Engine недавно представили новую красивую домашнюю страницу, созданную с помощью Beaver Builder. Мы поделились ссылкой на страницу в группе Beaver Builders в Facebook, и несколько человек отметили, что общее время загрузки страницы было довольно большим. Наш хороший друг и выдающийся разработчик WordPress Джон Браун пришел на помощь с отличным объяснением.

Разговор в Facebook

Позвольте мне очень быстро перефразировать этот разговор:

Обеспокоенный Beaver Builder: я провел тест загрузки страницы с помощью инструмента тестирования XYZ, и загрузка заняла почти 10 секунд!

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

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

Эти оценки инструментов тестирования очень грубы и игнорируют многие практические реалии. Они скажут избегать перенаправлений, когда они предназначены для рекламы, сценариев отслеживания и других вещей, которые обязательно работают таким образом. Они часто игнорируют HTTP/2 и рекомендуют сокращать количество запросов и объединять ресурсы, которые не имеют значения и даже могут навредить… Они не сосредотачиваются на индексе скорости и рендеринге над сгибом…

Реальная загрузка страницы составляет <1,5 с.

Давайте копнем глубже

Я спросил Джона, не разрешит ли он задать еще несколько вопросов по поводу выступления, и он очень любезно согласился. Это мои (Робби) вопросы с ответами Джона.

О, я уже упоминал, что Джон управляет магазином индивидуальных разработок под названием 9seeds, поэтому его можно нанять, чтобы он помог вам точно настроить производительность вашего веб-сайта WordPress!

1. Вы упомянули «водопад». Можете ли вы рассказать немного больше о том, что такое водопад?

Существует множество инструментов для оценки эффективности сайта. Многие из них предоставляют отчет, включающий понятную буквенную оценку. Однако эти буквенные оценки — довольно грубый инструмент, и хотя приятно, когда вы получаете все «А», это не особенно полезно, не говоря уже о том, чтобы помочь, когда вы не видите прямую оценку «А». Единственная буквенная оценка, которую я считаю полезной, — это сжатие изображений, которое легко исправить: пропустите изображения через оптимизатор.

Слишком часто я вижу, как непрофессионалы и начинающие разработчики ослепляются буквами. На производительность веб-интерфейса влияет множество факторов, и действительно нужно обратить внимание на «водопад», который представляет собой просто график, показывающий все HTTP-запросы, когда они начались и когда завершились. Для их создания я использую WebPageTest.org.

«Водопад» — это то место, где вы «видите», какой конкретный ресурс загружается слишком долго и/или блокирует загрузку других объектов.

Наконец, учтите, что прямая оценка «А» может потребовать выбора дизайна (например, удаления ползунков) и исключения сторонних ресурсов (таких как Google Analytics, HotJar и т. д.), которые более ценны для владельца сайта, чем получение оценки «А». Не каждый сайт можно заставить выпрямиться Как без болезненных жертв.

2. Вы рекомендовали WebPageTest в качестве инструмента тестирования. Почему вы предпочитаете его и чем он отличается от таких инструментов, как Pingdom, GTmetrix (и/или Google Page Speed?)?

Лично я никогда не нашел ничего лучше и более гибкого, чем WebPageTest.org. Тем не менее, в прошлом я использовал GTMetrix, Pingdom, Google Page Speed ​​и другие, и с ними все было в порядке. Некоторые из новых, такие как Lighthouse, действительно хороши для прогрессивных веб-приложений (а не для 99% сайтов WordPress). Я, конечно, не говорю людям менять инструменты: используйте тот инструмент, который вы знаете и понимаете. Если вы не знаете ни одного инструмента, WPT — отличный бесплатный инструмент для изучения. Просто выйдите за рамки буквенных оценок и начните понимать, что является причиной этих буквенных оценок.

3. Что касается «сокращения запросов и объединения активов», разве это уже не лучшая практика? Почему?

Раньше, когда большинство сайтов были HTTP, а не HTTPS, и все веб-серверы использовали протокол HTTP/1.1, веб-серверы могли отправлять только ограниченное количество ресурсов параллельно. Каждый ресурс (изображение, скрипт, таблица стилей) отправлялся отдельно, и каждый имел свои собственные накладные расходы, что замедляло работу. Объединение всего возможного вместе уменьшило количество HTTP-запросов и дало огромный выигрыш в производительности.

За последние пару лет повсюду произошел огромный толчок к использованию HTTPS, и веб-серверы начали поддерживать новый протокол HTTP/2. HTTP/2 имеет огромные преимущества, такие как предварительная выборка и предварительная загрузка, но также может отправлять все эти крошечные ресурсы параллельно, поэтому нет необходимости их объединять. На самом деле, возможно, лучше этого не делать, чтобы каждый крошечный ресурс можно было кэшировать независимо.

Важно помнить, что это возможно только в том случае, если ваш веб-сервер поддерживает HTTP/2, а это возможно только в том случае, если ваш сайт использует HTTPS.

Тем не менее, все сайты, над которыми мы сейчас работаем, работают по протоколу HTTPS и работают на серверах с поддержкой HTTP/2, так что я уже даже не думаю об объединении ресурсов и уж точно не скучаю по этому поводу!

4. Есть ли еще какие-либо «мифы» или устаревшие рекомендации по производительности, против которых вы бы не рекомендовали?

Самое главное заключается в том, что каждый сайт может стать идеальным, не делая болезненных уступок, таких как изменение дизайна или удаление сторонних ресурсов, которые вы не контролируете. Однако это действительно нормально, потому что вам следует начать изучать что-то под названием «Индекс скорости»! У WPT есть хорошие отзывы по этому поводу, но в основном они учитывают, когда «выше сгиба» воспринимается пользователем как полностью загруженный. Речь идет о скорости работы пользователя, а не о том, чтобы страница была действительно завершенной. Это была одна из особенностей нового дизайна главной страницы WP Engine: индекс скорости был потрясающим. Это были отложенные сценарии, которые долго загружались и выполнялись.

5. Есть ли у вас какие-либо другие инструменты, советы или рекомендации по повышению производительности, которые вы бы порекомендовали кому-то?

Инструменты, которым я доверяю на протяжении многих лет:

• WebPageTest.org – Мой любимый!
• ImageOptim – настольное приложение для сжатия JPG/PNG
• ImageAlpha — настольное приложение для сжатия PNG (в основном за счет уменьшения количества цветов)
• CloudFlare — бесплатно как глобальный CDN, так и базовый WAF. Плюс впечатляющие платные профессиональные функции, такие как оптимизация изображений на лету, оптимизация маршрутов и многое другое.

Плагины:

• WP Rocket – Даже на WP Engine мы используем WP Rocket, он просто работает.
• Imagify.io – оптимизация изображений на базе WordPress/облака.
• BeaverBuilder – мне не заплатили за то, чтобы я это сказал! Нас призывают провести аудит производительности на многих сайтах, и мы часто видим серьезные проблемы с интерфейсом и серверной частью других популярных конструкторов страниц. Я не буду называть имени, но не с Beaver Builder, поэтому мы используем его на нашем собственном сайте в качестве хорошо!

Еще раз спасибо, Джон, за то, что нашел время рассказать нам о более современном подходе к производительности. Я хотел в последний раз рассказать об агентстве Джона, 9seeds. Если вам нужна помощь в какой-либо индивидуальной разработке WordPress, позвоните им!

О Джоне Брауне

Странник. Разработчик WordPress. Фотограф. Печень Жизни.