Slow webserver after upgrade from ESP8266 to ESP32

[marcom]

Hi.
I use ESP8266 (4MB) with SPIFFS webserwer and simpleftp.
I works great.
Now, I would like to use my code with ESP32 (4MB) - because od bluetooth, IOs, etc.
I changed my code, it woks, but I am confused because of speed of it !
I have to wait 4-5 seconds for page refresh.
I am sending HTML files from SPIFFS and I don't know what is to slow - flash file system or wifi ?
I think it is a flash problem because if i have page declareg with PROGMEM - it works fast (normal).
I lost all my day for testing and I don't know what to do.
Stay with ESP8266 and cry or... or believe it is my fault, SPIFFS library problem (LittleFS doesn't work with ESP32 so I use SPIFFS) and try another solutions (declare all my html pages as PROGMEM - but it is awfull when page is big).

I believe someone had the same problem and can help.
Regards,
Mariusz

[Sprite]

I'm no expert on this, but it'll likely help if you can post the code you're having issues with.

[HardyM]

I'm also seeing issues with the ESP32 camera web server demo (expanded with my own application)
But even the default application has issues too I find.
I'm feeding paged read from SD Card and I've done some profiling.
The card data gets read and then passed to httpd_resp_send which can take many seconds to return the data - often timing out.
Usually a power off / on again will sort it.
I've seen lots of questions about this - is it a wifi thing ? How to get the wifi debugging info might be handy to know.
Regards
Hardy

[Qmaker-programmer]

Hi marcom,

I read that you went back to SPIFFS because you thought LittleFS doesn't work on ESP32. Don't give up on it! LittleFS is much faster and more reliable than SPIFFS for the ESP32, especially when handling multiple web requests or real-time data.

The reason it might have failed for you is likely the library version or the mount configuration. Since ESP32 Core v2.0.0, LittleFS is officially supported and integrated, so you don't need external libraries.

I am currently running a project called **QuickChat S3** (a 100% offline messaging system) that relies entirely on LittleFS to serve a modern "Obsidian Dark" web interface. It works flawlessly even with multiple clients because I use it alongside the **ESPAsyncWebServer** library.

1. How to initialize LittleFS correctly:

Code: Select all

#include "LittleFS.h"

void setup() {
  Serial.begin(115200);
  
  // The 'true' parameter formats the partition if mounting fails the first time
  if(!LittleFS.begin(true)){ 
    Serial.println("LittleFS Mount Failed");
    return;
  }
  Serial.println("LittleFS Mounted Successfully");
}

2. To fix the slowness, use an Asynchronous Server:
Instead of the standard WebServer, use ESPAsyncWebServer. It allows the ESP32 to serve files from LittleFS without blocking the CPU:

Code: Select all

#include <ESPAsyncWebServer.h>
AsyncWebServer server(80);

void setup() {
  // ... (LittleFS.begin here)
  
  // Serve all static files from the root of LittleFS automatically
  server.serveStatic("/", LittleFS, "/").setDefaultFile("index.html");
  server.begin();
}

Why this works better:

• Non-blocking: The server handles requests in the background.
• Efficiency: LittleFS handles the small, frequent reads of a web interface much better than SPIFFS.
• Real-time: In my project, I use this setup with WebSockets to achieve zero lag.

You can see a full working implementation of this architecture in my repository here: https://github.com/Qmaker-programmer/QuickChat

Using LittleFS with an Async approach will definitely solve the slowness you experienced. Hope this helps you get your project back on track!

[lbernstone]

I've seen lots of questions about this - is it a wifi thing ? How to get the wifi debugging info might be handy to know.

If you set core debug level higher in the tools menu, you will see lots more info about WebServer debugging. Info will show you the transactions, verbose shows you every byte sent across the wire (you can turn on timestamps in the Arduino serial monitor to get timings). It is also often useful to watch the network console in your browser's developer tools to see if there is a big gap between the times the device (server) sees versus the client.