Denis Ryabov

Там, видимо, страница генерируется по разному в зависимости от устройства (я вижу разницу в наличии класса col-3cm у тега body в оптимизированной и неоптимизированной версиях), и скорее всего закэшировалась «не та» версия. Тут в зависмости от того, как определяется тип устройства, сработает или включение опции Avoids enormous network payloads -> Remove IE Conditionals в Advanced настройках (это такой трюк, который делает кэширование зависящим от типа устройства), или отключение Initial server response time was short -> Caching.

Там суть в том, что «Optimize integrations» воспринимает атрибуты async и defer как указание на то, что данные скрипты можно загрузить уже после отрисовки страницы. К сожалению, в случае defer это не совсем так, т.к. такие скрипты должны быть выполнены до события DOMContentLoaded, а не после. Нужно будет в следующей версии или убрать проверку атрибута defer, или переопределить метод addEventListener у document и window, чтобы правильно вызывать DOMContentLoaded у новых скриптов (сложно, но можно).

В PageSpeed Ninja вроде бы все ошибки ловятся через try/catch, и если что-то не так, то возвращается исходная неоптимизированная страница. В файле error_log точно нет каких-нибудь записей с упоминанием psn-pagespeed-ninja? Можете попробовать включить логирование ошибок в самом PageSpeed Ninja (там будут все ошибки, даже уровня Notice, со стеком вызовов), только не забудьте потом выключить логирование, т.к. файл ошибок может сильно разрастись.

PageSpeed Ninja на админку никак не должен влиять, скорее всего нужно искать конфликт с каким-то другим плагином (возможно, кэширующим или другим оптимизирующим). На всякий случай проверьте wp-content/advanced-cache.php — если было включено кэширование в PageSpeed Ninja (а на максимальных настройках скорее всего было), а плагин был удален некорректно, то там могут оставаться следы. Хотя обычно проблемы с advanced-cache.php приводят к белому экрану на фронте, а не к проблемам в админке, я не знаю, что еще можно проверить.