I've had exactly the same problem, it was troubling me quite a long time. It is especially annoying when working remotely over SSH or playing multiplayer games. Here is my long-term solution:

Diagnosis

Run ping with frequency 10 scans per second to see when is the glitch occurring:

ping 8.8.8.8 -i 0.1

Scanning & Location services

As mentioned by others, WiFi spikes are typically caused by WiFi daemon scanning another WiFi networks around. The scanning goes through all channels so if the current receiving channel is not the same as your AP is transmitting, you have a ping spike.

The scanning is usually triggered by location services. You can review the location services in: System Preferences -> Security & Privacy -> Privacy tab -> Location Services .

If you go to Advanced check the Show location icon in the menu bar... to see when the apps are querying location thus scanning WiFi neighborhood.

Location services were still active because of System services . Mainly Time Zone & System Customisation and Significant Locations . But after turning that off I still had a WiFi glitch in spite of that Location setting window showed no other application acquiring the location.

Finding the culprit

You need to enable WiFi logging to see why is WiFi daemon doing the scan.

Hold option/alt key (next to the command key) and click WiFi icon in the top toolbar. Click Enable Wi-Fi Logging .

After that open a new terminal:

tail -f /var/log/wifi.log

You should see something like this:

Mon Jan 14 20:01:21.353 AutoJoin: <airportd[83093]> Successful cache-assisted scan request for texstudio with channels {( Mon Jan 14 20:01:21.353 <CWChannel: 0x7fbcfadc5b20> [channelNumber=56(5GHz), channelWidth={40MHz(-1)}, active, DFS], Mon Jan 14 20:01:21.353 <CWChannel: 0x7fbcfadcbfb0> [channelNumber=60(5GHz), channelWidth={40MHz(+1)}, active, DFS], Mon Jan 14 20:01:21.353 <CWChannel: 0x7fbcfd44c790> [channelNumber=64(5GHz), channelWidth={40MHz(-1)}, active, DFS], Mon Jan 14 20:01:21.353 <CWChannel: 0x7fbcfadc6ba0> [channelNumber=149(5GHz), channelWidth={80MHz}, active], Mon Jan 14 20:01:21.353 <CWChannel: 0x7fbcfad2be90> [channelNumber=153(5GHz), channelWidth={80MHz}, active], Mon Jan 14 20:01:21.353 <CWChannel: 0x7fbcfadf4870> [channelNumber=157(5GHz), channelWidth={80MHz}, active] Mon Jan 14 20:01:21.353 )} took 0.0005 seconds, returned 2 results Mon Jan 14 20:01:21.353 Scan: <airportd[83093]> Cache-assisted scan request for texstudio on channel 161 does not require a live scan Mon Jan 14 20:01:21.353 Scan: <airportd[83093]> Cache-assisted scan request for texstudio on channel 165 does not require a live scan Mon Jan 14 20:01:21.353 Scan: <airportd[83093]> Cache-assisted scan request for texstudio on channel 100 does not require a live scan Mon Jan 14 20:01:21.353 Scan: <airportd[83093]> Cache-assisted scan request for texstudio on channel 104 does not require a live scan Mon Jan 14 20:01:21.353 Scan: <airportd[83093]> Cache-assisted scan request for texstudio on channel 108 does not require a live scan Mon Jan 14 20:01:21.353 Scan: <airportd[83093]> Cache-assisted scan request for texstudio on channel 112 does not require a live scan Mon Jan 14 20:01:21.353 Scan: <airportd[83093]> Cache-assisted scan request for texstudio does not require a live scan

Now observe ping terminal and wifi log terminal next to each other. You can clearly see the glitch occurrs precisely when WiFi is doing the scan.

In my case the culprit was a program texstudio , as you can see from the log. It was acquiring location every 5 seconds (wt.?), which was is confirmed also by this guy: https://justus.berlin/2016/04/reducing-cpu-load-and-energy-consumption-of-texstudio-on-the-mac/

This solved my problem. The Texstudio was not mentioned in the location services list so this advanced approach was necessary.

Summary: