EvgenyMorozov

Как сделать сайт на 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. Это поможет понять, где узкие места.

Поставить роутер с авторизацией у входа, а второй роутер (который раздает wifi - я так понял?) перевести в режим "точка доступа".

Бери тут https://underscores.me/

Хотите проблем - ну делайте "модно-стильно-молодежно". Не хотите проблем - делайте кабелем. wifi был придуман для носимых устройств и оправдан там, где прокладка сети уже невозможна - в старых офисах, на арендуемых площадях, в исторических зданиях.
При проектировании сети всегда стоит закладывать на каждое место на одну розетку больше, чем было посчитано :) Узловые свитчи вязать оптикой. Серверную располагать так, чтобы "чужие здесь не ходят".

Вот смотри - у тебя хостинг. Он с вероятностью 10 раз в год может отвалиться (банально - перезагрузка).
Теперь у тебя еще есть стороннее облако. Оно с вероятностью в 10-ть раз в год может отвалиться (банально - перезагрузка).
Потом ты решил jquery с cdn грузить - эта либа с вероятностью в 10-ть раз в год может отвалиться.
Потом ты поставил метрику и пиксель - они с вероятностью в 10-ть раз в год (каждая) может отвалиться.
У тебя гугл рекапча - она в 2019-м блочилась роскомнадзором - в итоге сайт не совсем так работал.
У тебя комментарии ВК - но политиканы других стран (украина например) его заблочили. И ты можешь и не узнать оперативно об этом.
Ты поставил сторонний плагин (uLogin например) - он сливает твоих посетителей и зарабатывает на них загружая вредонос с третьей стороны к тебе на сайт. Как пример - он данные форм сливал.

Итог - разнося всё на разные решения ты лишь увеличиваешь шансы что конечный пользователь испытает проблемы с твоим сайтом. Ты не знаешь как политика разных стран все эти отдельные сущности будут блочить или когда у облака или cdn произойдет отказ. А это есть. Это бывает. В итоге ты лишь увеличиваешь варианты и шансы отказов. Тебе это надо?

Ну и ответ: всё храни у себя. Хороший хостинг все держит.

А как именно вы собираетесь кешировать в memcached, как его использовать? Как стандартный object cache? Fragment cache? Full page cache?

Из всех вариантов кеширования самым быстрым будет Nginx fastcgi_cache, поскольку он будет отдавать статические HTML-страницы прямиком с диска, а то и из памяти – даже не обращаясь к PHP-процессу, не поднимая WordPress и тем более не трогая базу. Но это полная статика, а значит не подойдет если у вас необходимость показывать динамические данные на странице (авторизованные пользователи с личными кабинетами, корзины покупателей и тд).

WP Super Cache по сути делает то же самое, но на уровне плагина - он генерирует статические HTML-страницы, и веб сервер конфигурируется чтобы отдавать их. Это тоже быстро, минусы плюс-минус те же, но как бонус есть возможность определенной настройки в админке и гибкости. Но это в экспертном режиме. Кроме него он может работать в cмешанных режимах где PHP все-таки задействован, не нужно менять конфиги сервера и при этом можно даже кешировать условно динамические страницы. Это огромное преимущество перед nginx fastcgi_cache, если сайту такая функциональность нужна.

Нужно ли иметь одновременно и nginx fastcgi_cache и wp super cache? Нет. Выберите одно из двух. Если сайт может полностью жить в статике - nginx fastcgi_cache настроили и забыли. Если логика статики и динамики чуток посложнее - WP Super Cache.

Независимо от первых 2х вариантов, можно использовать кеширующий бекенд (memcached, redis) для кеширования фрагментов, объектного кеша и любых других данных. Полезно для кеширования .mo файлов переводов, отрендеренных ресурсоемких фрагментов (меню, блоки/виджеты с калькуляциями и тд), стандартного объектного кеша WP и тд. Это второй, внутренний уровень кеширования и важен как раз для динамических запросов, которые не используют full page cache от Nginx / WP Super Cache.

Этот файл пережиток MS-DOS, там в нем хранились первоначальные настройки ОС. Современной винде он не нужен уже давно. Когда еще была DOS подсисетма в винде был аналог config.sys. Сейчас уже и DOS программы на винде не запустить, а значит и необходимости в файле нет.

Давайте для начала определим вашу роль и ваши цели.

Если ваша роль - разработчик, то must-have плагинами будут те, которые облегчат вашу работу - Advanced Custom Fields (желательно Pro), Query Monitor, Laps и тд, или же малой кровью решать типовые задачи - Classic Editor, Disable Comments, Safe SVG, Enable Media Replace и подобные. Под "малой кровью" имеется в виду что они имеют минимальный overhead, не делают ничего лишнего и вы сами лучше все равно не напишете. Все остальное пишем сами, форкаем у других разработчиков, тюним под свои задачи и тд - со временем накапливаем собственный инструментарий.

Если ваша роль - имплементатор (собираете сайтики на WP, но в PHP не умеете), то набор плагинов будет другим. Тут уж коллеги-имплементаторы подскажут какие плагины важны, какие нужны.

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

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

Теперь по целям. Чего вы хотите? Чтобы можно было быстро собрать сайт для тестирования бизнес идеи с минимальными расходами? Это одна кухня. Чтобы был легкий и быстрый контент-сайт, который выдерживает серьезный трафик? Это другая кухня. Интернет-магазин? Вообще другое. А в какой нише этот интернет-магазин? Физические товары или цифровые? А рынок местный или международный? Это все будет вас приводить к разному набору плагинов. Думаю, смысл уже понятен.

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

- В robots.txt запрещаем индексацию
- Добавляем в шапку noindex
- Отключаем карту сайта
- Закрываем доступ для неавторизованных посетителей, чтобы только админы и редактора могли ходить по сайту, для всех остальных одна страница-заглушка "coming soon"
- Когда сайт готов к публикации - открываем карту сайта, разрешаем индексирование, подключаемся к Google / Yandex Webmaster Tools, сабмиттим сайт в очередь на индексацию.

Открыл вопрос и из монитора хлынул поток воды, так что сразу к вопросам:

Какое оборудование (модели) ставить на уровень доступа, распределения?

Да Микроты ставьте, если прокачаться хотите. В качестве свитчей - HP, например. Можно и D-Link, не слушайте диванных кукаретиков.

Как делать - 4 коммутатора на все устройства (в шкафу), или же по одному на этажах и центральный в серверную?

Всё в шкаф, чтоб потом не бегать по этажам и не искать причину поломки.

Как нарезать vlan? По этажам? По кабинетах?

По кабинетам геморройно, я бы вообще ничего не делал, сеть-то маленькая.

Так и не знаю делать ли интернет розетки или нет)

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

А, да, и AD бы всё-таки настроить и DNS с DHCP на Windows Server зарулить.