Initial loading/rendering should be faster

[marians]

Even with good UMTS network bandwidth, loading the webapp feels slow and the app looks broken in the meantime. Both actual and perceived load duration should be improved.

Here is a test that shows details on the current loading behaviour: http://www.webpagetest.org/result/140624_WD_8FF/1/details/

The test has been performed with the "3G" network setting and slow roundtrip time (300ms), location: Falkenstein, Germany.

Without cached elements, it takes 5.2 seconds until the application is loaded.

Here are some pain points:

• Time to First Byte: ~320 ms is way too much for static resources. Will check my server setup. Might be that this is caused by nginx forwarding these requests to Apache.
• jQuery loaded via SSL: Could actually be served without SSL. Download seems to block other network threads.
• leaflet.js blocks loading: Download of leaflet.min.js takes 1 sec and no other resources are loaded from sendung.de in the meantime.
• Too many DNS lookups: DNS lookups make up for a substantial share of the entire duration.

[marians]

Some in-page optimizations have now been done:

• Put leaflet and jquery JavaScript into index.html to reduce requests/roundtrips.
• Put leaflet.css into index.html (and minified it using Chrome Page Speed) to reduce requests/roundtrips.
• Configured the tiles layer so that it's only loaded from one host name instead of three. This reduces initial load time at the cost of tiles download performance during zooming and panning.
• Preloaded marker.png from JavaScript. This is done to improve perception, as it prevents the browser from rendering placeholder frames on the map.

Here is a test result after these optimizations: http://www.webpagetest.org/result/140624_D7_A8N/

Comparison:

• Load time before 5.235s, after 2.736s
• Start Render before 1.994s, after 2.417s
• Visually complete before 8.400s, after 5.100s
• Requests before 15, after 10

[marians]

Did some re-configuration on the server end. In fact requests were proxied by nginx and served by Apache. I changed this to make nginx directly handle the request. Results are here:

http://www.webpagetest.org/result/140624_D7_A8N/

Surprisingly, the Time to First Byte hasn't changed at all. Seems like the proxying to Apache didn't affect times. Since only 3 requests are made to that server, the impact is small.

It turns out that the time to first byte result is mainly influenced by the 3G network setting for the test. Here is a test result with Cable Modem settings: http://www.webpagetest.org/result/140624_XV_BHX/

Here, time to first byte is down to 170 ms.

Closing for now.