Да, вполне разумно настроить сайт в новой среде, где вы могли бы запустить профилировщик производительности и другие инструменты.

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

Теоретически это можно сделать, но по моему опыту никто никогда так не делает по двум причинам:

1. Это кошмар для настройки и обслуживания. Просто проще (и точнее) сделать это в продакшене, поэтому существуют легкие инструменты профилирования, такие как XHProf. В отличие от Xdebug, эти профилировщики предназначены для работы в производственной среде, по запросу или с определенной частотой дискретизации. New Relic также является хорошим вариантом, если вы можете себе это позволить.
2. В среде общего хостинга ваш сайт работает вместе с сотнями, а то и тысячами приложений, подобных вашему, каждое из которых потребляет ресурсы ЦП, дискового ввода-вывода, сети и памяти. Хотя некоторые общие хосты могут сообщать вам, что потребляет ваше приложение, было бы немного странно, если бы они также сообщали вам, что делают другие приложения 🙂

Я занимаюсь профилированием приложений WordPress уже около десяти лет, и вот что вам нужно знать: 99% проблем с производительностью кроются в коде приложения. Не в конфигурации сервера, не в дисковом ио или объеме оперативной памяти, не в перенасыщенной сети. Но в коде приложения.

Независимо от среды, если приложение выполняет:

add_action( 'init', function() {
    wp_remote_get( 'https://some-third-party-service.org/api/version-check/' );
} );

И если этому стороннему сервису требуется 1 секунда для ответа, то каждая загрузка страницы на вашем сайте WordPress будет платить штраф в 1 секунду. Каждый. Одинокий. Время. В Windows, в Linux, в MacOS. С 1G RAM или 32G RAM. С SSD-диском или старым вращающимся магнитным диском.

Могли ли вы обнаружить проблему с запуском профилировщика на локальном компьютере? Конечно, вы могли бы:

Yes, naive code such as this can easily be spotted with PHP-level tools, like Query Monitor and the Debug Bar family, right there in production, even on a shared host. But if they don’t reveal the problem, then it’s perfectly fine to get a full copy of your production site, run it locally or some cheap VPS, in an environment where real profiling tools are available.