Compress the HTML content

[redakker]

Change to code to serve gzipped content to the browser

• change the webserver
• change the pre-build script which prepares the HTML for the C++ code

It will save some space on the ESP device and probably the web serving will be faster.

[BalazsM]

I profiled the site loading network trafic, and found that the full reload time is above 2000ms. Which breaks up like this:

1. 16,6% (332 ms) is building up TCP sockets
2. 29.35% (587ms) is waiting for response
3. 20.05% (401ms) is content delivery
4. 34% (680ms) is doing nothing

The most of the loading time (4th point) is came from functions.js line 382-401 where are setTimeouts to load data, css files and chip info. When I removed these setTimeouts to load files instantly and moved css files into big one, the load time dropped under 1000ms, because waits were removed, and 2 of 9 TCP socket build up are also removed. But, an issue camed up: sometimes the webserver did not provide content (ex: css file is empty)!

I will improve pre_build_web.py to minify further css files (ex: remove comments, line endings) and place into one. With this modificítion we can move loading around 1000-1500ms, becouse removing 3 of 5 setTimeouts and TCP socket build ups.

I found an another issue, but don't know yet where it came from: sometimes content delivery pauses for seconds. With detailed logging I will investigate which function is locking in loop().

I think we need a better webserver implementation, which can do at least one of these:

• can handle multiple queries in order without problems
• can handle multiple queries in same time (not multithreaded, just finite state machine driven)
• can reuse TCP socket

[redakker]

@BalazsM
Thanks for your effort!
Yes, your points make sense.
The timeouts were implemented to mitigate the heavy load of the chip. Sometimes stuck because of "big data" even if that is a very small HTML page.
All improvements are appreciated.

I profiled the site loading network trafic, and found that the full reload time is above 2000ms. Which breaks up like this:

1. 16,6% (332 ms) is building up TCP sockets
2. 29.35% (587ms) is waiting for response
3. 20.05% (401ms) is content delivery
4. 34% (680ms) is doing nothing

The most of the loading time (4th point) is came from functions.js line 382-401 where are setTimeouts to load data, css files and chip info. When I removed these setTimeouts to load files instantly and moved css files into big one, the load time dropped under 1000ms, because waits were removed, and 2 of 9 TCP socket build up are also removed. But, an issue camed up: sometimes the webserver did not provide content (ex: css file is empty)!

I will improve pre_build_web.py to minify further css files (ex: remove comments, line endings) and place into one. With this modificítion we can move loading around 1000-1500ms, becouse removing 3 of 5 setTimeouts and TCP socket build ups.

I found an another issue, but don't know yet where it came from: sometimes content delivery pauses for seconds. With detailed logging I will investigate which function is locking in loop().

I think we need a better webserver implementation, which can do at least one of these:

• can handle multiple queries in order without problems
• can handle multiple queries in same time (not multithreaded, just finite state machine driven)
• can reuse TCP socket