Yes, it is perfectly reasonable to set up the site in a new environment where you could actually run a performance profiler and other tools.
As mentioned throughout the comments here, yes for the best results you'll need an environment that looks very much like what's running in production. And to get even better results, you'll need to mimic the ongoing traffic, CPU/disk/network usage that's happening on the production server, while profiling.
In theory this can be done, but in my experience nobody really ever does that for two reasons:
- It's a nightmare to configure and maintain. It's just easier (and more accurate) to do it in production, which is why lightweight profiling tools, such as XHProf exist. Unlike Xdebug, these profilers are designed to run in production, on-demand or at a specific sample-rate. New Relic is also a good option if you can afford it.
- In a shared hosting environment, your site is running alongside hundreds, maybe thousands of applications similar to yours, each consuming CPU, disk IO, network and memory. While some shared hosts might tell you what your application is consuming, it would be a bit weird if they told you what the other applications are doing as well :)
I've been profiling WordPress applications for about a decade now, and here's what you need to know: 99% of the performance problems are in the application code. Not in the server configuration, not in the disk io or amount of RAM, not in an over-saturated network. But in the application code.
Regardless of the environment, if the application is doing:
add_action( 'init', function() {
wp_remote_get( 'https://some-third-party-service.org/api/version-check/' );
} );
And if that third-party service takes 1 second to respond, then every page load on your WordPress site will pay the 1 second penalty. Every. Single. Time. On Windows, on Linux, on macOS. With 1G of RAM or 32G of RAM. With an SSD disk or an old spinning magnetic disk.
Could you have spotted the problem running a profiler on your local computer? Of course you could:
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.