Борьба за ускорение сайтов продолжается и во многом упирается снова в незнание того, как правильно делать этот процесс. Многие открывают тест Pagespeed и считают ускорением получение там зеленых баллов. Но на самом деле все выглядит и работает иначе. Такие инструменты, как Page Speed Insights (PSI), предлагаются разработчикам веб-сайтов исключительно для тестирования и отладки. PSI не используется для ранжирования страницы.
Содержание
Чтобы рассчитать Core Web Vitals для вашего сайта, Google собирает полевые данные из браузеров Chrome посетителей вашего сайта и отправляет их на серверы Google в виде отчета CrUX. PSI можно легко обмануть, предварительно загрузив файлы JavaScript и CSS и не используя их сразу. PSI игнорирует такие предварительно загруженные ресурсы. Многие люди делают это, но большинство не проходит тривиальный тест, такой как локальный Lighthouse, выполняемый через ваш браузер Chrome (перейдите в режим инкогнито, используйте Inspect — Lighthouse). Плагин NitroPack извлекает все файлы сценариев и откладывает все оценки и выполнение JavaScript до первого взаимодействия с пользователем, такого как прокрутка или выбор пункта меню.
NitroPack использует успешную стратегию обмана, которая еще не обнаружена инструментами полевого тестирования Google. Google знает о своем поражении и планирует внедрять аудит времени для пользовательских потоков сверх начальной загрузки страницы. Таким образом, мы считаем, что мошенничество с NitroPack потеряет свою магическую силу к 2022 году.
Тем не менее, NitroPack уже есть за что ответить. NitroPack скрывает проблемы с метрикой Cumulative Layout Shift (CLS), обманывая PSI. Полевые инструменты улавливают это. В результате собственный веб-сайт NitroPack не проходит проверку Web Vitals, поскольку оценки CLS неудовлетворительны. NitroPack мог бы скорректировать свой результат раньше, если бы не манипулировали показателями CLS в PSI. Команда NitroPack должна искренне извиниться перед всеми своими пользователями, которые в настоящее время могут столкнуться с той же проблемой.
Пользователи NitroPack обеспокоены предполагаемым падением трафика на их сайты, измеренным с помощью Google Analytics. NitroPack решил устранить задержку в оценке и выполнении всего кода JavaScript, связанного с Google Analytics и ремаркетингом или ретаргетингом, чтобы избежать споров. В результате время LCP для большинства веб-сайтов, использующих NitroPack, теперь составляет 3 секунды на мобильных устройствах, что меньше 2,5-секундного ограничения, установленного Web Vital. По иронии судьбы, большинство профессиональных пользователей без колебаний откладывают Google Analytics или обслуживают его локально с помощью таких плагинов, как Flying Analytics , CAOS , WP Rocket или Perfmatters, для улучшения показателей Web Vital.NitroPack усердно работает над улучшением производительности своего плагина, чтобы оставаться конкурентоспособным даже после будущих обновлений Google для Lighthouse, которые могут устранить их мошенничество.
Главный аргумент в пользу мошенничества заключается в том, что NitroPack откладывает весь JavaScript до взаимодействия с пользователем, а для большинства веб-сайтов требуется, чтобы JavaScript был интерактивным. Когда пользователь взаимодействует с сайтом, весь отложенный мусор обрабатывается, поэтому пользовательский опыт не намного лучше, чем до установки NitroPack. Отложенный JavaScript — хороший метод для получения лучших результатов, но его не следует использовать для задержки всего, а только для задержки некритического JavaScript. Если вы хотите пойти по этому пути, используйте «WP Meteor», он в основном делает то же самое бесплатно.
Плагины кеширования с минимальными настройками
Оценка и анализ JavaScript являются серьезными проблемами, влияющими на показатели, измеряемые инструментами онлайн-тестирования скорости. Важно выполнять JavaScript только после того, как HTML-страница будет отрисована, чтобы оптимизировать работу посетителей. Блокирующий рендеринг характер выполнения JavaScript — хорошо известная проблема, и Google Web Vitals следят за тем, чтобы это выполнялось отложенным образом. Мы понимаем, что оптимизация JavaScript, созданного Elementor Pro и WordPress, является довольно технической проблемой для большинства агентств веб-дизайна. В конце концов, это хорошо отражено в их низкой скорости, выявленной в нашем исследовании . Но что они могут сделать сейчас, когда Google обновляет свои алгоритмы, добавляя показатели Page Experience?
Новое решение появилось в середине 2020 года. Новый плагин NitroPack от молодого болгарского стартапа может решить все их проблемы. Это действительно обеспечивает повышение скорости загрузки мобильной страницы, измеряемой PageSpeed Insights и GTMetrix.. Разработчики плагина рекламируют умные шаги по оптимизации программного обеспечения для своих алгоритмов кеширования, ведущие к впечатляющим улучшениям скорости. Но так ли это на самом деле? В конце концов, любой человек, когда-либо получивший серьезное образование в области информатики, знаком с одной из ее основных аксиом: « Мусор на входе, мусор на выходе ». Эта аксиома столь же фундаментальна, как и закон сохранения энергии в физике.
Нет сомнений в том, что правильные инструменты кэширования, сжатия изображений и плагины для выгрузки JavaScript играют решающую роль в улучшении скорости загрузки страницы. Наиболее эффективная комбинация полностью бесплатных инструментов — это LiteSpeed Cache (для минификации, слияния, критического CSS, отложенной загрузки, сжатия изображений, отсрочки JS, CDN с краевым кэшированием файлов HTML), OMGF (для локального размещения шрифтов) и Asset CleanUp.(для уменьшения раздувания JavaScript). Однако у таких инструментов есть множество настроек, которые зависят от интеллекта пользователя для принятия важных решений по повышению производительности веб-сайта. Похоже, что первоначальная мотивация команды NitroPack заключалась в том, чтобы заполнить этот особый пробел, заключающийся не только в предоставлении клиентам инструментов, но и в принятии за них лучших решений. Цель состоит не в том, чтобы помочь пользователям сделать лучшее суждение, не в том, чтобы предложить множество тематических исследований и видеоуроков, а в том, чтобы принимать все решения автоматически. NitroPack — не одинок в этом квесте: Гиджо Варгезе и его команда также поставляют новый плагин FlyingPress для обращения к похожим пользователям.
Хотя должно быть возможно иметь полностью автоматизированные решения для кэширования, которые помогут пользователям, не знающим об оптимизации скорости, добиться значительного улучшения скорости загрузки страницы, непрактично превзойти прилежного пользователя. Это не навсегда; люди не лучше машинного обучения для определенных задач. Искусственный интеллект копирайт помощник Jarvis из Conversion.ai уже обеспечивает лучшую копию , чем фрилансер с помощью GPT-3 DaVinci модели из OpenAI. И что еще более ужасающе, с помощью Jarvis вы можете писать образованные блоги с простым взглядом на любую тему, комбинируя и перефразируя контент из многочисленных сообщений, написанных людьми-блоггерами. Если вы хотите написать пост, не пытаясь сказать что-то новое — сделайте это вместе с Джарвисом, и вы получите более профессионально проработанный текст для своего блога. Ничто не мешает машинному обучению сдвинуть циферблат вперед для точной настройки параметров плагинов кэширования, но это не то, что происходит под капотом в NitroPack. Это что-то совсем другое и хитроумное.
Мы могли бы сравнить технические детали для конкретного веб-сайта, для этой конкретной веб-страницы NitroPack обслуживает только 12 отдельных запросов и 400 КБ данных в Google PageSpeed Insights. и GTMetrix. Что еще более шокирует, плагин NitroPack заставляет файлы CSS и Fonts загружаться из локального кеша в тестовой системе GTMetrix (оглядываясь назад, эти файлы могли быть загружены в отдельный процесс ЦП и игнорируются алгоритмами обработки GTMetrix). И GTMetrix, и Google PageSpeed Insights не смогли идентифицировать какие-либо таблицы стилей CSS и сценарии JS, предоставленные отдельно от встроенного кода в файле HTML. Вся нагрузка на обработку была вызвана встроенным CSS и JS, что заняло всего 100 мс.Инструмент WebPageTest показывает 46 запросов для того же веб-сайта, что и выше, включая четыре файла CSS и тридцать два файла JS, загруженных на страницу. WebPageTest определяет, что событие «Документ завершен» происходит перед загрузкой файлов CSS и JS. Он пометил эти дополнительные 36 файлов CSS и JS как предоставленное событие «После загрузки» и не включил какой-либо процесс дальнейшей оценки этих файлов в свои метрики. Тем не менее, WebPageTest определяет, что что-то не так, не предоставляя значение индекса скорости для такого ненормального веб-сайта. Для сравнения, в вашем локальном веб-браузере та же веб-страница будет обслуживать 149 запросов с 984 КБ переданных данных.
Уловка плагина NitroPack полностью исключает время на обработку CSS и JS из измерений, проводимых Google PageSpeed Insights или GTMetrix. Решение от NitroPack для загрузки JS и CSS в отдельном потоке было, вероятно, гениальным ходом, чтобы скрыть эти файлы от существующих алгоритмов инструментов тестирования показателей страницы. Сообщаемое повышение аналогично тому, которое достигается WebWhim при оптимизации производительности JavaScript с использованием допустимых методов. Разница в оценке данных с помощью инструментов тестирования показателей страницы по сравнению с оценкой данных браузером живого посетителя помогает пользователям NitroPack обмануть Google, чтобы сообщить об улучшениях времени до интерактивности и индекса скорости. С технической точки зрения веб-сайты NitroPack никогда не становятся интерактивными в Page Metric Tools, потому что вся интерактивность происходит от выполнения JavaScript и CSS. Большинство JS, сгенерированных в WordPress инструментами построения страниц, такими как Elementor, полагаются на библиотеку jQuery и не работают без файла jquery.min.js, загруженного, оцененного и проанализированного на веб-сайтах.
