10 заблуждений о веб-производительности

Наша миссия в WP Rocket — информировать пользователей о важности веб-производительности, делая ее максимально простой и доступной. Это довольно сложная задача: веб-производительность — непростая тема, а оптимизацию веб-сайта для повышения производительности еще труднее объяснить и понять. Более того, найти достоверную информацию сложно – тема сложная и иногда субъективная.

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

Каковы наиболее распространенные заблуждения о веб-производительности?

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

1. Задержка JavaScript

Оптимизация файлов JavaScript — одна из самых сложных задач оптимизации веб-производительности. Это также один из наиболее эффективных способов повышения производительности и ключевых показателей, таких как Core Web Vitals. Другими словами, вы не можете избежать оптимизации JavaScript, если вам нужен быстрый веб-сайт. Один из эффективных способов — отложить JS-файлы, которые не нужно выполнять немедленно. В результате страница будет загружаться быстрее, а браузер будет выполнять JavaScript только тогда, когда это необходимо для взаимодействия с пользователем.

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

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

Например, WP Rocket позволяет вам легко управлять функцией Delay JS. Опция позволяет легко отложить JS — ключевую задачу оптимизации. Кроме того, WP Rocket позволяет вам исключать файлы JavaScript как вручную, так и благодаря исключению в один клик, выпущенному в нашей последней основной версии WP Rocket 3.13.

Мы спросили Адама Сильверстайна, инженера по связям с разработчиками в Google , что они думают о постоянной задержке JavaScript и ее влиянии на производительность. Он подтверждает нашу точку зрения и добавляет: «Как правило, для серверных сайтов, таких как сайты WordPress, большую часть JavaScript можно отложить, если по какой-то причине он не требуется в начале цикла страницы. Примером могут служить сценарии аналитики, в которых вы хотите собирать данные как можно быстрее: здесь более уместен атрибут async. Один из потенциальных рисков, связанных с отложенными сценариями, заключается в том, что если другие сценарии или встроенные сценарии зависят от отложенного сценария (а также не откладываются), зависимость может разорваться».

Итак, пришло время разобраться с неправильным представлением об отсрочке JavaScript.

2. Отложите JavaScript

Здесь заблуждение состоит в том, что все JS можно отложить.

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

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

Адам Сильверстайн упоминает о скором выпуске нового предложения API скриптов WordPress. Это поможет стратегии отсрочки, определяя тактику загрузки и предотвращая проблемы с зависимостями.

Адам объясняет: « В предлагаемом подходе для ядра мы автоматически обрабатываем случаи отсрочки с помощью основного подхода к стратегии сценариев, включая проверку зависимых сценариев на возможность отложенного выполнения и обработку отложенного выполнения встроенных сценариев, которые зависят от отложенного сценария».

Когда дело доходит до отсрочки JavaScript, в WP Rocket есть множество автоматических исключений для предотвращения конфликтов. Например, когда Avada включена, WP Rocket автоматически исключает библиотеку jQuery и внешний скрипт Google Maps.

Новый Script API позволит нашему плагину еще больше расширить библиотеку исключений. В результате вероятность того, что ваш сайт сломается при откладывании JavaScript, будет все меньше и меньше.

3. Сокращение используемого CSS

В дополнение к оптимизации JavaScript сокращение использования CSS является одним из наиболее эффективных способов повысить производительность вашего веб-сайта. Есть два способа управлять такой оптимизацией:

• Встраивание файлов CSS, что означает интеграцию CSS на той же странице с использованием тега `style`.
• Используйте отдельные внешние файлы.

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

Правда в том, что встраивание CSS совершенно нормально и имеет два важных преимущества с точки зрения производительности и взаимодействия с пользователем:

• Это более быстрый процесс, потому что браузер будет делать только крошечный запрос, чтобы проверить свежесть страницы. Если страница не изменилась, что обычно и бывает, браузер выдаст кешированную копию страницы. По этой причине встроенный используемый CSS улучшит производительность: браузер не будет загружать и анализировать файл CSS, а будет напрямую обрабатывать встроенный CSS на странице.
  
• Встраивание всего CSS страницы предотвращает такие проблемы, как FOUC (Flash нестилизованного контента), и не влияет на взаимодействие с пользователем, как это может сделать использование CSS Critical Path в дополнение к отдельному файлу. Чтобы предотвратить ухудшение других показателей, наличие CSS критического пути должно требоваться, когда используемый CSS доставляется с использованием файла.

Вот почему WP Rocket встраивает CSS и позволяет любому воспользоваться расширенной функцией, такой как удаление неиспользуемого CSS одним щелчком мыши:

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

4. Размещайте шрифты локально

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

Что касается шрифтов Google, важно контролировать, откуда будут отправляться файлы, чтобы они не зависели от CDN Google Fonts, особенно если он плохо работает для большей части аудитории.

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

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

Если веб-сайт использует CDN, шрифты Google будут работать быстрее только в том случае, если покрытие CDN лучше, чем у Google Fonts, что сильно зависит от местоположения посетителя.

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

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

Другое заблуждение относительно локального размещения шрифтов заключается в том, что WP Rocket не может предварительно загружать шрифты Google. Это неверно: наш плагин может автоматически предварительно загружать шрифты Google, если включен параметр «Удалить неиспользуемый CSS».

5. Подсказка по ресурсу Fetchpriority

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

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

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

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

Мы привели несколько примеров, чтобы объяснить, как fetchpriority зависит от нескольких факторов.

• Логотип и изображение LCP : это легко — эти элементы являются очевидными кандидатами с высоким приоритетом извлечения.
  
• Слайдеры : становится все сложнее.
  
  Изображения ползунка выше или рядом со сгибом будут иметь субъективный приоритет загрузки в зависимости от того, вызывают ли они проблему.
  
  Если слайдер находится почти на сгибе, но считается критически важным для взаимодействия с пользователем, его первое изображение должно иметь высокий приоритет.
  
  Если слайдер задерживается, нет необходимости расставлять приоритеты для получения его изображений, даже если он находится выше сгиба.

• CSS, JS и сторонние ресурсы : только их соответствующие разработчики могут оценить, должны ли они быть приоритетными или деприоритетными. И даже при их вводе и при смешивании нескольких плагинов и ресурсов приоритет выборки будет зависеть от случая.

Вы можете видеть, что мы имеем в виду, когда говорим, что подсказки ресурсов не так просты, как вы думаете.

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

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

Адам Сильверстайн поясняет: «В целом цель должна состоять в том, чтобы добавить fetchpriority=high только к важным изображениям, потому что добавление его к нескольким изображениям, как правило, сводит на нет все преимущества. Обычно вы хотите, чтобы образ LCP был установлен с этим атрибутом, но хорошо подумайте, прежде чем использовать его на многих других ресурсах. Эта страница — лучший ресурс для понимания приоритета загрузки. Как правило, все изображения начинаются с низкого приоритета. Изображения в области просмотра начинаются с «низкого» приоритета, а затем во время компоновки, когда браузер понимает, что они находятся в области просмотра, повышаются до «высокого». Пометив его в разметке с помощью fetchpriority="high", они могут сразу начать с "high" и загружаться намного быстрее. Если вы пометите слишком много изображений как высокий приоритет, они будут конкурировать за одни и те же ресурсы. Одним из возможных исключений может быть попытка пометить образ LCP как для настольных, так и для мобильных устройств (это может быть другой образ). Функция «экспериментов» WebPageTest — отличный способ проверить это».

Говоря о fetchpriority, интересно отметить, что команда Core Performance Team предложила добавить атрибут fetchpriority=»high» к изображениям LCP в ядре WordPress для повышения производительности LCP.

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

6. Ленивая загрузка фоновых изображений

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

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

Заблуждение состоит в том, что фоновые изображения, добавленные во внутренний CSS (тег `style`), и файлы CSS могут загружаться отложенно. Правда в том, что WordPress, библиотеки отложенной загрузки и нативная отложенная загрузка не допускают такой оптимизации, которая должна быть точной, и это не так просто, как может показаться.

В WP Rocket мы работали над определенной функцией, чтобы сделать эту оптимизацию простой и автоматизированной, но при этом точной.

7. Изображения LCP и изображения выше сгиба

Говоря об отложенной загрузке и атрибуте приоритета выборки, еще одно заблуждение состоит в том, что все, что находится выше сгиба, должно иметь высокое значение (fetchpriority=high).

Адам Сильверстайн объясняет: «Оптимизация Fetchpriority в идеале должна применяться только к изображению LCP. В то же время все изображения в верхней части страницы должны избегать ленивой загрузки».

И добавляет пример: «Допустим, есть шесть изображений над линией сгиба и одно изображение LCP. Тогда лучшим подходом было бы исключить ленивую загрузку из всех образов и применить fetchpriority к образу LCP».

8. Исключите изображения выше сгиба из ленивой загрузки

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

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

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

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

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

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

Мы провели несколько тестов и получили интересные результаты. При правильной реализации и исключении точного количества изображений выше сгиба из отложенной загрузки он может улучшить такие показатели, как первая содержательная отрисовка, самая большая содержательная отрисовка и индекс скорости. Кроме того, он может выполнять аудиты PageSpeed ​​Insights, такие как «Избегайте чрезмерной нагрузки на сеть» и «Поддерживайте низкое количество запросов и небольшие размеры передачи».

Тем временем WP Rocket позволяет решить эту проблему с помощью вспомогательного плагина.

9. Изображение предварительного просмотра YouTube Iframe

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

Тем не менее, к этому моменту статьи вы должны быть знакомы с концепцией: это зависит.

Внедрение изображения предварительного просмотра iframe YouTube для оптимизации производительности не будет работать для всех веб-сайтов. Это может вызвать проблемы, если родительский элемент, содержащий видео, стилизует изображения непригодным для использования способом. Если это так, изображение предварительного просмотра не будет отображаться правильно, и может потребоваться дополнительный CSS для отмены конфликтующего стиля родительского элемента.

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

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

Наши тесты показывают, что YouTube CDN по-прежнему работает лучше всего и имеет самый низкий показатель TTFB, что влияет на скорость загрузки изображения.

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

10. Использование CDN

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

Это зависит от местоположения посетителя и расстояния между пользователем и запрашиваемыми активами.

Приведем пару примеров, чтобы было понятнее.

• Местная аудитория : вы ведете местный бизнес во Франции, и ваш веб-сайт уже размещен на локальном сервере. Использование CDN, у которого нет PoP (точки присутствия) во Франции или рядом с ней, ухудшит работу пользователя, поскольку страница и ее активы будут отправлены из удаленного центра обработки данных, скажем, из Нью-Йорка. С другой стороны, расстояние будет короче, если вы просто используете исходный сервер.

• Регион или всемирная аудитория : вы управляете региональным бизнесом в Европе. Выбор CDN с сильным присутствием в Европе даст лучшие результаты по сравнению с выбором CDN, у которого есть только одна или две точки присутствия в Европе.

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

Подведение итогов

Оптимизировать веб-производительность совсем не просто — и эта статья еще раз доказывает это. Надеюсь, это пролило свет на некоторые неправильные представления о ключевых темах, таких как оптимизация JavaScript и CSS и отложенная загрузка.

В WP Rocket мы стремимся сделать наш плагин производительности максимально простым, предлагая при этом самые продвинутые функции для повышения производительности вашего сайта. Мы знаем, о чем говорим, и всегда постараемся объяснить как можно проще. А пока попробуйте WP Rocket и убедитесь, насколько это просто и мощно!