Sanvi

Как сделать сайт на WordPress с высокой производительностью?

Вначале необходимо определить, что такое "высокая производительность". Обычно, под производительностью сервера (WP сайт это как раз тот самый сервер) подразумевается показатель RPS (Requests Per Second) - максимальное количество запросов к серверу в секунду. Именно максимальное, т.е. в какой то "час-пик". Предположим, что сайты на WP обычно используют небольшие, ну максимум средние компании, с соответствующим ожиданием по нагрузке в своем сегменте.

Возьмем голую тему без плагинов, которая выводит 10 изображений, с подключением 5 статических файлов (css/js), итого около 20 запросов от одного не кэшированного визита посетителя. Если на наш сайт зайдут 5 посетителей в секунду, они сгенерируют 100 RPS (5 * 20). Может показаться, что 5 визитов в секунду - это мало, но в минуту это будет уже 300 визитов, а в час 18000 визитов, что как бы дохрена, для малого-среднего бизнеса. Повторюсь, речь идет про "час-пик", т.к. нагрузка в другой промежуток времени нас не интересует.

По моим наблюдениям, WP без проблем выдерживает 50-100 RPS на нормальном хостинге с начальным тарифом без кэширования.

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

Я придерживаюсь следующего плана оптимизации WP сайта, от простого к сложному:
1. Кэширование плагином - самое быстрое и относительно дешевое решение, гуглить WordPress caching plugins. Обычно, вместе с такими плагинами идет опция с оптимизацией изображения до .webp или .avif формата и оптимизацией css/js файлов, если же нет, то это должен быть следующим пунктом оптимизации. Например, для W3 Total Cache имеются плагины Smush и ShortPixel.
2. Хостинг - арендовать более производительный shared-хостинг и подключить CDN.
3. VDS/DS хостинг - переезд на производительный VDS/DS хостинг, настройка обратного прокси Nginx и перекладка на его плечи задачи кэширования. Иногда получается сделать так, что до WP вообще не доходит запросов, все отрабатывает Nginx (это идеальный сценарий, но не всегда выполнимый). Здесь можно снять несколько сотен-тысяч RPS, что уже очень прилично, для такого уровня сайтов.
4. Больше серверов - докупка VDS/DS серверов с балансировкой, либо руками, либо средствами хостера. Здесь можно снять ЕЩЕ несколько сотен-тысяч RPS дополнительно к п3. Обычно, такая производительность нужна каким то интернет-каталогам/магазинам.

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

Ну и как уже сказали другие, elementor противоречит слову "производительность", хотя и его наличие можно на время закидать кэшированием-серверами-деньгами.

Рекомендую почитать:
WordPress Developer Resources - Optimization
The Ultimate Guide to Boost WordPress Speed & Perf...
Page Speed Optimization for WordPress

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

Отслеживать производительность можно плагинами New Relic и Query Monitor, а тестировать нагрузку Load Impact и Apache Benchmark. Это поможет понять, где узкие места.

Обратил внимание, что последние пару лет все чаще слышу про fastapi, насколько он уже созрел на рынке? "Слышать" это одно (субъективщина, хайп и все такие), может есть какие-то метрики, как определять востребованность конкретной технологии относительно другой, например django и fastapi

Я придерживаюсь 2х критериев для ЯП, которые используются в малых-средний проектах, это сайт с поиском работы (hh), и фриланс площадки. Вот инфа по hh на 10.03.2025:

Без взаимоисключений:
- Django: 184 вакансии.
- FastAPI: 172 вакансии.

Взаимоисключающие django и fastapi:
- Django: 100 вакансий.
- FastAPI: 89 вакансий.

Всего пару лет назад FastAPI составлял 30% от django, сейчас же они сравнялись (тенденция на лицо), на фрилансе FastAPI так же часто мелькает, а учитывая, что это относительно django новая технология, то на него обязательно стоит обратить внимание, т.к. вполне вероятно, что его рост на рынке продолжится.

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

Переезд на зарубежные сервера чреват потерей позиций сайта (тестировала, так и случилось).

От смены сервера позиции не проседают, что то другое повлияло.

Какой SEO-плагин поставить для для Wordpress в 2025м?

Тот же, что и в 24 году - Yoast SEO или All in One SEO Pack.

Все зависит от организации работы в конкретной конторе и конкретного разработчика, но лично у меня работает следующий подход:
1. Пишем начальное тз, минимальный необходимый перечень.
2. Говнокодим на основание п1 по принципу - "сделать быстро и чтобы работало по тз".
3. Пушим п2 в гит и разворачиваем сайт (или компонент на сайте).
4. Записываем фидбэк о компоненте, что не работает, как хотелось бы чтобы работало итп. Если это не критические замечания (безопасность или что то основное не работает), то откладываем изменения на месяц, квартал или год.
5. При накопление критической массы замечаний в п4 (ну или у Вас просто не осталось задач на настоящий момент) - добавляем рефакторинг п3 в очередь задач.
6. Повторяем 3-6 пункты до бесконечности.

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

Важное уточнение!

Схема с минимальным ТЗ и говнокодом работает лишь с теми заказчиками, которым Вы подробно разъяснили, почему сроки и стоимость ниже, почему за каждую "хотелку" не указанную в тз придется доплачивать, и почему необходим рефакторинг.

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

только так:

<div class="items__item">Длинное&nbsp;описание&nbsp;на 11111111</div>

.items {
  width: min-content;
}

Возможно ли это?

Оо, это Вы по адресу, чего изволите?
- Обычная статика без шаблонизатора.
- Статика с шаблонизатором.
- Статика с шаблонизатором и внедрением react.
- React фронт без api.

Как мне это сделать я очень сильно запутался и ничего не понимаю. Возможно ли это?

Возможно, необходимо:
1. Собрать статику.
2. Перебить пути до изображений (если используется шаблонизатор).
3. Срезать шапку и подвал у каждого html из п1.
4. Конвертировать п1 и п3 в php файлы.
5. Врезать wp/php код из п4.
6. Врезать wp/php код с метатегами в header.php.
7. (опционально) встряхнуть (tree-shaking) css и js файлы, вырезав весь не используемый код.
8. (опционально) произвести оптимизацию статики, не только вес, но и размер изображений под разные размеры дисплеев устройств.

Мне хочется посадить сайт созданный с помощью webpack

Webpack не создаёт сайт, а собирает.

Эта тема очень обширна, нужен более точный вопрос.

1. При переходе на https://easyvisavdk.ru/stranica-vizy/ - выдает пустую страницу, но с кодом 200.
2. При переходе на https://easyvisavdk.ru/stranica-vizy/?postID=1238:
2.1. Вначале сервер отдает страницу "Процесс оформления визы в Германию" (да да, мы загружали Мексику).
2.2. Затем, происходит динамическая замена контента на Мексику. Для этого, в п2.1. предусмотрен div#usa_visa, который заменяется контентом в скрипте https://easyvisavdk.ru/wp-content/themes/visa-lend... на 189 строке. Данные запрашиваются из API WP по адресу https://easyvisainc.ru/wp-json/wp/v2/posts/1238.

Т.к. не видно самих постов в админке, то предположу один из вариантов:
- Используется всего 1 страница со слагом stranica-vizy, где с помощью ACF полей созданы данные под каждую страну, которые потом динамически заменяют основной контент страницы.
- Используется какой то CPT (Custom Post Types) со своими записями, тогда надо искать плагин, который взаимодействует с такими записями.
- Данные зашиты в файлы, без возможности изменения из админки.

P.S. SEO будет хромать!

P.P.S. Точно нужно писать в консоль все данные о записи?

Привет.
Тебе нужно их выводить через the_tags()
Ну а далее стилизовать так, как в макете

get_post()

Попробуйте так:

add_filter('document_title_parts', 'test', 10, 1);

function test($title) {
    if (is_single()) {
        $categories = get_the_category();
        if (!empty($categories)) {
            $title['title'] .= ' — ' . $categories[0]->name;
        }
    } elseif (is_category()) {
        $title['title'] = single_cat_title('', false);
    }

    return $title;
}

Всего пока 4 сайта, на разных CMS (Wordpress, Joomla).

1. С чего нужно начинать, чтобы подготовить сайт(ы) к переезду?

Любой хостинг (shared с поддержкой MySQL и PHP) или VDS/DS.

2. Что нужно подготовить на новом пустом сервере?

Что такое "пустой сервер"? Если это VDS/DS, то гуглим, если это shared хостинг, то "создать сайты" (так обычно называется манипуляция у хостера, которая регистрирует место для расположения файлов для сайта) и MySQL БД для сайтов.

3. Нужен ли для каждого сайта (их четыре) свой виртуальный сервер (VM)?

Не нужен.

Или как эти сайты вообще размещать чтобы в случае чего они не упали все вместе?

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

5. ... какие советы дадите

Задавать более конкретные вопросы.