Многоязычная производительность WordPress: 7 способов быстро перевести сайт

Подведите итог этому посту следующим образом: 9 мин чтения

ЧатGPT Недоумение Грок Google ИИ

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

Ключевые выводы

• Измеряйте каждый язык отдельно. Пороговые значения Google “хорошие”: LCP в пределах 2,5 с, INP менее 200 мс и CLS менее 0,1 при 75-м процентиле загрузок страниц.
• URL-адреса, специфичные для языка (/de/, /fr/) можно кэшировать, как и любую другую страницу. Язык, выбранный файлом cookie, обычно не может.
• Очищайте кэш страниц для переведенных страниц при изменении переводов, иначе посетители увидят устаревший текст.
• Разделить веб-шрифты по сценарию с помощью unicode-range, поэтому немецкий посетитель не скачивает японские глифы.
• Избегайте автоматических языковых перенаправлений при каждом посещении; каждое перенаправление представляет собой дополнительный цикл до того, как что-либо отобразится.

Почему многоязычные сайты WordPress замедляются

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

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

У каждого есть простое решение.

Шаг 1: измерение по каждому языку

Google рекомендует достичь хороших показателей Core Web Vitals, что, по его словам, “соответствует тому, что наши основные системы ранжирования стремятся вознаградить” (Центр поиска Google). Цели:

Web.dev рекомендует оценивать их по 75-му процентилю загрузок страниц, разделенному на мобильные устройства и настольные компьютеры (веб.dev).

Как измерить по языкам:

• Запустите PageSpeed Insights на одной странице на каждом языке (/pricing/, /de/pricing/, /ja/pricing/). Различия напрямую указывают на проблемы, характерные для конкретного языка, такие как шрифты или длинный текст, вызывающие изменения макета.
• В отчете Core Web Vitals консоли поиска откройте примеры URL-адресов в каждой группе проблем и обратите внимание, какие языковые папки появляются.
• Тестирование в регионах, которые вы обслуживаете. Сайт, размещенный в США, будет иметь более высокую задержку для посетителей из Азии, независимо от языка.

Шаг 2: дайте каждому языку свой собственный кэшируемый URL-адрес

Кэширование страниц — это самая большая победа. В руководстве WordPress Advanced Administration говорится, что плагины кэширования обслуживают страницы как статические файлы и “могут повысить производительность в несколько сотен раз для довольно статичных страниц” (Ресурсы для разработчиков WordPress).

Это работает только в том случае, если каждый язык имеет отдельный URL-адрес. Когда язык выбирается файлом cookie или настройками браузера и обслуживается по одному и тому же URL-адресу, кэш страниц либо хранит один язык для всех, либо его необходимо обойти. Google также предпочитает отдельные URL-адреса для SEO: он рекомендует “разные URL-адреса для каждой языковой версии страницы вместо использования файлов cookie или настроек браузера” (Центр поиска Google).

Контрольный список для вашего плагина кэширования:

• Кэшировать страницы в /de/, /fr/ и так далее, и проверьте, нет ли никого в списке исключений.
• Если плагин может предварительно загрузить кэш, включите переведенные URL-адреса; предварительную загрузку из карты сайта проще всего выполнить, если они перечислены в карте сайта.
• Не изменяйте кэш с помощью языкового cookie-файла, если у вас нет другого выбора.
• Очищайте переведенный URL-адрес при изменении его перевода, а не только при редактировании исходного сообщения.

Шаг 3: обслуживайте переведенный HTML, а не текст, замененный после загрузки

То, как ваш инструмент перевода создает переведенную страницу, имеет такое же значение, как и кэширование.

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

В WordPress отдавайте предпочтение серверному методу для ваших основных языков. Если клиентский скрипт — ваш единственный вариант для части сайта, зарезервируйте место для растущего текста (особенно кнопок и меню) и протестируйте CLS на каждом языке.

Шаг 4: разделение шрифтов по скрипту

Латинские шрифты небольшие; полные шрифты CJK (китайский, японский, корейский) могут быть во много раз больше. Загрузка каждого скрипта на каждую страницу приводит к потере пропускной способности.

Используйте @font-face unicode-range дескриптор. MDN объясняет, что если страница не использует ни одного символа в диапазоне, “шрифт не загружается”, и что дескриптор существует, поэтому сайт “со множеством локализаций” может предоставлять отдельные ресурсы шрифтов для каждого скрипта (МДН).

@font-face {
  font-family: 'Brand Sans';
  src: url('/fonts/brand-latin.woff2') format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153;
  font-display: swap;
}
@font-face {
  font-family: 'Brand Sans';
  src: url('/fonts/brand-arabic.woff2') format('woff2');
  unicode-range: U+0600-06FF;
  font-display: swap;
}

Также:

• Самостоятельно размещайте файлы WOFF2 и предварительно загружайте только файл Latin (или main-script), используемый над сгибом.
• Подумайте об использовании хорошего системного шрифта для сценариев, которые не охватывает ваш фирменный шрифт, вместо большого веб-шрифта.
• Использовать font-display: swap поэтому текст отображается сразу же в резервном шрифте.

Шаг 5: сохраняйте изображения и сценарии простыми на каждом языке

• Локализованные изображения. Если заменить изображения на каждом языке, сжать и изменить размер каждой версии, как у оригинала, то можно легко загрузить неоптимизированный баннер размером 4 МБ для одного рынка.
• Ленивая загрузка. WordPress добавляет loading="lazy" к изображениям по умолчанию; убедитесь, что изображение героя не загружается в режиме отложенной загрузки в каждом языковом шаблоне.
• Сторонние скрипты. Виджеты чата, платежные значки и трекеры, специфичные для рынка, накапливаются. Загружайте их только на тех языках или страницах, где они необходимы.

Шаг 6: избегайте ненужных перенаправлений

Автоматические перенаправления на основе языка браузера добавляют поездку туда и обратно перед первым байтом правой страницы. Google также не рекомендует перенаправлять пользователей на языковую версию “в зависимости от того, какой, по вашему мнению, язык пользователя”, поскольку это может помешать пользователям и поисковым системам получить доступ ко всем версиям (Центр поиска Google).

Лучшие варианты:

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

Шаг 7: получите основы прямо на сервере

Переведенные страницы не меняют основ. В руководстве WordPress в качестве основных рычагов указаны кэширование, CDN для статических файлов и настройка сервера:

• Поддерживайте актуальность PHP и включен OPcache.
• Добавить постоянный кэш объектов (Redis или Memcached), если ваш хостинг поддерживает его, особенно для WooCommerce или сайтов с членством, где полностраничное кэширование ограничено.
• Используйте CDN для изображений — CSS и JS, а для полных страниц — если позволяет ваша настройка, чтобы посетители, находящиеся далеко от вашего сервера, могли получить их поблизости.
• Список плагинов должен быть коротким. Каждый активный плагин запускается для каждого некэшированного запроса на каждом языке.

Как подходит плагин WordPress ConveyThis

Плагин ConveyThis переводит страницы на сервере и обслуживает каждый язык в своей подпапке или поддомене, поэтому переведенные страницы можно кэшировать, как оригинал. Он хранит локальный кэш переводов для каждой страницы и языка, поэтому повторные запросы не ждут службы перевода, а при изменении перевода он очищает кэш страниц в популярных плагинах кэширования, таких как WP Rocket, W3 Total Cache, WP Super Cache и WP Fastest Cache.

Другие настройки, которые стоит знать:

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

The Страница интеграции WordPress охватывает установку и настройки, а также планы и цены перечисляет ограничения по количеству слов и языков для каждого плана. Для перевода самих строк темы см. наше руководство по перевод темы WordPress.

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

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

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

Следует ли кэшировать переведенные страницы отдельно?

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

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

Запустите PageSpeed Insights на одной странице на каждом языке, сравните и проверьте, какие языковые папки отображаются в отчете Core Web Vitals консоли поиска. Стремитесь к LCP в течение 2,5 секунд, INP менее 200 миллисекунд и CLS менее 0,1.

Являются ли подкаталоги или поддомены более быстрыми для многоязычного сайта?

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

Как остановить большие шрифты, замедляющие перевод страниц?

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

Сохраняйте его быстрым по мере роста

Скорость и качество перевода зависят от того, как создаются переведенные страницы. Ты можешь создать учетную запись ConveyThis, установите плагин WordPress и сравните переведенные страницы с оригиналами.