Why Is WindowServer Using So Much CPU? 1.8% vs 0.08%

I don't own a monitor for this Mac, and WindowServer still drew 6.56 hours of CPU in its first 20 days of uptime. This morning I measured where that comes from. The answer on my machine was one variable: whether the display macOS invents for a headless Mac is awake. Awake, WindowServer used 1.81% and 1.78% of one core across two runs. Asleep, it used 0.08%, 0.13% and 0.08%. That's roughly a 20x gap, and nothing about the workload changed in between.

If you searched why is WindowServer using so much CPU, the top results are mostly cleaner-app vendors telling you to close windows and buy their tool. This post is narrower. It gives the numbers from one Mac with no human in front of it, a way to take the same measurement without Activity Monitor skewing it, and a summary of what people in Apple's forums and on Hacker News actually traced their spikes to.

The rig, and the display that isn't there

Mac16,10 (M4, 10 cores), macOS 26.4.1 (25E253), booted Sep 28 at 10:09, reached over SSH. No cable in either HDMI or Thunderbolt. system_profiler SPDisplaysDataType still reports a main display:

Displays:
  Screen Sharing Virtual Display:
    Resolution: 3840 x 2160 (2160p/4K UHD 1 - Ultra High Definition)
    UI Looks like: 1920 x 1080 @ 60.00Hz
    Main Display: Yes
    Online: Yes
    Display Asleep: Yes

(The name is localized on my machine; I translated it.) So WindowServer has a 4K HiDPI framebuffer to composite even though no photon ever leaves the box. I covered the other side of this earlier, when I found that a dummy display plug buys nothing on Apple silicon over SSH. This post is about what that synthetic display costs.

Method: two ps readings, not Activity Monitor

ps reports each process's cumulative CPU time. Read it twice, subtract, and divide by the wall-clock gap. That gives an average for the whole window instead of the instantaneous number top shows, and nothing is drawn on screen while you do it. To wake the display without touching a setting, I used caffeinate -u, which declares user activity for a set number of seconds.

pid=$(pgrep -x WindowServer)
a=$(ps -o time= -p "$pid"); sleep 120; b=$(ps -o time= -p "$pid")
echo "$a -> $b"      # a 2.17 s gap over 120 s = 1.81% of one core

caffeinate -u -t 150 &   # wake the display for 150 s, then sample again

One unit note before the numbers, because it confuses a lot of forum threads: ps and Activity Monitor report CPU percent per core. On this 10-core M4, 100% means one core is fully busy and the ceiling is 1,000%. Apple's Activity Monitor guide covers the System/User/Idle split at the bottom of the window, which is a different, whole-machine number.

Results

Every row is a separate window taken between 10:30 and 10:51 KST today. I dropped two 120-second windows because the display changed state partway through: one turned off at 10:36:55, the other at 10:45:10. They came out at 0.97% and 0.46%, between the two clean states, which is what you'd expect from a mix.

Two side findings came out of the same samples. First, loginwindow moves the opposite way: 0.46% to 0.49% while the display slept, 0.00% to 0.01% while it was awake, in every clean window. I don't know why, and it's small enough that I'm only reporting it. Second, the display shut off about ten seconds after each caffeinate assertion expired (10:36:55 and 10:49:03), even though pmset -g reads displaysleep 10. On the other hand, five of the fourteen wake periods in this week's power log lasted exactly 10 min 11 s, which does fit that setting. My guess is the setting only times idleness after real input, but I didn't test that.

The bigger number was the wallpaper

Today's averages don't add up to the 20-day total. WindowServer has accumulated 393:45.76 of CPU time over 480.7 hours of uptime, a 1.36% average. The power log covers the last seven days, and in that window the display was awake for 3 h 20 min before my tests, about 2% of the time. At 1.8% when awake and about 0.1% when asleep, that works out to roughly a 0.13% average. The real average is ten times higher, so most of those 6.56 hours were spent earlier in this boot, under different conditions.

The other cumulative counters point to what those conditions were. WallpaperAerialsExtension has 17.26 hours of CPU time on this boot (more than WindowServer itself), and VTDecoderXPCService, the video decoder that feeds it, has 4.65 hours. In every window this morning, the Aerials extension measured 0.00% to 0.01%. On Jul 31, while writing up this Mac mini's 24/7 power consumption, I sampled it at 6.80% and WindowServer at 8.34%, with displaysleep 0. At the July rate, 17.26 hours works out to about 254 hours, or 10.6 days, of animated wallpaper. That's an inference from two counters, not a log entry. The setting now reads displaysleep 10, and I have no record of when it changed or who changed it. When I profiled Spotlight on this machine in September, the Aerials extension was the single biggest CPU consumer on the box, at 50,334 CPU-seconds.

What forum threads traced it to

A headless machine is the easy case. If your Mac has real screens and real apps, the spike is usually somewhere else. I searched HN comments mentioning WindowServer and CPU (105 hits on Algolia), read the top 30, and checked them against Apple's forums. The causes that actually got isolated, as opposed to guessed at, fell into a few groups:

• An app spamming redraws. The most repeated diagnosis on HN is that high WindowServer CPU is "a symptom, not a cause". Another commenter gives a working threshold: if it sits above 6 to 10% while you're doing nothing, some background app is likely pushing 60 fps updates. Quartz Debug's "flash screen updates" mode shows which one is flashing. Spotify, Discord and Chrome are all named in the thread.
• Display features on external monitors. In one Apple Community thread on macOS 10.14.6, a user saw 40 to 50% that dropped to 3% when Night Shift was turned off, and reproduced it three times. On current hardware, a developer-forum post about an M5 Pro driving a 5K 165 Hz display traces crash logs to a WindowServer display-pipeline assertion. No Apple reply as of today.
• Input polling. One commenter reported a 1,000 Hz gaming mouse driving WindowServer to 150% on Big Sur. The fix there was lowering the poll rate.

One claim I could test directly: an HN commenter wrote that Activity Monitor itself pushes WindowServer from 7–11% to 20–40%. On this machine, opening it (open -g -a "Activity Monitor", default refresh) moved WindowServer from 0.08–0.13% to 0.23% with the display asleep, and from about 1.8% to 2.10% with it awake. So I measured an observer effect of 0.1 to 0.3 points, not 10 to 30. But Activity Monitor cost 1.91% to 2.04% of a core on its own, which is more than WindowServer's entire awake cost. Scope matters here: I only have one Mac, its display is virtual and nobody was looking at the window, and that commenter was on an Intel machine in 2020. The practical takeaway still holds. If you're chasing a few percent, measure with ps rather than with an app that adds its own load.

What I'd check, in order

1. Read the per-core number correctly. 30% on a 10-core Mac is under a third of one core.
2. Take two ps readings with the display on and with it asleep. If the gap is large, as it was here, the cost comes from drawing, not from something broken.
3. Turn off moving wallpapers and screen savers on any machine nobody watches. Compare this with how sleep assertions keep a Mac awake. A display that's awake for no reason has the same cause.
4. On a desktop with monitors attached, quit apps one at a time while watching the ps delta. Use Quartz Debug's flashing if you can't tell which app is drawing.

Sources and method: all CPU figures come from ps -o time= deltas on one Mac16,10 (M4, macOS 26.4.1 25E253), taken on 2026-10-18 between 10:30 and 10:51 KST, with the display woken by caffeinate -u and the state checked against pmset -g log and system_profiler. That's seven clean windows of 90 to 120 seconds, and the two mixed-state windows are reported but excluded. The July figures are from my Jul 31 measurement on the same machine. The wallpaper explanation for the 20-day total is arithmetic on cumulative counters, labeled as inference above. The forum section summarizes the linked threads. I did not reproduce the Night Shift, mouse or external-display cases, because this machine has no monitor or mouse.