То, что получилось не из-за cache control, а из за expires.

Ни удалять, ни добавлять этот заголовок не надо.

Ну и отлично, всё получилось - у вас остались там только внешние ресурсы(usocial и яндекс метрика), на expires которых вы не можете повлиять, если только отключить их, если они не нужны.

Добавьте там же ещё вот такой блок:

Просто бездумное выращивание pagespeed бесполезно.

В вашем случае, вероятнее всего, nginx является reverse proxy, и все запросы без изменений передаёт apache. Скорее всего никакого доступа к конфигу nginx у вас нет, да и не нужен он вам.

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

У вас на статику сейчас expires 14 дней, что по мнению PSI очень мало, но вообще, заголовки есть.
Что именно у вас сейчас прописано в .htaccess касаемо Expires?

Меня позвали потому, что я разбераюсь в этом вопросе.
Правда, чтобы вам помочь, надо либо знать ваш домен, либо посмотреть на скрин из PSI, чтобы понять, что именно у вас не кешируется.

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

Feed import разве умеет работать с пользователями?

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

Кстати, по серверам стоит смотреть на AMD Epyc тогда уж.

Начать стоит с того, что бекапить нужно куда-нибудь на удалённый сервер, лучше в другом ДЦ. В случае мелкого сайта, это может быть какое-нибудь облачное файлохранилище, даже бесплатное, или домашний NAS...

Даже если это какой-то мелкий сайтик, система хранения на которой он лежит может помереть, или хостер, или в ДЦ что-то случиться.

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

Оно так, но далеко не всегда это даёт возможность процессору получить данные в 10 раз быстрее, даже если они в кеше. Так что даже если бы вся память, предположим, помещалась бы в этот кеш, и задача была бы перемешивать данные в памяти, то всё равно был бы прирост заметно меньше 10 раз. А задачи, всё же, обычно больше вычислительные.

Там падение зависит от типов нагрузки и может быть довольно большим на практике. Не 300% конечно, но это же один из факторов. 30 тут, 20 на частоте, что-то на памяти что-то на настройках, что-то за счёт архитектуры и шин, вот и набегает... У новых зеонов пока не решены проблемы для которых заплатки, там тоже есть заметное падение производительности, на райзенах с этим куда лучше.

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

borovinskiy wrote:

В большой кеш может залезть движок PHP Zend, что может дать серьезное ускорение.

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

От объёма кеша процессора, тем более L3, на одной и той же архитектуре процессора, при малой конкуретности разница в производительности единицы процентов, на самом деле.

Есть отличная статья с обзором методик и софта для бекапа на Хабре: https://habr.com/ru/company/southbridge/blog/449282/ точно намного более толковое, чем то, что могут написать на хакер ру.

Я настраивал последний раз менее недели назад. Всё как и было.

IIS плохой выбор для всего кроме, ASP.NET приложений.

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

Ну и, на самом деле, вам совершенно не обязательно отправлять почту через яндекс даже если он используется в вашей организации. Можно и через почтовик на вашем сервере, если всё правильно настроить(dkim spf и.т.п.).

Надо посмотреть на этот архив. Возможно, где-то в нём завалялся и дамп базы, возможно не свежий, но хоть какой-то - так не редко бывает. Так не глядя вам никто ничего определённого сказать не сможет.

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

Лучше уж куда-нибудь за cloudflare спрятаться, чем себе такое ставить... Там есть waf, и в нём правила для Drupal.

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

Ей сто лет в обед и появилась она в Solaris. Потом была портирована во FreeBSD, и затем в Линукс, и даже это было довольно давно.

Ну и не то, чтобы это так уж тренд, к тому же, она не такая уж быстрая, и очень охоча до памяти.