Everywhere at once is the machine talking, and the machine has four voices worth hearing in order: power, memory, disk, then the settings nobody changed since install.
Power first because it is the fastest check with the most embarrassing payoff: Windows power plan on Balanced throttles CPU frequency on database servers constantly, powercfg /getactivescheme tells you in one command and High performance fixes it in another. VM guests add the hypervisor version of the same question, CPU ready time and noisy neighbors visible from the host side, worth one conversation with whoever runs the platform.
Memory speaks through Page Life Expectancy and its friends: perfmon's SQL Server Buffer Manager counters, a PLE persistently low for your RAM size with Lazy writes per second staying busy means the buffer pool churns, either the instance deserves more memory or max server memory sits misconfigured, the setting check being sp_configure max server memory against what the box actually has, leaving the OS its few GB. The classic misconfiguration is the default, effectively unlimited, letting SQL Server and the OS fight.
Disk speaks numbers with hard thresholds: perfmon's Avg. Disk sec/Read and sec/Write per volume, healthy under 10ms for data and a few ms for log, tolerable to 20ms, indicting the storage above that, matched against sys.dm_io_virtual_file_stats naming which database files suffer. Log volume latency hits every commit everywhere, the everywhere at once signature specifically. Autogrowth events compound it, the default 1MB or percent growth settings causing constant file growth stalls, visible in the default trace and fixed with sane fixed growth sizes.
The settings pass completes it: cost threshold for parallelism at the ancient default of 5 sends trivial queries parallel, 25 to 50 fits modern workloads, MAXDOP at 0 on many core boxes deserves a value per current guidance and tempdb wants multiple equal data files rather than the single default. None of these require heroics, together they routinely return an instance that was configured by installation defaults to its actual hardware's speed, at which point the query level thread linked alongside takes over for whatever slowness genuinely belongs to queries.