zver - наш воображаемый пользователь-зверь.

1. Какой пользователь в какое время заходил?

- last - история входов.
- last zver - история входов зверя.
- lastb zver - история неудачных входов зверя.
- last zver | grep "Jan 21" - история входов зверя за 21 января сего года.
- last -s -7days zver - история входов зверя за последние 7 дней.
- last -s 2025-01-15 -t 2025-01-21 zver - история входов зверя за 15-21 января 2025 года.

2. Действия того или иного пользователя?

- cat /home/zver/.bash_history - история команд зверя.
- who -u - показывает активных пользователей (терминалы и время входа).
- ps -u zver - показывает список активных процессов зверя.
- sudo iotop -u zver - мониторинг ввода вывода пользователя зверя (в режиме реального времени).
- sudo iftop -f "src user zver" - показывает сетевой трафик зверя.
- sudo tail -f /var/log/syslog | grep zver - просмотр действий зверя в реальном времени.
- sudo journalctl -f | grep zver - отслеживание действий зверя в реальном времени (если используется systemd).
- sudo lsof -u zver - какие файлы открыты у зверя.
- find /home/zver -type f -mmin -60 - какие файлы изменил зверь за последний час.
- stat /home/zver/nomera-devchonok.txt - показывает подробности что делал зверь с файлом стратегического назначения.

3. Если пользователь пользовался sudo -i, sudo -s, sudo su, как посмотреть, что он делал под этими оболочками?

- sudo grep zver /var/log/auth.log - история команд (втч. под sudo) зверя.
- sudo zgrep zver /var/log/auth.log* - просмотр истории команд зверя из текущих и архивных логгов.
- sudo aureport -x --summary - показывает сводку команд (втч. под sudo).

Расширенный мониторинг зверей - auditd и еще.

- Разница 1: Почти, sudo -i также меняет HOME на /root, и читает логин скрипты root юзера.
- Разница 2: Верно, действия с sudo -i и sudo -s логгируются в журналах юзера, а sudo su - нет.
- Разница 3: Верно, sudo позволяет настраивать ограничения для команд через sudo -i и sudo -s, но не для sudo su (так как sudo su переключает юзера в root).

Еще не понял разницу между
sudo su
sudo su -

- sudo su - переключает юзера на root, но окружение при этом не является полным root окружением.
- sudo su - - эмулирует полный вход юзера root (login shell). Будут прочитаны все файлы конфигурации, которые обычно читаются при входе root (profile, .bash_profile, .bashrc и что-то там еще). Насколько я понимаю, это то, что нужно Вам при работе от имени юзера root.

И где можно смотреть логи пользаков при использовании sudo -i, sudo -s?

Viewing and monitoring log files, можно еще заюзать journalctl.

Короткий ответ (с учетом указанного ТЗ) - WP.

Длинный ответ:

публиковать страницы, создавать иерархию страниц, чпу url, какой то слайдер с картинками

Учитывая типовое ТЗ, ответ - WP (все это уже реализовано, преимущественно бесплатно и в большом количестве).

небольшое количество услуги в регионе

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

Нашли компанию, предлагает разработку сайта на WP или на Python+Django (дороже и дольше)

Начнем с того, что это не равнозначные инструмент, ибо WP - это готовый движок/CMS для сайта + сам сайт (готовые шаблоны), развернул на хостинге и готово. А вот Django - это фреймворк, т.е. некий набор инструментов, да он позволяет сделать из него что угодно (ах*енно сделать (на правах отвечающего)), но потом. Соответственно, если вопроса в функционале и производительности не стоит (и предположу - сделать быстро) - выбираем WP, будет дешевле и быстрее.

Что обычно я использую (от начального проекта к финальному):
1. WP в стоке + сборка фронта (webpack) с оптимизацией + кэширование.
2. Докупка железа и горизонтальное масштабирование п1 балансировщиком.
3. Профилирование и переписывание определенных запросов под конкретные задачи в самом WP, обычно добавляет производительности в 2-3 раза (от wp там мало что остается, но ценник и сроки еще не такие, как в п4).
4. Python + Django + кэширование (если нужно быстрее любого WP и более специфический функционал).
5. П4 + FastAPI (если прям совсем прижало по производительности).

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