Как улучшить скорость загрузки сайта мероприятий на WordPress

Как улучшить скорость загрузки сайта мероприятий на WordPress

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

Используйте данные с пользовательских площадок, чтобы увидеть, с чем сталкиваются реальные посетители, а затем воспользуйтесь PageSpeed ​​Insights, Chrome DevTools, мониторингом сервера и диагностическими инструментами WordPress, чтобы найти причину.

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

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

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

Регистрация добавляет AJAX-запросы и запись в базу данных. Оформление заказа добавляет пользовательскую сессию и платежный шлюз.

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

Календарь -> Событие -> Регистрация -> Оформление заказа

Сначала определите самый медленный этап. Затем выясните, на чем именно заключается задержка: в браузере, WordPress, базе данных, сервере или внешнем сервисе.

В этом руководстве описана техническая часть. Если вы всё ещё занимаетесь созданием сайта, начните с полного руководства по созданию сайта мероприятия с помощью WordPress . Идеи по макету и дизайну можно найти в этих примерах сайтов мероприятий.

Почему для сайтов мероприятий требуется другой тест скорости?

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

Стандартный корпоративный веб-сайт в основном содержит публикации и страницы. Сайт мероприятия также может включать в себя:

• Запрос предстоящих и повторяющихся событий в заданном диапазоне дат.
• Восстановить отображение месяца, списка, карты или отфильтрованного представления после взаимодействия с ним посетителя.
• Загрузите схемы площадки, фотографии докладчиков, видеозаписи выступлений, таймеры обратного отсчета и виджеты для социальных сетей.
• Проверьте наличие билетов, пока несколько посетителей бронируют их одновременно.
• Запишите данные об участниках в базу данных и отправьте их по электронной почте или в CRM-систему.
• Поддерживать WooCommerce Проведите сессию и дождитесь завершения платежа.
• Импортируйте события и запускайте запланированные задания в фоновом режиме.
• Справиться с внезапным наплывом покупателей, когда билеты поступят в продажу.

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

CDN может предоставлять изображения докладчиков ближе к посетителям, но он не может добавлять PHP-воркеры в очередь запросов на бронирование на сервере.

Четырехэтапный подход позволяет сосредоточить исследование на том, что пытается сделать посетитель. Он также дает более четкое представление о производительности веб-сайта WordPress, посвященного мероприятиям , чем тестирование только главной страницы.

Как измерить скорость загрузки сайта мероприятия на WordPress?

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

Начните с четырех репрезентативных URL-адресов:

Этап	Страница или действие для тестирования	Запись	Типичная подсказка
Календарь	Короткий код архива главных событий или календаря самых загруженных событий.	Время до первого байта (TTFB), время выполнения запроса, ответ в следующем месяце, количество запросов.	Первоначальный просмотр или фильтрация происходит медленно.
События	Страница, посвященная одному событию и содержащая много медиаконтента.	Largest Contentful Paint (LCP), размер страницы, запросы третьих сторон	Загрузка страницы задерживается из-за элементов «Герой», «Карта», «Видео» или «Галерея».
Регистрация	Форма бронирования и запрос на ее отправку.	Взаимодействие с Next Paint (INP), длительность AJAX-запросов, ошибки	Страница загружается быстро, но отправка происходит медленно.
Оформление заказа	Корзина и процесс оплаты, если используются	TTFB, запросы к шлюзу, неудачные заказы	Публичные страницы работают быстро, но платежи задерживаются.

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

Создайте базовый уровень

1. Откройте PageSpeed ​​Insights и протестируйте все четыре URL-адреса на мобильных устройствах и компьютерах.
2. Сохраните результат проверки данных полей, когда URL-адрес или источник будет иметь достаточный трафик. Не рассматривайте отсутствие данных полей как положительный результат.
3. Проведите лабораторный тест как минимум три раза для каждого URL-адреса. Сохраняйте медианное значение, а не лучший результат.
4. Повторите проверку календаря после изменения месяца или применения стандартного фильтра.
5. Откройте инструменты разработчика Chrome, выберите панель «Сеть» и запишите запрос на регистрацию. Отфильтруйте по: Fetch/XHR изолировать запрос.
6. Запишите, были ли вы авторизованы, был ли активен кэш страницы, какой профиль устройства вы использовали и где проводилось тестирование.

Текущие оптимальные пороговые значения Core Web Vitals от Google составляют: LCP — 2.5 секунды или меньше, INP — 200 миллисекунд или меньше, и Cumulative Layout Shift (CLS) — 0.1 или меньше. Согласно документации Web Vitals , эти показатели оцениваются на уровне 75-го процентиля посещений.

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

Что следует проверить, если весь сайт работает медленно?

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

Диагностика задержки

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

Затем изолируйте стек WordPress. В официальном руководстве по устранению неполадок «Проверка работоспособности» объясняется, как режим устранения неполадок может отключать плагины и переключать темы для сессии администратора, не изменяя того, что видят обычные посетители. Используйте его в периоды затишья или на тестовом сервере:

1. Перейдите на Plugins > Add New и установить Проверка работоспособности и устранение неполадок.
2. Открыто Tools > Site Health > Troubleshooting и включите режим устранения неполадок.
3. Протестируйте с использованием стандартной темы WordPress и только активного плагина для мероприятий.
4. Включайте тему и другие плагины по одному, повторяя проверку URL-адреса после каждого изменения.

Устраните выявленную причину.

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

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

Подтвердите изменение

Восстановите исходную тему оформления и необходимые плагины, очистите кэш, затем повторите те же три теста. Изменение сервера считается успешным, если среднее время ответа на обратный звонок (TTFB) улучшается на затронутых URL-адресах, и рабочий процесс обработки событий по-прежнему работает.

Как исправить проблему с медленной работой календаря событий WordPress?

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

Диагностика календаря

Сравните архив событий с простой страницей и архивом одного события. Затем ответьте на следующие вопросы:

• Медленно ли загружается только первый календарь, или же медленно происходит и смена месяцев, и работа фильтров?
• Усугубляется ли проблема, когда представление включает больше событий?
• Можно ли считать повторяющиеся события незавершенными, если у сериала известна дата окончания?
• Загружаются ли все маркеры на карте одновременно?
• Включаются ли в публичные запросы события, срок действия которых истек?
• Большую часть времени занимают AJAX-запросы, или же браузер занят отрисовкой карточек и скриптов после этого?

Установите Query Monitor на тестовом сервере или во время контролируемой диагностической сессии. Откройте календарь медленных запросов, войдя в систему, выберите «Запросы» в меню панели инструментов администратора и отсортируйте по времени.

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

Сократите нагрузку на календарь.

Начните с изменений в конфигурации, которые сократят объем работы на каждый запрос:

1. Отображайте меньше событий в исходном списке или таблице и добавьте пагинацию.
2. Если поиск по всему архиву не требуется, используйте более узкий диапазон дат.
3. Если таковая существует, указывайте реальную дату окончания для повторяющихся сериалов.
4. Не следует загружать большую карту в качестве календаря по умолчанию, если список может быстрее ответить на первый вопрос.
5. Удалите модули, которые страница не использует, например, погоду, таймер обратного отсчета, галерею или карту.
6. Определите, как долго прошлые события должны оставаться в открытом доступе. Архивируйте или удаляйте их только после подтверждения требований к сроку хранения и создания резервной копии.

Сайты, использующие Modern Events Calendar имеет несколько соответствующих элементов управления. Перейдите по ссылке. MEC Settings > General > Advanced Для обзора Обслуживание и Ресурсы (CSS и JavaScript файлы).

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

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

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

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

Раскрытие информации: Webnus развивается Modern Events CalendarПриведенные выше настройки связаны с документацией по продукту, поэтому вы можете проверить их работу и пути в меню.

Проверьте правильность календаря.

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

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

Как исправить проблемы с ресурсоемкими страницами, содержащими одно событие?

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

Найдите элемент LCP и дорогостоящие активы.

Откройте страницу события в Chrome, откройте Инструменты разработчика и выберите «Производительность» . В представлении «Метрики в реальном времени» отображается локальный элемент LCP; наведите на него курсор, чтобы выделить элемент на странице.

Запишите трассировку загрузки, если вам нужно увидеть, когда браузер обнаружил и отобразил элемент. В справочнике по панели «Производительность » Chrome объясняется назначение маркеров и подробная информация об элементе.

Затем воспользуйтесь панелью «Сеть»:

1. Отключите кэширование браузера, пока открыты инструменты разработчика.
2. Перезагрузите страницу.
3. Сортировать по: Размер для поиска больших изображений и файлов видеопостеров.
4. Сортировать по: Длительность для поиска медленно работающих шрифтов, карт, встроенных элементов и API.
5. Отфильтруйте результаты по домену стороннего сервиса, чтобы увидеть, сколько запросов генерирует один виджет.

Чтобы просмотреть файлы плагинов и тем, откройте панель « Покрытие кода » в инструментах разработчика , перезагрузите страницу и поработайте с элементами управления календарем или бронированием. В панели «Покрытие кода» отображается количество использованных и неиспользованных байтов в каждом ресурсе CSS и JavaScript.

Это доказательства для дальнейшего расследования, а не разрешение на удаление файла. Удаление кода плагина без понимания его зависимостей может привести к сбоям в работе фильтров или форм. Инструкции по записи см. в руководстве Chrome по анализу покрытия кода.

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

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

Используйте WebP или AVIF, если ваша система WordPress позволяет надежно создавать и передавать изображения в этом формате. Плагины, такие как Imagify и ShortPixel Image Optimizer, могут изменять размер, сжимать и создавать изображения в новых форматах. Выберите один рабочий процесс обработки изображений, сделайте резервные копии оригиналов и сравните визуальное качество перед запуском пакетной обработки.

Добавить точный width и height атрибуты, позволяющие браузеру зарезервировать место. Ленивая загрузка изображений и iframe под первым экраном. Не загружайте изображение LCP с отложенной загрузкой. Google Руководство LCP Рекомендуется сделать этот ресурс доступным из исходного HTML-кода и загрузить его на ранней стадии.

Отложить или исключить работу третьих лиц

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

Распространенные альтернативы включают в себя:

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

Если тема уже предоставляет необходимые шрифты, пользователи MEC могут ознакомиться с опцией « Отключить шрифты Google» , описанной в настройках внешнего вида MEC . После внесения изменений проверьте всю страницу, поскольку другая тема или плагин могут по-прежнему запрашивать тот же шрифт.

Проверьте исправление страницы события.

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

Как следует кэшировать страницы мероприятий, чтобы не нарушить процесс бронирования?

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

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

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

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

• WP Rocket: Кэширование страниц включается при активации плагина. Используйте Settings > WP Rocket > Advanced Rules для исключения URL-адресов. документация по кэшированию страниц поясняет, какие файлы кэша были сгенерированы.
• Кэш LiteSpeed: Используйте его для кэширования страниц, если на хостинге используется механизм кэширования LiteSpeed ​​или сайт использует QUIC.cloud. Перейдите по ссылке: LiteSpeed Cache > Cache > Cache и установить Включить кэш в ON, инструкция по установке поясняет требования к серверу.
• W3 Total Cache: открытый Performance > General Settings, включить Page Cacheи начните с метода хранения, поддерживаемого хостом. официальная страница плагина документирует его базовую конфигурацию.

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

Используйте эти границы в качестве отправной точки:

Запрос	Подход к кэшированию всей страницы	Что проверить
Архив публичных мероприятий	Обычно кэш	Изменение месяца, фильтры, пагинация, новые события
Публичная страница отдельного события	Обычно кэш, если обновления доступности выполняются корректно, очищается.	Дата, цена, наличие товара или вместимость, элементы управления бронированием
Отправка заявки на бронирование или регистрацию	Не следует отправлять статический ответ.	Проверка, предотвращение дубликатов, пропускная способность, подтверждение
Личный кабинет зарегистрированного участника	Исключать, если кэш не создает индивидуальные варианты для каждого пользователя.	Идентификационные данные, бронирования, счета-фактуры, личные данные
WooCommerce Корзина, оформление заказа и Мой аккаунт	Исключать	Содержимое корзины, сессии, оплата, подтверждение заказа

WooCommerce В нем прямо указано владельцам сайтов исключить разделы «Корзина», «Оформление заказа» и «Мой аккаунт», а также файлы cookie, идентифицирующие корзины и сессии. Следуйте текущим правилам. WooCommerce руководство по кэшу а также инструкции для выбранной системы кэширования.

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

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

Если общедоступная страница работает быстро, но её доступность устарела, правило очистки является неполным.

Как вы оцениваете раздутость баз данных и фоновую работу?

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

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

Проверьте перед удалением.

Начало в Tools > Site HealthWordPress предупреждает, когда автоматически загружаемые параметры становятся слишком большими. Автоматически загружаемые параметры — это настройки плагинов и тем, загружаемые при каждом запросе. Руководство по производительности WordPress Как правило, рекомендуется не превышать общий объем в 800 КБ.

Используйте Query Monitor, чтобы найти повторяющиеся или медленные запросы к базе данных на странице соответствующего события. Для запланированных задач WP Crontrol отображает события cron WordPress, их обработчики, время следующего запуска и периодичность повторения. Ищите импорты событий, которые выполняются чаще, чем необходимо, сбои заданий, которые повторяются, и перекрывающиеся задачи.

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

Удалите работу, принадлежащую известному владельцу.

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

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

Решите, поможет ли постоянное кэширование объектов.

Кэш объектов хранит результаты повторных чтений из базы данных, чтобы WordPress мог использовать их повторно в разных запросах. Redis — один из распространенных бэкендов. Он полезен, когда профилирование показывает повторные чтения параметров или запросов, а хостинг-провайдер предоставляет поддерживаемый сервис Redis.

Перед установкой коннектора Redis задайте хосту следующие вопросы:

• Включен ли и активирован ли для этого сайта Redis или другой сервис постоянного кэширования объектов?
• Какие плагины или дополнения для WordPress поддерживает хостинг?
• Как можно просмотреть коэффициент попаданий, использование памяти, вытеснения и ошибки подключения?
• Как правильно очистить кэш после развертывания или восстановления данных?

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

Как диагностировать медленную регистрацию и оформление заказа?

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

Откройте панель «Сеть» в DevTools, сохраните журнал, отправьте заявку на регистрацию теста и выполните фильтрацию по... Fetch/XHRВыберите медленный запрос и запишите его:

• Общая продолжительность и время ожидания на сервере.
• Статус HTTP и любые сообщения проверки.
• URL запроса и информация о том, был ли он обойдён кэш страницы.
• Повторные звонки в платежный шлюз, CRM-систему, службу электронной почты, налоговую службу или веб-хук.
• Повторные или дублирующиеся запросы.

Проверьте журналы сервера и приложения на одну и ту же временную метку. Медленный ответ при высокой загрузке PHP-воркера указывает на выполнение задач приложения в очереди. Быстрый ответ WordPress, за которым следует длительный внешний вызов, указывает на интеграцию.

Исправьте компонент, вызывающий задержку. Это может означать увеличение производительности PHP, исправление медленного запроса к базе данных, сокращение объема синхронной интеграции или обращение к внешнему поставщику.

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

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

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

Как подготовиться к резкому увеличению трафика во время запуска продажи билетов?

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

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

CDN и кэширование страниц могут обрабатывать тысячи посещений страницы мероприятия, в то время как PHP-процессы будут обрабатывать запросы на проверку доступности, отправку форм, блокировки базы данных, запросы на оплату и обращения к CRM. Протестируйте оба варианта.

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

Создайте сценарий, напоминающий запуск:

1. Большинство виртуальных посетителей открывают страницу мероприятия.
2. Некоторые изменяют вид календаря или проверяют наличие билетов.
3. Регистрация начинается с небольшой группы.
4. Меньшее количество посетителей отправляет заявки на бронирование или осуществляет пробные платежи.

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

Во время выполнения теста следите за этими сигналами:

• Процессор и оперативная память.
• Активные и поставленные в очередь PHP-обработчики.
• Затраты ЦП базы данных, количество подключений, медленные запросы и ожидание блокировок.
• Медианное и высокое процентильное время ответа на запросы на бронирование.
• Частота ошибок HTTP и таймауты.
• Неудачные, дублирующиеся или неполные бронирования.
• Количество одновременно использующих устройство пользователей и частота запросов.
• Коэффициент попадания в кэш для общедоступных страниц.
• Задержки и ошибки в платежных системах, CRM-системах и почтовых сервисах.

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

Дополнительное покрытие CDN не восстановит исчерпанный пул PHP-кода или заблокированную строку в базе данных.

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

Каков практический путь устранения неполадок?

Используйте симптом для выбора первого обследования:

• Весь сайт работает медленно: Проверьте время отклика (TTFB), графики ресурсов хоста, количество PHP-воркеров, активность базы данных, тему оформления и конфликты плагинов.
• Только календарь тянется медленно: Проверьте количество событий, диапазон дат, повторяемость, фильтры, запросы к базе данных, конфигурацию календаря и модули событий.
• Медленно работают только страницы с отдельными событиями: Проверьте элемент LCP, изображения главного экрана и выступающих, карты, галереи, видео, шрифты и сторонние скрипты.
• Страница работает быстро, но регистрация медленная: Отслеживайте AJAX-запросы, записи в базу данных, проверки доступности, обращения по электронной почте или в CRM-систему, а также загрузку сервера.
• Пока не начнутся продажи билетов, всё идёт быстро: Протестируйте некэшированную пропускную способность системы бронирования, количество PHP-воркеров, конкуренцию за доступ к базе данных, задержку платежей и коэффициент попадания в кэш при одновременном трафике.
• На общедоступной странице отображается информация о наличии товара в прошлом: Перед сокращением времени жизни каждого элемента кэша проверьте исключения из кэша и правила очистки.

Начните с этого. Измените одну причину и повторите соответствующий тест.

Как проверить, что исправление сработало?

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

Используйте базовый вариант, который вы сохранили в начале:

1. Повторите каждое URL-адресное сообщение три раза, используя одно и то же устройство, местоположение, состояние авторизации и состояние кэша.
2. Сравните медианные значения для соответствующего показателя или запроса. Не сравнивайте один удачный случай с одним неудачным.
3. Просматривайте календарь, применяйте фильтры и открывайте события.
4. Проверка корректности и некорректности регистрации.
5. Проверьте наличие билетов, цену, налоги, купоны и информацию о способах оплаты, если они используются.
6. Проверьте страницу подтверждения, запись о бронировании, электронные письма, данные CRM и веб-хуки.
7. Просмотрите ошибки сервера и журналы за тестовый период.
8. Отслеживайте данные с мест проведения работ после того, как накопится достаточное количество реальных посещений.

Сохраните четырехэтапный путь в плане мониторинга: Календарь -> Событие -> Регистрация -> Оформление заказа . Новые медиафайлы, импорт событий, теги отслеживания и обновления плагинов могут изменить один этап, не затрагивая другие.

Часто задаваемые вопросы

Измерьте ход события, а затем внесите одно изменение.

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

Календарь -> Событие -> Регистрация -> Оформление заказа

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