Демистификация Core Web Vitals для WordPress

Core Web Vitals теперь представляет собой набор обязательных показателей для оптимизации вашего сайта, особенно если SEO и производительность сайта важны для вашей цифровой стратегии. Тем не менее, может быть сложно определить, какие инструменты и стратегии WordPress наиболее важны при попытке улучшить основные веб-жизненные показатели вашего сайта.

Посмотрите этот сеанс, чтобы подробно ознакомиться с передовыми практиками и инструментами для понимания и улучшения показателей Core Web Vitals на вашем сайте WordPress.

Динамики:

• Алекс Зунига, менеджер по продукту в WP Engine
• Марк Даволи, директор по веб-разработке в Amsive Digital
• Мэтт Чейз, директор по развитию Vital Design
• Санжукта Гхош, старший веб-разработчик в WP Engine
• Майк Крэнти, директор по фронтенд-инжинирингу в XWP

Стенограмма:

АЛЕКС ЗУНИГА: Здравствуйте и добро пожаловать в Демистификацию основных веб-жизненных показателей для WordPress. Я Алекс Зунига, менеджер по продукту в WP Engine. И сегодня мы действительно собираемся обсудить все тонкости основных жизненно важных веб-сайтов для вашего сайта WordPress. Core Web Vitals — это обязательная метрика для оптимизации, если вы заботитесь об оптимизации своего сайта для SEO и производительности сайта. Но может быть трудно понять, какие инструменты и стратегии WordPress наиболее эффективны. Так что присоединяйтесь к этому сеансу, чтобы подробно изучить, как передовой опыт и инструменты могут помочь вам улучшить показатели жизненно важных веб-ресурсов для WordPress.

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

МАЙК КРАНТЕА: Привет, я Майк Крантеа. Я нахожусь на Канарских островах в Испании. Я директор по фронтенд-инжинирингу в XWP, где проработал последние 17 лет. В основном в сфере фронтенд-технологий мне нравится веб-производительность. И я рад быть здесь. Привет.

АЛЕКС ЗУНИГА: Спасибо, Майк. Далее у нас Мэтт Чейз.

Мэтт Чейз: Я директор по развитию компании Vital Design в Портсмуте, штат Нью-Гемпшир. Сильный фронтенд фокус на моей работе. Таким образом, мы делаем много маяков и баллов Core Web Vital.

АЛЕКС ЗУНИГА: Потрясающе. Спасибо, Мэтт. И Марк.

МАРК ДАВОЛИ: Здравствуйте, меня зовут Марк Даволи, директор по веб-разработке в Amsive Digital. Наша команда специализируется на пространстве Core Web Vital, поскольку SEO очень важно для нашей компании. А значит, и Core Web Vitals тоже. Счастлив быть здесь.

АЛЕКС ЗУНИГА: Рад видеть тебя, чувак. И, наконец, Санджукта.

САНДЖУКТА ГХОШ: Здравствуйте. Я тоже из WP Engine. Я являюсь частью команды, отвечающей за поддержку веб-сайтов WP Engine. И это включает в себя сайты, которые перешли к Delicious Brains, когда их приобрел WP Engine. И большую часть прошлого года я потратил на оптимизацию сайтов Delicious Brain для Core Web Vitals. Поэтому я думаю, что это должен быть очень интересный разговор. Счастлив быть здесь.

АЛЕКС ЗУНИГА: Спасибо. Спасибо. Что ж, добро пожаловать всем участникам нашей дискуссии. И нам не терпится услышать, что вы скажете. Итак, мы собираемся разбить эти вопросы по измерениям, управлению, инструментам и ожиданиям клиентов, когда речь идет о Core Web Vitals. Итак, наш первый вопрос, который мы хотим задать вам всем, почему меня вообще должно волновать Core Web Vitals? И в какой степени я должен сосредоточиться на оптимизации Core Web Vital?

МАРК ДАВОЛИ: Я могу поговорить об этом, если хотите. Для меня очень важно убедиться, что у вас высокая скорость страницы. И причина, по которой это важно, заключается в конверсии конечного результата. Верно? Таким образом, когда кто-то заходит на веб-сайт, чем дольше он загружается, тем больше вероятность того, что он соскочит с него. И если у вас нет высокой скорости страницы, то вам не повезет, и вы потеряете много бизнеса. Особенно в интернет-магазине.

САНДЖУКТА ГХОШ: Так что да. Я согласен с тем, что вы сказали, потому что, хотя это очень важно для SEO, мы также должны помнить, что Core Web Vitals — это мера воспринимаемой производительности вашего сайта. Как пользователь воспринимает ваш сайт. И я думаю, что очень важно удерживать внимание, чтобы пользователь воспринимал ваш сайт как отзывчивый, интерактивный и стабильный. Какие вещи измеряет Core Web Vitals. Поэтому я думаю, что даже больше, чем оценки SEO, важно, чтобы пользователь воспринимал вашу работу. И именно поэтому мы должны сосредоточиться на Core Web Vitals.

АЛЕКС ЗУНИГА: Абсолютно. Мэтт, у тебя было…

Мэтт Чейз: Да, в общем-то, это то, что я собирался сказать, да, аспект SEO великолепен. Но в конечном итоге мы кодируем эти сайты для людей. И мы хотим, чтобы у этих людей был самый быстрый и быстрый сайт. Но это влияет на оба мира. Верно? Итак, мы подошли к следующему: когда мы настраиваемся на эти Core Web Vitals, мы делаем отличный UX. Но таким образом, чтобы это удовлетворило SEO-команды, а победить в этой битве иногда не так-то просто. Так что это работает для всех.

АЛЕКС ЗУНИГА: Учитывая все сказанное, мы понимаем, что это важно. Но каковы наилучшие способы измерения нашего счета?

МАРК ДАВОЛИ: Итак, один из способов, которым мы измеряем, помимо использования… ну, есть Google Page Speed ​​Insight Tool, который имеет решающее значение, потому что это инструмент, который они используют для измерения. Правильно, поэтому, если вы хотите оказать влияние, использование этого инструмента жизненно важно. Ваш Lighthouse в браузере также есть прямо в Chrome DevTools, что очень важно. Кроме того, в Search Console есть отличный инструмент для отслеживания реальных пользовательских показателей за последние 28 дней, что очень важно для долгосрочного мониторинга.

САНДЖУКТА ГХОШ: Да. Так что я бы сказал, что Page Speed ​​Insights — очень хороший инструмент, потому что он дает вам обоим данные в режиме реального времени в том смысле, что сами Core Web Vitals основаны на реальных пользовательских данных за последние 28 дней. Но затем вы также можете увидеть свой отчет Lighthouse, основанный на лабораторных данных. И это то, что вы на самом деле можете сразу улучшить, потому что требуется некоторое время, прежде чем вы действительно увидите улучшения в Core Web Vitals, потому что они измеряются в течение определенного промежутка времени.

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

АЛЕКС ЗУНИГА: Потрясающе. Звучит как большой крик для Маяка там. Отличный. Отличный.

МАЙК КРАНТЕА: Я хотел бы добавить по этой теме, что отслеживание реальных данных о производительности пользовательских метрик стало лучше, чтобы иметь возможность быстрее реагировать на снижение производительности, достигшее производственной среды. Лабораторные тесты действительно помогают, когда вы находитесь в постановке. Например, сказать, что есть деградация, которую мы не хотим распространять. Но в производстве всегда происходит что-то, что может стать неожиданностью. И вместо того, чтобы ждать несколько недель, пока Search Console и реальные пользовательские показатели появятся в базе данных crux, отслеживая их самостоятельно с помощью библиотеки Web Vitals, вы можете оставаться на шаг впереди.

АЛЕКС ЗУНИГА: Потрясающе. Ага. Всегда нужно быть впереди тех производственных сюрпризов, которые иногда случаются. Все в порядке. Что ж, спасибо, что ответили на вопросы об измерении. Теперь, глядя на управление, какие одна или две вещи, которые вы можете сделать, окажут наибольшее влияние на Core Web Vitals?

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

МАРК ДАВОЛИ: Да. И для меня ключевым моментом является то, что мы называем приведенным выше рендером сгиба. Поэтому убедитесь, что это отображается как можно быстрее. И, как упоминалось ранее, откладывание и ленивая загрузка всего, что находится за пределами экрана, чтобы убедиться, что вы получите максимально возможный результат. При этом WP Rocket отлично подходит для своей функции сценариев задержки. Но мы склонны… как я стараюсь ограничить это GTM, или рекламными скриптами Google, или подобными вещами. И действительно сосредоточьтесь на улучшении фактической базовой архитектуры темы, на которой работает веб-сайт, чтобы убедиться, что он максимально оптимизирован. Таким образом, вы не полагаетесь на сторонний плагин, чтобы иметь такое влияние на производительность.

Мэтт Чейз: О, абсолютно. Ага. Оба конца.

АЛЕКС ЗУНИГА: Попался. Попался. И просто для уточнения, вы сказали WP Rocket. И это особенность скриптов задержки?

МАРК ДАВОЛИ: Да.

АЛЕКС ЗУНИГА: Потрясающе.

МАЙК КРАНТЕА: Одна вещь, которой не уделяется должного внимания, — это кэширование. Но быстрое время отклика сервера не гарантирует быстрой работы. Но если ваш сервер отвечает медленно, вы гарантируете медленную работу. Таким образом, использование всех доступных уровней кэширования — кэширование браузера, кэширование объектов, кэширование страниц — и их включение и функционирование — это хороший первый шаг. Делайте свои основы. А затем вы можете перейти к оптимизации внешнего интерфейса. Проверяю, что у тебя в голове. И так далее и тому подобное.

АЛЕКС ЗУНИГА: Отлично

САНДЖУКТА ГХОШ: Да. И я думаю, что мы также не должны забывать оптимизировать наши изображения. Я думаю, что это очень важно, потому что многие веб-сайты в наши дни, как правило, перегружены изображениями. Поэтому я думаю, что важно, чтобы вы сжимали свои изображения, обслуживали их через CDN, а затем, как вы уже упоминали, лениво загружали свои изображения. Что еще более важно, используйте адаптивные изображения. Таким образом, вы можете использовать атрибут исходного набора тега изображения или тега изображения для предоставления адаптивных изображений. Я видел, что это действительно приводит к значительному улучшению, потому что Core Web Vitals — это прежде всего мобильные измерения. Поэтому очень важно, чтобы вы обслуживали адаптивные изображения. Это то, что мы иногда забываем.

Так что я думаю образы. А также некоторые очень простые вещи, такие как минимизация вашего JavaScript в вашем CSS на этапах сборки. Думаю, это тоже очень помогает. Это довольно просто сделать.

Мэтт Чейз: Да. Что касается этого вопроса, на самом деле, поскольку вы подняли этот вопрос, WordPress распространяет своего рода упакованную систему сборки веб-пакетов. Они просто называют это в WordPress Scripts. И наше агентство долго мучилось, пытаясь поддерживать собственную систему веб-пакетов. А затем каждые восемь месяцев или около того какая-то зависимость узла менялась и ломала всю нашу цепочку инструментов. Но WordPress поддерживает это для нас. И это было огромным преимуществом.

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

МАРК ДАВОЛИ: Да. Также я считаю очень важным убедиться, что вы очень избирательны в отношении плагинов, которые вы используете на своем веб-сайте. Вы можете получить много неожиданного вредоносного ПО при установке сторонних плагинов. Поэтому постарайтесь ограничить их очень хорошо зарекомендовавшими себя, хорошо построенными плагинами. И обратите внимание на то, что загружают эти плагины. Это действительно может помочь контролировать производительность сайта. И, к сожалению, WordPress по-прежнему сильно зависит от jQuery для внутреннего использования и многого другого. Но это не обязательно для фронтенда. Поэтому, если возможно, отказ от поддержки jQuery в интерфейсе веб-сайта и использование нативного JavaScript может действительно повысить производительность.

АЛЕКС ЗУНИГА: Потрясающе. Я думаю, что мы как бы уже погружаемся в эту область. И вы упомянули несколько. Но давайте немного больше коснемся этого с инструментами. Какие инструменты вы предпочитаете использовать для оптимизации Core Web Vital? И для каких вариантов использования они лучше всего подходят? Или есть сценарии, в которых они не подходят?

Мэтт Чейз: Я имею в виду, это всплывало раньше. Но на самом деле мне больше всего нравится встроенный в браузер инструмент Lighthouse, потому что он дает немедленные результаты. Верно. Core Web Vitals великолепен, но его сила в том, что это совокупность, которая формируется с течением времени. Таким образом, вы не можете что-то изменить и увидеть изменение числа. По сравнению с Lighthouse, в браузере вы делаете обновление. Вы видите свою локальную среду разработки и запускаете тест Lighthouse. И сразу видно, о, моя производительность подскочила на 15 баллов. Прохладный. Это было правильно. Подтолкните это к производству.

АЛЕКС ЗУНИГА: Потрясающе. Любые другие инструменты, которые вы хотели бы использовать?

МАЙК КРАНТЕА: Я хотел бы особо отметить функцию локального переопределения в Chrome. Это, в сочетании с вкладкой «Производительность», дает вам хирургическую возможность поиграть с изменением даже порядка загрузки элементов на вашем веб-сайте. И насколько сильно это влияет. Это дает вам необходимый контроль, чтобы знать, стоит ли прилагать усилия для внесения определенного изменения, или вы просто хотите оставить его там и сосредоточиться на других вещах, которые действительно оказывают влияние.

МАРК ДАВОЛИ: И еще одна вещь, которую я считаю крайне важной, — это мониторинг серверной архитектуры. Верно. Таким образом, вы можете иметь самые лучшие в мире Core Web Vitals, но если ваш сервер подвергается необычно большой нагрузке, а вы этого не знаете, вы можете внезапно обнаружить, что ваша первая содержательная краска резко падает, что затем влияет практически на все остальное. Поэтому внимательно следите за такими инструментами, как New Relic или что-то еще, просто для мониторинга производительности. Крайне важно внимательно следить за тем, чтобы у вас была надлежащая инфраструктура для максимально быстрого рендеринга вашего веб-сайта.

МАЙК КРАНТЕА: И вот тут-то и помогает включение кэширования.

МАРК ДАВОЛИ: И CDN.

МАЙК КРАНТЕА: Да. Избегайте некоторых потенциальных бедствий.

АЛЕКС ЗУНИГА: Отлично. Что ж, я ценю эту ясность. Итак, один из вопросов. Существует множество плагинов для оптимизации Core Web Vitals. Каковы ограничения плагинов WordPress, чтобы помочь с этим? Или они действительно оптимизируют сайт? Или они просто обманывают измерения Google? И я думаю, может быть, это вопрос о том, что лучше — мы как бы упомянули, что лучше использовать плагины или выполнять работу вместо того, чтобы полагаться на плагин там?

САНДЖУКТА ГХОСЕ: Я думаю, что плагины — это здорово. Например, WP Rocket великолепен. Мы часто используем EWWW Image Optimizer. И я тоже думаю, что это здорово. Но, как мне кажется, это уже было сказано. WP Rocket, вы должны использовать его осторожно, потому что, если вы включите функцию отложенного JavaScript, я видел случаи, когда это приводило к странным ошибкам. Одноразовые баги. Поэтому я бы предпочел иногда, возможно, свернуть свое собственное решение, а не использовать плагин. При условии, что у вас есть опыт разработки.

Поэтому большую часть оптимизации, которую мы сделали для сайтов Delicious Brain, мы сделали сами, а не использовали плагин. Тем не менее, я думаю, что плагины — отличная отправная точка. Поэтому, когда вы только начинаете, вы можете, например, захотеть реализовать развертывание WP Rocket на своем промежуточном сайте, поэкспериментировать и посмотреть, не сломается ли он. Или если это принесет реальные улучшения. Поэтому я думаю, что плагины следует использовать осторожно. И вы должны знать, что происходит в фоновом режиме, что делают плагины. И как это может повлиять на ваш сайт.

Мэтт Чейз: Да. К счастью, WP Rocket, я думаю, в более поздних версиях, по крайней мере, очень четко маркирует опасные переключатели, которые у них есть. Потому что я тоже обжигался много раз, когда отложенные скрипты — и даже те, которые вы не ожидаете, такие как оптимизация CSS, каким-то образом ломали модели, где не было того, что сказало, что имя класса сделает их видимыми. . Так что это был волнующий день.

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

MIKE CRANTEA: Есть еще один плагин, помеченный как экспериментальный. Это лаборатория производительности. Это сделано основной командой WordPress Performance. И хотя это звучит как что-то пугающее, во всех моих тестах до сих пор он обеспечивал полную стабильность. И это было очень впечатляюще для того, что должно было быть, и качества работы, которая закончилась в этом плагине Performance Lab. Так что стоит попробовать. Пара галочек. И все, что там, в безопасности. Ну, я не уверен насчет переключения базы данных. Это что-то более спорное, когда я читал об этом. Ага. Просто не трогай эту кнопку. Например, они добавили поддержку SQLite или что-то в этом роде внутри плагина, который определенно работает для некоторых небольших веб-сайтов.

АЛЕКС ЗУНИГА: Интересно.

МАРК ДАВОЛИ: Да. И для меня WP Rocket — это фантастика. Мы ограничиваем его использование на большинстве наших сайтов, потому что большая часть того, что мы делаем, создается изначально. Но в Core WordPress есть много других функций, которые при правильном использовании действительно могут дать вам хорошо оптимизированный сайт. Например, использование редактора блоков вместо стороннего, такого как Elementor или т. д., может сильно раздуть сайт. Так что, если вы строите вокруг, как новая родная система блоков типов Gutenberg, и действительно загружаете файлы по мере необходимости вместо того, чтобы загружать все сразу на каждой отдельной странице, например. Теперь в WordPress встроены функции ленивой загрузки. Поэтому следите за тем, как он используется, и используйте его надлежащим образом, и так далее. А затем добавить такой инструмент, как WP Rocket, чтобы улучшить то, что уже есть. Но не только на него полагаясь.

Это может быть полезно для вас, особенно если у вас есть сайт, который не работает должным образом. Но, как уже упоминалось, как и генерация критического CSS, у этих вещей может быть много проблем, потому что они делают много предположений, основанных на том, что их бот видит на вашей странице. Но он не может предсказать вещи, которые не будут отображать первоначальные представления. Итак, если у вас есть модели, как уже упоминалось, они всплывают, он не узнает, что это возможно. Он не будет генерировать для него CSS и правильно его встраивать. Например, делать такие вещи, как предварительная загрузка ключевых шрифтов или рендеринг их в верхней части страницы. Опять же, это ключ. Действительно самое главное.

САНДЖУКТА ГХОЗ: Что касается темы критического CSS, я просто хотел вскочить и упомянуть, что у Эдди Османи есть замечательный инструмент под названием Critical. Вы можете добавить это в свой процесс сборки, чтобы сгенерировать свой критический CSS. Это потрясающе. И это очень надежно. Итак, поскольку вы упомянули критический CSS, я решил добавить это. Прости, что прервал тебя.

МАЙК КРАНТЕА: Все в порядке. Что касается той же темы критического CSS, команда Jetpack предприняла некоторые усилия, чтобы что-то сделать с плагином Jetpack Boost. Это очень, очень интересный способ создания критического CSS путем рендеринга страниц в iframe или что-то в этом роде. Это обеспечивает, когда это работает, это отличное решение. Когда это не так, он говорит вам, эй, здесь это не работает. Просто двигаться вперед. Вам нужно что-то еще. Не всегда легко добраться до критического CSS. С другой стороны, 4 или 5 лет назад критический CSS был очень большим. Это очень помогло.

За последние два или три года, с развитием HTTP/3, наличие одного критического CSS, отображающего блокировку, имеет очень незначительное влияние на 100 килобайт или что-то вроде встроенного CSS. Заставляет веб-сайт работать так же быстро, как веб-сайт, который четыре или пять лет назад имел критически важный CSS. Так что не бойтесь иметь CSS приличного размера внутри вашего сайта. Вам не нужно избавляться от него. И я видел веб-сайты, которые были супероптимизированы.

У нас есть критический CSS, например, 100 килобайт встроенного CSS. И блокировка рендеринга, jQuery и два других скрипта, которые не использовались. Это как, ура. Вы побеждаете цель с этим. Это может помочь нам последние 5% подхода. Но если вы начнете с этого, посмотрите на первое.

АЛЕКС ЗУНИГА: Потрясающе. Потрясающий. Я думаю, что все эти инструменты. Приятно слышать эти крики. И приятно слышать эти предложения и рекомендации. И много такого рода кружится вокруг нашего следующего вопроса. Каковы уникальные аспекты работы над WordPress с помощью Core Web Vitals? Вам нужно делать это с помощью плагинов, а не с любым другим технологическим стеком? С WordPress проще? Есть ли еще инструменты? Как мы только что упомянули, вы все только что отстреляли много инструментов. С WordPress проще? С WordPress сложнее? Что вы все берете?

Мэтт Чейз: Я думаю, что с WordPress это очень просто. Итак, мы немного поговорили — или я упомянул пакет узлов WordPress scripts, который они распространяют, который является просто отличной системой сборки веб-пакетов в коробке. У них также есть блок WordPress Create, который является очень быстрым и простым способом загрузки пользовательского блока для вашего сайта на основе WordPress. Но он построен таким образом, что большая часть связующего кода, так сказать, написана для вас. Так что это уже разумно... Марк, ты упомянул эти сценарии только в качестве реплики, когда ты должен был. Таким образом, вы знаете, делает ли ваш блок это прямо из ворот. Вам даже не нужно думать об этом. Так что WordPress делает такие вещи очень простыми.

МАРК ДАВОЛИ: Да, абсолютно. И это с открытым исходным кодом. Верно? Таким образом, вы можете изменить практически все. Из-за этого гораздо сложнее, когда вы работаете с закрытой системой, оптимизировать для Core Web Vitals по сравнению с WordPress. И когда Core Web Vitals впервые были анонсированы, этого еще не было. Это было намного сложнее. Они действительно проделали долгий путь, добавив множество этих функций, особенно с редактором блоков и построением на основе блоков и так далее, чтобы действительно оптимизировать эту возможность выборочной загрузки ресурсов, файлов CSS, файлов шрифтов и так далее. Так что да. Это было здорово.

АЛЕКС ЗУНИГА: Вероятно, это вызов закрытой системы по сравнению с открытым исходным кодом. Вперед, Санджукта.

САНДЖУКТА ГХОШ: Да. Ага. И я думаю, потому что есть много хостинг-провайдеров, специализирующихся на WordPress. И как вы сказали. WordPress с открытым исходным кодом. Таким образом, существует множество оптимизаций хостинга сайтов WordPress. И поэтому я думаю, что там уже есть большая поддержка, если вы строите поверх WordPress, а это значит, что вам не нужно изобретать велосипед. Так что я думаю, что это определенно проще, если вы строите поверх WordPress, чтобы оптимизировать свои основные веб-жизненные показатели.

АЛЕКС ЗУНИГА: Красиво. Итак, мы говорили о том, как мы оцениваем эти инструменты, что мы используем, чтобы реально улучшить наши основные веб-жизненные показатели, некоторые инструменты. Теперь, когда мы говорим об ожиданиях клиентов, на каком этапе нового проекта вы начинаете рассматривать Core Web Vitals как часть вашей сборки или стратегии? Это правильно, когда вы начинаете, как ваш базовый шаблонный шаблон? Или это то, что вы оптимизируете немного дальше по сюжету? Что вы все делаете?

Мэтт Чейз: Да. Я думаю, что для меня это больше просто способ начать что-то делать, чем то, что вы делаете с неоптимизированным веб-сайтом. Это с самого начала. И это есть в каждой строке кода, которую вы пишете идеально. Я стараюсь не делать этого — я не хочу создавать большой оптимизированный сайт, а потом возвращаться и исправлять его. Я хочу попытаться писать как можно чище с самого начала. И затем, как правило, я нахожу, что делать это таким образом, выжимая последний маленький кусочек сока оптимизации в конце, немного проще.

МАРК ДАВОЛИ: Да. Он абсолютно прав. Мы начинаем строить его прямо с самого начала. Я имею в виду, что есть компоненты, которые не происходят ближе к концу. Мы не собираемся проводить оптимизацию изображений ближе к запуску. Но на самом деле вам нужно даже не в самой сборке, а иногда даже в процессе проектирования, важно думать о том, как проектируется сайт, если вы принимаете во внимание Core Web Vitals. Потому что с архитектурной точки зрения более сложно реализовать одни проекты так, чтобы они были быстрыми, по сравнению с другими. Поэтому понимание этого и обучение дизайнеров тому, что потенциально может усложнить реализацию, а не нет, очень полезно.

МАЙК КРАНТЕА: И диктовать ограничения. Эй, у вас может быть только x телефонов. Вы не должны брать на стол 25 со всеми их вариациями. Это помогает на этапе проектирования. Кроме того, без каких-либо точек соприкосновения, которые происходят на протяжении всего проекта, иногда легко довести некоторые дела до конца. Как спринт семь запросов на добавление плагина викторины в микс. Если это не будет проверено, вы обнаружите, что это немного в конце. Так что мои рекомендации — обрабатывать это каждые пару спринтов. Мы проверяем наши автоматизированные измерения стадии развития событий. Что случилось с последними вещами, которые были вынуждены уйти. Замедлились ли дела? Нужно ли нам принимать какие-либо корректирующие меры заблаговременно, вместо того, чтобы реагировать в конце проекта?

САНДЖУКТА ГХОШ: Да. Я согласен. Очень важно, чтобы вы начали с этапа проектирования, потому что, как и простые вещи, например, должно ли быть всплывающее окно, рекламный баннер или что-то в этом роде. Иногда это может иметь огромное значение для вашей совокупной оценки макета. Так что хорошо знать заранее, что произойдет. Будет ли у вас всплывающее окно или баннер. И вы не хотите сюрпризов к концу вашего проекта. Поэтому я думаю, что очень важно вовлечь клиента или заинтересованные стороны прямо на этапе проектирования и сказать им, что это может повлиять на ваши основные веб-жизненные показатели, чтобы они могли принять обоснованное решение.

МАРК ДАВОЛИ: Это также очень полезно после запуска, потому что, как только ваш сайт выходит за дверь, иногда может быть что-то вроде: давайте добавим виджет чата или что-то подобное позже. А потом вдруг какой-то перегиб. И тогда вам нужно подумать о том, как нам это интегрировать и оптимизировать. Таким образом, функция сценариев задержки может подтолкнуть большинство рекламных пикселей, которые, как известно, плохо убивают ваш балл Core Web Vitals. Но иногда вы не можете что-то отложить, потому что это важно для того, чего действительно хочет клиент. Так что сбалансируйте его, насколько это возможно, и обязательно сообщите о потенциальных последствиях. И только конечный результат, чтобы получить его как можно быстрее. Иногда приходится жертвовать функциональностью. Иногда нет. Но сделайте это как можно быстрее, чтобы увеличить эти конверсии.

АЛЕКС ЗУНИГА: Отлично. Отличный. Я слышал что-то вроде того, что чем лучше ингредиенты, тем лучше веб-сайты с самого начала. Не то, чтобы мы просто собирались добавить некоторые основные веб-жизненные показатели в самом конце. Это то, что действительно является образом жизни, если вы хотите думать об этом в первую очередь. Что ж, здорово. Итак, наш последний вопрос. У вас когда-нибудь возникали проблемы с донесением ценности времени, которое вы тратите на работу над Core Web Vitals, до своих клиентов? Это что-то, что они когда-либо отвергают? Они никогда не понимают, почему вы делаете эту работу?

Мэтт Чейз: Я не думаю, что когда-либо получал какие-либо возражения. Если что, то как раз наоборот. Обычно нам нужна производительность. Нам нужны Core Web Vitals. Давайте сделаем это. Я скажу, что мы не всегда задумываемся… мы говорили о пикселях отслеживания и о том, как они печально известны тем, что снижают этот показатель. Но никого это не волнует. Мы такие же, как пиксели, пиксели, пиксели, пиксели. Таким образом, люди должны думать о фактическом взвешивании этой экономической выгоды, когда они добавляют отслеживание, потому что это не так просто, как просто включить его и получить результаты. Потому что есть цена.

АЛЕКС ЗУНИГА: Потрясающе.

МАЙК КРАНТЕА: Я думаю, что с производительностью не хватает терпения. Итак, если вы думаете, о, давайте поработаем над производительностью, которая продлится пару спринтов после первого. Когда я это увижу? Когда я это увижу? Планирование выпуска его итеративно, например, увеличение одной функции, одной функции, еще одной функции, повышает уверенность в том, какое влияние оказывает эта работа. И чем больше вы видите, что это приводит к конверсиям и изменениям, тем быстрее воспринимается ценность без необходимости тратить много времени на образовательную работу.

МАРК ДАВОЛИ: Да. И я думаю, что клиентам может быть сложно понять разницу между реальными пользовательскими показателями и лабораторными данными. Потому что многие из них могут запускать свои собственные тесты и тому подобное. И не до конца понять. Таким образом, помогая им понять, что часть сводной информации о происхождении страницы — это информация, которую Google использует, например, для ранжирования SEO и тому подобного. Потому что многие из них ищут этот результат и оптимизируют его. И помочь им понять, что требуется 28 дней, чтобы измерить любое изменение, внесенное в рабочую среду, прежде чем вы получите полную гамму того, как ваше изменение повлияло на вещи.

АЛЕКС ЗУНИГА: Это отличный призыв. Отличный призыв.

МАЙК КРАНТЕА: И я должен назвать одну из метрик, которая является самой запутанной из всех. Показатели интерактивности. Они были заведомо неустойчивыми. А для некоторых людей, которые больше боятся каких-либо изменений в счете, может ли та новая функция, которую мы создали, значительно замедлить работу веб-сайта? А потом снова пройти тест и подняться на 10 пунктов, а затем опуститься на 10 пунктов. Объяснение этой вариации занимает очень много времени. Почему это не только одно число, которое является последовательным? Ну, это так же сложно, как называть вещи и кэшировать.

АЛЕКС ЗУНИГА: Ну, круто. Похоже, мы очень ценим все ваши отзывы, все ваши отзывы о Core Web Vitals. Как их использовать, что использовать для их измерения, как установить ожидания клиентов для всего этого. Это действительно был урок обучения. Мы надеемся, что наши участники хорошо провели время, проведенное здесь. Нам определенно приятно слышать все ваши отзывы. И мы надеемся, что присутствующие здесь тоже получили отличные отзывы.

Так что всем вам большое спасибо за ваше время. Ну, это была наша панель. Мы действительно хотим сказать большое спасибо всем нашим участникам. Мы хотим поблагодарить вас за участие в этой панели. И мы надеемся, что вы прекрасно проведете время, наблюдая за остальными нашими сеансами DE{CODE}.