You never heard of a profiler? Logging? You're going about this all wrong.
When fixing performance problems you shouldn't guess, just profile it to find the bottlenecks.
I've seen plenty of performance 'fixes' that weren't, pure guesses by developers that did nothing, when a quick profile immediately revealed the culprit.
In your case you also need to figure out if it's happening server-side or client-side. I generally start with the server-side logs, get a few days/weeks worth of data, find average page request times, plus how much deviation on those requests, then go from there. That gets you the server-side. For client-side, unfortunately it's a lot harder. Google analytics page load speed, for example, is a pile of crap. But, again, there's a profiler in dev tools, remember js compile time is a significant thing and can slow load time too so check that out as well as the actual run times (js compile time shows in the page load graph).
Good points about using good tools & analysis techniques - especially to get to latent sources of slowness.
But I'm not sure you can say that he's not profiling - he's using the end users' direct experience as the profiling tool, prioritizing the fixes by greatest annoyance.
Since he let himself get in the mode of being reactive, that's not a bad way out of the hole he dug himself.
Of course the best way is to design your architecture for speed, minimize all code usage & data transfer, use the profiling tools before release candidate status, and prioritizing speed & performance in the QA process.
profiling is not a replacement for user feedback. You could profile some server side functions and see that X is 5 ms and Y is 8 ms. You will think all good, they're pretty fast. But the user might complain about a feature being slow, say deleting a thread, which happens to call the 5 ms function 50 times for some reason. You would then address the reason for so many calls, rather than optimizing the call itself.
Talking to your users is paramount, at the very least they will indicate where you have to add profiling
When fixing performance problems you shouldn't guess, just profile it to find the bottlenecks.
I've seen plenty of performance 'fixes' that weren't, pure guesses by developers that did nothing, when a quick profile immediately revealed the culprit.
In your case you also need to figure out if it's happening server-side or client-side. I generally start with the server-side logs, get a few days/weeks worth of data, find average page request times, plus how much deviation on those requests, then go from there. That gets you the server-side. For client-side, unfortunately it's a lot harder. Google analytics page load speed, for example, is a pile of crap. But, again, there's a profiler in dev tools, remember js compile time is a significant thing and can slow load time too so check that out as well as the actual run times (js compile time shows in the page load graph).