Scrollback.io makes Google's pagespeed tool score badly

[kaihendry]

https://developers.google.com/speed/pagespeed/insights/?ux=1&url=http%3A%2F%2Fhackerspace.sg&tab=mobile

[notthetup]

"Compressing http://scrollback.io/socket/018/v53sr0gg/xhr_streaming could save 2KiB (98% reduction)."

Could we mention this to the scrollback guys? They are a local startup.

[kaihendry]

https://twitter.com/kaihendry/status/428416687163969536

[aravindet]

Before discussing compression and other ideas to speed Scrollback up, I'd like to point out that Scrollback is loaded asynchronously and it wouldn't slow down the loading of other resources on the page. Simple pages are typically rendered before scrollback begins to load.

This means that the Scrollback UI would always show up a few seconds after the rest of the page. We realize that this has an effect on the perceived performance of the website, but at the moment it's a trade-off between loading Scrollback first and loading other resources on the website first.

Gzip compression: Scrollback is served in one static javascript file (client.min.js) which is served from the browser cache >99% of the time. Serving it compressed would certainly have a modest improvement in first-time loading. The xhr_streaming request you see in PageSpeed is the connection for real-time data (on most browsers websockets will be used). It just sends tiny messages (a few hundred bytes each) back and forth with long delays in between, so I doubt adding compression here would improve responsiveness.

Much larger gains in performance will come from extensively using HTML5 AppCache and LocalStorage. After this change, scrollback will load up and display the UI using cached messages without making any network request. In our proof of concept, the chat box barely flickers while the rest of the page is reloaded.

[kaihendry]

:thumbsup:

[notthetup]

:+1:

[chernjie]

:thumbsup: