Please see https://forum.xojo.com/t/web-2-0-when-using-https-initial-page-load-is-500msec-slower/ for background details.
Xojo web 2.0 can be slow to load the first page because it’s making over 25 requests for small files (CSS and JavaScript mostly). Even if these files can be cached, the browser still much check each one, and this takes time.
The question came up “would it be faster to inline these into a single file” which is one of the recommendations here: https://developers.google.com/speed/docs/insights/BlockingJS
I’ve put together a proof of concept which I’m calling FastStart
Here’s the outline of what it does:
- App.HandleURL : add code to handle a new special URL “fast.html”
- Upon first connection to /fast.html, the app makes a URLconnection to “/” which gets the Xojo web default HTML. This file is about 60 lines, most of which are links to load script and CSS tags
- process this HTML line by line
- for each CSS or Script tag, extract the URL, make a new URLConnection to localhost and get the content of the file
- Inline it: replace the script (or css) tag with the contents of the file
- if it’s not a script or css line, then just add the line to the output
- cache the data
- Send the WebResponse with the final output
On subsequent connections after the first one, we can skip most of these steps and simply use the cached, inlined HTML – all we have to do is replace the SessionID with the new session ID.
Does it work?
Tests of Xojo Web FastStart
All tests are measuring the time until the first screen paint (e.g. when the web app UI is shown and is usable). All tests are using HTTPS.
Test 1:
Server is on LAN (gigabit ethernet), sub millisecond ping time.Time Condition
1.8 normal
2.2 normal, cached (!note - this is slower than uncached!!)
1.4 fastStart, first session, uncached (includes initial parsing time)
0.5 fastStart, cached
0.5 fastStart, uncachedConclusion: on a fast LAN, fastStart is much faster, even though the 1.73MB inlined HTML file can not be cached. Xojo Web is actually slower when the files are cached (possibly suggesting some issue with the 304 responses?)
Tests 2 and 3 are using using Network Link Conditioner to simulate a slow connection.
See https://download.developer.apple.com/Developer_Tools/Additional_Tools_for_Xcode_12.5/Additional_Tools_for_Xcode_12.5.dmgTest 2:
Simulated LTE (50mbps/10mbps with 65msec delay)Time Condition
4.5 normal
4.1 normal, cached
1.9 fastStart, first session, uncached (includes initial parsing time)
1.2 fastStart, uncached
0.9 fastStart, cachedConclusion: on a good LTE connection, fastStart is much faster in all cases
Test 3:
Simulated 3G (780kbps/330kbps with 100msec delay)Time Condition
6.7 normal
4.3 normal, cached
7.1 fastStart, first session, uncached (includes initial parsing time)
6.8 fastStart, uncached
6.7 fastStart, cachedConclusion: on a 3G connection, the lack of caching starts to matter, and fastStart can be slower than normal.