teenystat/Articles/Presentation lag

Mac presentation lag: use repeatable CPU and memory checkpoints

Repeat the same slide or action at baseline, after the stack settles, during the failure, and after one change. That pattern separates evidence from a lucky retry.

Published Jul 5, 2026 Updated Aug 9, 2026 10 min read By John Sciacchitano

The short answer: reproduce one exact lagging action, then compare it at four checkpoints: a quiet baseline, the settled presentation stack, the failure, and recovery after one reversible change. Use TeenyStat for the system trend and Activity Monitor for process names, Memory Pressure, swap, and quit controls.

A high CPU number does not prove the deck caused the lag. A high used-memory percentage does not prove macOS is short on memory. If the same action lags while CPU and Memory Pressure remain normal, shift the test to the slide media, external display, or remote-share route.

Disclosure: I build teenystat. Current Swift source reads CPU from tick deltas returned by host_processor_info. Its first CPU sample establishes a baseline and can be near zero. Used memory is active plus wired plus compressed pages from host_statistics64. That is not Apple's Memory Pressure calculation.

This is the system-load spoke for the TeenyApps Mac presentation rehearsal checklist for contrast and load. If the failure is unreadable text or color meaning, use TeenyColor's two-proof slide contrast workflow.

Match the lag to the evidence

Observed pattern What it supports Next test
Launch spike settles and the repeated action becomes smooth. Temporary startup or rendering work. Run the full deck once; do not diagnose from the launch sample.
The same action lags with sustained CPU and one process at the top. A process or workload deserves investigation. Save work, identify the process, then remove one nonessential workload.
Activity Monitor Memory Pressure or swap rises during the run. Memory efficiency may be part of the slowdown. Close one safe app, repeat the same action, and compare recovery.
One slide or movie lags locally with normal system signals. The content or media path is more likely than general load. Test the item alone and review its format, size, transition, and export.
Only remote participants see lag. The meeting, network, capture, or share route needs a separate test. Compare local playback with a received participant view.

01Define one lagging action

Write a narrow reproduction before watching metrics: "advance from slide 11 to 12 and play the embedded movie," "start the browser demo," or "share the Keynote window and trigger the build." Include the deck revision, route, and start state.

Broad notes such as "presentation feels slow" mix several possible failures. Slide advance, pointer delay, local media playback, external-display stutter, remote-share stutter, and meeting-audio delay use different paths.

Run the action once from a quiet desktop and record whether it fails. This is the baseline. Then open the full presentation stack, including the actual display, meeting app, browser, notes, recorder, and local server you plan to use.

02Let the monitor establish a real baseline

TeenyStat computes CPU from the change between processor tick samples. The first read establishes previous ticks and may be near zero, so it should not be used as proof that the Mac was idle.

The app polls every three seconds by default and keeps up to 60 points in each sparkline. At the default interval, that is roughly three minutes of direction, not a durable performance trace. If the interval changes, the time covered by the 60 points changes too.

Wait for several samples after the stack opens. Record whether CPU settles, used memory stabilizes, and fan speed is available. Fan speed is delayed context on Macs with fans; a fanless result is expected on fanless hardware.

03Repeat the action during the failure

Trigger the same slide, movie, build, or share action. Note the wall-clock time and watch the trend before, during, and after the lag. Repeat once. A single pause can be a cache warm-up or a missed input; the same pause at the same action is more useful evidence.

Compare the failure with the settled checkpoint. Did CPU rise with the lag? Did one core stay busy? Did used memory keep climbing? Did the fan trend change later? These observations narrow the next test, but they do not name a cause.

Open Activity Monitor when you need process attribution. Sort by CPU for compute work. Use the Memory pane for Memory Pressure, compressed memory, cached files, and swap. Apple explains that Memory Pressure combines several memory conditions, so free or used memory alone is not the diagnostic.

04Make one reversible change and check recovery

Save the deck and meeting state. Remove one nonessential workload, such as an exporter, duplicate browser, optional recorder, video effect, sync job, or local build. Repeat the same action from the same starting state.

If the lag clears and the system trend recovers, the change is useful evidence. It is not proof that the closed app was the only cause. Reopen it after the rehearsal if you need to confirm the relationship.

Use normal Quit first. Force Quit can lose unsaved work and disrupt dependent processes. The menu bar monitor versus Activity Monitor guide covers the handoff from system signal to process-level action.

05Change tracks when the system evidence is normal

TeenyStat does not show GPU, disk, network, meeting quality, or the remote participant's received frames. Normal CPU and Memory Pressure do not prove those paths are healthy.

If one local slide or movie fails, test the media by itself. Apple documents Keynote controls for media compatibility and reducing presentation file size; those are content checks after general system load is ruled out, not promises that a conversion will fix lag.

If local playback is smooth and only the external display fails, test the display route. If only remote participants see lag, compare a received participant view with local playback and inspect the meeting, capture, and network path. If the audience problem is readability, switch to the TeenyColor contrast workflow.

Presentation lag evidence card

  1. Deck revision, route, slide or action, and expected result.
  2. Quiet baseline result after more than the first CPU sample.
  3. Settled-stack CPU, used-memory trend, fan availability, and Activity Monitor Memory Pressure when relevant.
  4. Failure time, visible symptom, repeated result, and process evidence.
  5. One reversible change and the recovery result.
  6. Final classification: system load, slide or media, display route, remote share, or unresolved.
  7. Accepted live setup and tested fallback.

Sources checked

FAQ

Why is my Mac presentation lagging?

The cause may be system load, one slide or media item, the display route, or a remote share. Repeat the same failing action at baseline, after the stack settles, during the failure, and after one change. Compare CPU with Activity Monitor memory pressure before assigning a cause.

Does high memory used mean the Mac is short on memory?

Not by itself. TeenyStat reports used memory from active, wired, and compressed pages. Open Activity Monitor for Memory Pressure and swap, which are better diagnostic signals than a used percentage alone.

Can TeenyStat tell which app is causing presentation lag?

No. TeenyStat shows system-level CPU, used memory, fan data where available, short sparklines, and per-core CPU shape. Use Activity Monitor when you need process names, Memory Pressure, swap, or quit controls.

What if the presentation lags while CPU and memory pressure look normal?

Test whether the lag follows one slide, one media item, an external display, or only the remote share. Normal system signals do not prove the route is healthy, but they are a reason to stop blaming CPU and test the presentation path.

Related articles

Keep system load visible before the room joins.

teenystat shows CPU, memory, and fan speed in your Mac menu bar, with thresholds, sparklines, and per-core CPU detail when you need a closer look.

Download teenystat Read more guides