Stats

[JohnMcLear]

Do you have stats of page loads PRE the implementation and POST the implementation? I'd be interested in implementing this for Etherpad but I'd need to know how much impact it will have prior to me spending the time on it.

Alternatively if you want to drop it into Etherpad and give me stats in a real world application I'd be willing to consider merging it..

https://github.com/ether/etherpad-lite/tree/develop/src/static/font are the font files.. Note we minify and set maxAge at runtime.

[jaicab]

If you need some stats, this is some of the best info out there: http://blog.mebooks.co.nz/using-local-storage-to-improve-page-load/ http://www.mobify.com/blog/smartphone-localstorage-outperforms-browser-cache/ http://www.stevesouders.com/blog/2011/09/26/app-cache-localstorage-survey/

[JohnMcLear]

Those stats aren't specific to fonts though, I think doing a real world pre and post implementation woulds be the best way to see the real world impact of this.. Almost like a case study... Currently "in theory" it should be faster but in theory doesn't always win the race..

[Aymkdn]

+1 for @JohnMcLear :-)

[wjordan]

I agree, current stats are important because browser implementations change quickly.

I tried running the jsperf test linked in the first link above, and the standard cache in my current browsers (both on desktop and mobile) appears to be significantly faster than localStorage- 30% faster on my Ubuntu-Chrome desktop, and 47% faster on my Android-Chrome mobile.

Based on these stats, I'd recommend deprecating/avoiding this outdated technique entirely (whether for fonts or otherwise), if targeting current modern browsers - unless other stats reveal otherwise.

[DanielRuf]

I have the same opinion like @wjordan. localstorage takes longer and probably blocks rendering as the JavaScript engine stops and does all the heavy lifting to base64 decode the files. Also base64 encoded strings are larger than nonencoded strings so expect some performance drawbacks.