Mobile & Desktop Cache 2.0: How To Create A Scriptable Cache
4 likes2,530 views
This document provides an overview of how to build a scriptable cache for mobile and desktop applications. It discusses: - The benefits of a scriptable cache like improved performance and ability to implement advanced optimizations. - A 6 step process for building a basic scriptable cache using localStorage and dynamically loading/storing resources. - Additional techniques like handling errors, tracking cache state and size, and implementing an LRU cache. The document is intended to introduce the concept of a scriptable cache but notes that implementing one is not trivial and requires modifications to HTML and resources. Pseudocode is provided but may have errors and not cover all cases.
![Step 3: LRU Cache – Getting items
var
sCache
=
{
…
getItem:
funcHon(name)
{
//
Try
to
get
the
item
var
data
=
db
&&
db.getItem(name);
if
(!data)
return
null;
//
Move
the
element
to
the
top
of
the
array,
marking
it
as
used
for(var
i=0;i<dat.items.length;i++)
{
if
(dat.items[i].name
===
name)
{
dat.items.unshiw(dat.items.splice(i,-‐1));
break;
}
}
return
data;
}
…}
21](https://image.slidesharecdn.com/diy-scriptable-cache-v2-111027153233-phpapp02/85/Mobile-Desktop-Cache-2-0-How-To-Create-A-Scriptable-Cache-21-320.jpg)
Mobile & Desktop Cache 2.0: How To Create A Scriptable Cache
- 1. DIY Scriptable Cache Guy Podjarny, CTO guypo@blaze.io twi;er: @guypod
- 2. Agenda • Caching 101 • Mobile & Desktop Scriptable Cache – Concept – 6 Steps to Building a Scriptable Cache – Advanced Optimizations • Q&A 2
- 3. The Value of a Scriptable Cache • A dedicated cache, not affected by other sites • A robust cache, not cleared by power cycles • Better file consolidation – Works in more cases – Cache Friendly – Less requests without more bytes • Enable Advanced Optimizations – Robust Prefetching, Async CSS/JS… • The Secret to Eternal Youth 3
- 4. Not For The Faint of Heart! • DIY Scriptable Cache isn’t simple – No magic 3 lines of code • Requires HTML & Resource modifications – Some of each • The code samples are pseudo-code – They don’t cover all edge cases – They’re not optimized – They probably have syntax errors 4
- 5. Caching 101
- 6. What is a Cache? • Storage of previously seen data • Reduces costs • Accelerates results • Sample savings: – Computation costs (avoid regenerating content) – Network costs (avoid retransmitting content) 6
- 7. Cache Types Gateway -‐ Server resources from the faster intranet -‐ Shared per organizaHon Browser CDN Edge -‐ Eliminates network Hme -‐ reduces roundtrip Hme – latency -‐ Shared by one user -‐ Shared by all users Server-‐Side -‐ Reduces server load -‐ Faster turnaround for response -‐ Shared by all users 7
- 8. Caching - Expiry • Cache Expiry Controlled by Headers – HTTP/1.0: Expires – HTTP/1.1: Cache-Control • ETAG/Last-Modified Enables Conditional GET – Fetch Resource “If-Modified-Since” • CDN/Server Cache can be manually purged 8
- 9. Stale Cache • Outdated data in cache – Affects Browser Cache the most • Versioning – Add a version number to the filename – Change the version when the file changes – Unique filename = long caching – stale cache file.v1.js file.v2.js var today = “11/10/26” var today = “11/10/27” 9
- 10. Cache Sizes - Desktop • Ranges from 75MB to 250MB • Fits about 90-300 pages – Average desktop page size is ~800 KB • Cycles fully every 1-4 days – Average user browses 88 pages/day 10
- 11. Cache Sizes - Mobile • Ranges from 0 MB to 25MB • Fits about 0-60 pages (Average size ~400KB) • Memory Cache a bit bigger, but volatile 11
- 12. Conclusion • Caching is useful and important • Cache sizes are too small – Especially on Mobile • Cache hasn’t evolved with the times – Stopped evolving with HTTP/1.1 in 2004 • Browser Cache evolved least of all – Browsers adding smart eviction only now – Still no script interfaces for smart caching 12
- 13. Scriptable Cache
- 14. Scriptable Browser Cache - Concept • A cache accessible via JavaScript – Get/Put/Delete Actions • What is it good for? – Cache parts of a page/resource – Adapt to cache state – Load resources in different ways • Why don’t browsers support it today? – Most likely never saw the need – Useful only for advanced websites – Not due to security concerns (at least not good ones) 14
- 15. Intro to HTML5 localStorage • Dedicated Client-Side Storage – HTML5 standard – Replaces hacky past solutions • Primarily used for logical data – Game high-score, webmail drafts… • Usually limited to 5 MB • Enables simple get/put/remove commands • Supported by all modern browsers – Desktop: IE8+, Firefox, Safari, Chrome, Opera – BB 6.0+, most others (http://mobilehtml5.org/) 15
- 16. Step 0: Utilities var sCache = { … // Short name for localStorage db: localStorage, // Method for fetching an URL in sync getUrlSync: funcHon (url) { var xhr = new XMLH;pRequest(); xhr.open( ‘GET’, url, false); xhr.send(null); if (xhr.status==200) { return xhr.responseText; } else { return null; } } …} 16
- 17. Step 1: Store & Load Resources var sCache = { … // Method for running an external script runExtScript: funcHon (url) { // Check if the data is in localStorage var data = db.getItem(url); if (!data) { // If not, fetch it data = getUrlSync(url); // Store it for later use db.setItem(url, data); } // Run the script dynamically addScriptElement(data); } …} 17
- 18. Step 2: Recover on error var sCache = { … runExtScript: funcHon (url) { // Check if the data is in localStorage var data = db && db.getItem(url); if (!data) { // If not, fetch it data = $.get(url); // Store it for later use try { db.setItem(url, data) } catch(e) { } } // Run the script dynamically addScriptElement(data); } …} 18
- 19. Step 3: LRU Cache – Cache State var sCache = { … // Meta-‐Data about the cache capacity and state dat: {size: 0, capacity: 2*1024*1024, items: {} }, // Load the cache state and items from localStorage load: funcHon() { var str = db && db.getItem(“cacheData”); if (data) { dat = JSON.parse(x); } }, // Persist an updated state to localStorage save: funcHon() { var str = JSON.stringify(dat); try {db.setItem(“cacheData”, str); } catch(e) { } }, … } 19
- 20. Step 3: LRU Cache – Storing items var sCache = { … storeItem: funcHon(name, data) { // Do nothing if the single item is greater than our capacity if (data.length > dat.capacity) return; // Make room for the object while(dat.items.length && (dat.size + data.length) > dat.capacity) { var elem = dat.pop(); // Remove the least recently used element try { db.removeItem(elem.name); } catch(e) { } dat.size -‐= elem.size; } // Store the new element in localStorage and the cache try { db.setItem(name, data); dat.size += data.length; dat.items.push ({name: name, size: data.length}); } catch(e) { } } … 20
- 21. Step 3: LRU Cache – Getting items var sCache = { … getItem: funcHon(name) { // Try to get the item var data = db && db.getItem(name); if (!data) return null; // Move the element to the top of the array, marking it as used for(var i=0;i<dat.items.length;i++) { if (dat.items[i].name === name) { dat.items.unshiw(dat.items.splice(i,-‐1)); break; } } return data; } …} 21
- 22. Post Step 3: Revised Run Script var sCache = { … runExtScript: funcHon (url) { // Check if the data is in the cache var data = getItem(url); if (!data) { // If not, fetch it data = $.get(url); // Store it for later use storeItem(url, data); } // Run the script addScriptElement(data); } …} 22
- 23. Step 4: Versioning // Today: File version 1 sCache.load(); sCache.runExtScript(‘res.v1.js’); sCache.save(); // Tomorrow: File version 2 sCache.load(); sCache.runExtScript(‘res.v2.js’); sCache.save(); // Old files will implicitly be pushed out of the cache // Also work with versioning using signature on content 23
- 24. What Have We Created So Far? • Scriptable LRU Cache – Enforces size limits – Recovers from errors • Dedicated Cache – Not affected by browsing other sites • Robust Cache – Not affected by Mobile Cache Sizes – Survives Power Cycle and Process Reset • Still Has Limitations: – Only works on same domain – Resources fetched sequentially 24
- 25. Step 5: Cross-Domain Resources • Why Cross Domain? – Enables Domain Sharding – Various Architecture Reasons • Solution: Self-Registering Scripts – Scripts load themselves into the cache – Added to the page as standard scripts – Note that one URL stores data as another URL h;p://1.foo.com/res.v1.js h;p://1.foo.com/store.res.v1.js alert(1); sCache.storeItem( ‘h;p://1.foo.com/res.v1.js’, ’alert(1)’); 25
- 26. Step 6: Fetching Resources In Parallel <script>sCache.load()</script> <script> // Resources downloaded in parallel doc.write(“<scr”+”ipt src=‘h;p://foo.com/store.foo.v1.js’></scr”+”ipt>”); doc.write(“<scr”+”ipt src=‘h;p://bar.com/store.bar.v1.js’></scr”+”ipt>”); </script> <!-‐-‐ Scripts won’t run unHl previous ones complete, and data is cached -‐-‐> <script>sCache.runExtScript(‘h;p://foo.com/foo.v1.js’); </script> <script>sCache.runExtScript(‘h;p://bar.com/bar.v1.js’); </script> <!-‐-‐ Note the different URLs! -‐-‐> <script>sCache.save();</script> 26
- 27. Step 6: Parallel Resources + Cache Check var sCache = { … loadResourceViaWrite: funcHon (path, file) { // Check if the data is in the cache var data = getItem(url); if (!data) { // If not, doc-‐write the store URL doc.write(“<scr”+”ipt src=‘” + path + “store.” + file + // Add the “store.” prefix “’></scr”+”ipt>”); } } …} 27
- 28. Step 6: Parallel Downloads, with Cache <script>sCache.load()</script> <script> // Resources downloaded in parallel, only if needed sCache.loadResourceViaWrite("h;p://foo.com/”,”foo.v1.js”); sCache.loadResourceViaWrite("h;p://bar.com/”,”bar.v1.js”); </script> <!-‐-‐ Scripts won’t run unHl previous ones complete, and data is cached -‐-‐> <script>sCache.runExtScript(‘h;p://foo.com/foo.v1.js’); </script> <script>sCache.runExtScript(‘h;p://bar.com/bar.v1.js’); </script> <!-‐-‐ Note the different URLs! -‐-‐> <script>sCache.save();</script> 28
- 29. What Have We Created? • Scriptable LRU Cache – Enforces size limits – Recovers from errors • Dedicated Cache – Not affected by browsing other sites • Robust Cache – Not affected by Mobile Cache Sizes – Survives Power Cycle and Process Reset • Works across domains • Resources downloaded in parallel 29
- 30. Understanding localStorage Quota • Many browsers use UTF-16 for characters – Effectively halves the storage space – Safest to limit capacity to 2 MB • Best value: Cache CSS & JavaScript – Biggest byte-for-byte impact on page load – Lowest variation allows for longest caching – Images are borderline too big for capacity • Remember: Quotas are per top-level-domain – *.foo.com share the same quota 30
- 32. Adaptive Consolidation • Fetch Several Resources with One Request – Store them as Fragments • Adapt to Browser Cache State – If resources aren’t in cache, fetch them as one file – If some resources are in cache, fetch separate files – Optionally consolidate missing pieces h;p://1.foo.com/foo.v1.js h;p://1.foo.com/store.res.v1.js alert(1); sCache.storeItem(‘/foo.v1.js’, ’alert(1)’); h;p://1.foo.com/bar.v1.js sCache.storeItem(‘/bar.v1.js’, ’alert(2)’); alert(2); 32
- 33. Adaptive vs. Simple Consolidation - #2 • User browsers Page A, then Page B – Assume each JS file is 20KB in Size OpGmizaGon Total JS Requests Total JS Bytes None 3 60KB Simple ConsolidaHon 2 100KB AdapHve ConsolidaHon 1 60KB Page A Page B <script src=“a.js”></script> <script src=“a.js”></script> <script src=“b.js”></script> <script src=“b.js”></script> <script src=“c.js”></script> 33
- 34. Adaptive vs. Simple Consolidation - #2 • User browsers Page A, then Page B – Assume each JS file is 20KB in Size OpGmizaGon Total JS Requests Total JS Bytes None 4 80KB Simple ConsolidaHon 2 140KB AdapHve ConsolidaHon 2 80KB Page A Page B <script src=“a.js”></script> <script src=“a.js”></script> <script src=“b.js”></script> <script src=“b.js”></script> <script src=“c.js”></script> <script src=“c.js”></script> <script src=“d.js”></script> 34
- 35. Adaptive vs. Simple Consolidation - #3 • External & Inline Scripts are often related • Breaks Simple Consolidation • Doesn’t break Adaptive Consolidation StoreAll.js a.js var mode=1; sCache.storeItem(‘a.js’,’var mode=1;’) sCache.storeItem(‘b.js’,’alert(userType);’) b.js alert(userType); OpHmized Page: Page: <script src=“a.js”></script> <script>sCache.runExtScript(‘a.js’)</script> <script> <script> var userType = “user”; var userType = “user”; If (mode==1) userType = “admin”; If (mode==1) userType = “admin”; </script> </script> <script src=“b.js”></script> <script>sCache.runExtScript(‘b.js’)</script> 35
- 36. Robust Prefetching • In-Page Prefetching – Fetch CSS/JS Resources at top of page, to be used later • Next-Page Prefetching – Fetch resources for future pages • Robust and Predictable – Not invalidated due to content type change in FF – Not invalided by cookies set in IE – Not reloaded when entering same URL in Safari – … 36
- 37. Async JS/CSS • Async JS: Run scripts without blocking page – Doable without Scriptable Cache – Scriptable Cache allows script prefetching – Eliminates need to make fetch scripts block • Async CSS: Download CSS without blocking – CSS ordinarily delay resource download & render – You can’t always know when a CSS file loaded – Scriptable Cache enables “onload” event – Can still block rendering if desired 37
- 38. Summary • Caching is good – you should use it! • Scriptable Cache is better – More robust – More reasonably sized on Mobile – Enables important optimizations • The two aren’t mutually exclusive – “store” files should be cacheable – Images should likely keep using regular cache 38
- 39. Or… Use the Blaze Scriptable Cache! • Blaze automates Front-End Optimization – No Software, Hardware or Code Changes needed – All the pitfalls and complexities taken care of • Blaze optimizes Mobile & Desktop Websites – Applying the right optimizations for each client See how much faster Blaze can make your site with our Free Report: www.blaze.io Contact Us: contact@blaze.io 39
- 40. QuesGons? DIY Scriptable Cache Guy Podjarny, CTO guypo@blaze.io twitter: @guypod