ESP32-CAM stream is slow or lags: resolution, quality and Wi-Fi

Lower the frame size first. A smaller picture uses far less Wi-Fi time.

What the message means

Each frame is a JPEG sent over Wi-Fi. A large frame or a weak signal limits the rate, and a weak supply makes the board reset.

Fix it in this order

Choose a smaller frame size such as QVGA or VGA.
Raise the JPEG quality number a little, since a higher number means more compression and a smaller file.
Check the Wi-Fi signal and keep the antenna clear.
Use a good 5 V supply that can give enough current.
Keep only one client connected to the stream.
Turn off extra features, such as face detection, while testing speed.

Why it happens

Each frame is a JPEG sent over Wi-Fi, so the rate depends on frame size, compression and signal. The driver’s jpeg_quality runs from 0 to 63, where a lower number means higher quality and larger files, so raising the number shrinks each frame.

One guide says JPEG at QVGA works without extra PSRAM while larger sizes need it, and the driver’s own example says sizes above QVGA are for JPEG output; check your board and driver version. A supply that sags under radio load can also cause resets that look like lag.

If you see this, do this

You see	Do this
Stream stutters	Frame size or signal.
Board resets while streaming	Power. See the brownout page.

brownout resets, ESP32-CAM upload.

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.

Why this happens

The camera sensor produces frames that the ESP32-CAM compresses to JPEG and sends over Wi-Fi. The rate you see is the smallest of three limits: how fast the sensor and encoder can produce frames, how many bytes each frame has, and how many bytes per second the radio can move. A bigger frame size and a lower jpeg_quality number both give larger files. Real Wi-Fi throughput on this board is usually well below the nominal link speed and falls quickly with a weak signal.

As an illustration, if one frame is 20 KB and you want 15 frames per second, the link must carry 300 KB per second, which is 2.4 Mbit per second, sustained. Your own frame size will differ, so measure it. The Wi-Fi power-save mode can also add delays between packets.

How to confirm the cause

Print the frame length (fb->len) for a few frames. Multiply the average by your frame rate to estimate the needed bandwidth.
Print WiFi.RSSI(). Values near -70 dBm or lower suggest a weak link; compare with the board close to the router.
Count the frames you actually send per second in your code and compare with the rate the viewer shows.
Watch the supply with a multimeter during streaming. A drop or a restart message points to power rather than speed.
Check in the Tools menu whether PSRAM is enabled for your board.

Worked example

Reduce size, set a middle quality number and turn off modem sleep. The calls are the ones used in the standard camera driver.

sensor_t *s = esp_camera_sensor_get();
s->set_framesize(s, FRAMESIZE_QVGA);
s->set_quality(s, 12);          // 0 to 63, higher = smaller file
WiFi.setSleep(false);

camera_fb_t *fb = esp_camera_fb_get();
Serial.printf("frame %u bytes\n", fb->len);
esp_camera_fb_return(fb);

Common mistakes

Leaving a large frame size set from a sample sketch.
Forgetting esp_camera_fb_return, which starves the driver of buffers.
Opening the stream in two browser tabs at once.
Putting the board inside a metal case or against the antenna.
Judging speed with a face recognition feature running.

If this did not fix it

PSRAM disabled, which limits the frame buffers and sizes.
A congested Wi-Fi channel; test on a different channel.
A weak supply that resets the board under radio load.
The viewer or the network on the other side being the bottleneck.