Goal:
Make denver2012 site navigation easy and fast and mitigate against slow or non-existent net connection.

Proposal:
Store heavy elements in the appcache and utilize localstorage for full HTML.

Investigate using JSON responses for updating schedule and reducing amount of data over the wire.

Comments

coltrane’s picture

Crell has a sandbox project for generating a appcache manifest file http://drupal.org/sandbox/Crell/1284648

What are the steps/modules we can leverage for these goals?

rupl’s picture

Appcache

Dependencies:

  • The sandbox itself relies on html5_tools to inject the manifest attribute into the <html> tag.
  • If html.tpl.php is overridden, we need is the DOCTYPE of the current theme to be HTML5.

Crell had some problems with the caching of HTML to the point that he's unconvinced that manifest will work at all for a dynamic CMS like Drupal. While it was originally designed for web apps with finite states, I still think we could use it to minimize asset requests. I'm working on a reduced test case for the schedule, and will keep this issue updated with my progress.

appcache has good support where it counts (mobile browsers).

Web Storage

LocalStorage is not too complicated, we just need to write some JS to leverage it. Templating the JSON feed will be trickier than writing some fallback logic for the stored data.

Another feature not previously discussed could be user schedule. Assuming we did have a data feed, we could possibly store a queue of flags that are compared to the feed, and users could view a personal schedule without involving Flag module.

Web storage has broad support

coltrane’s picture

"we could use it to minimize asset requests"

Meaning non-HTML assets?

Despite the issues I think we could apply Drupal paths to the cache with appropriate planning and handling.

Issues with appcache:

  1. implicit caching: the page referencing the manifest file is cached, regardless of whether it's specified within the manifest file itself
  2. aggressiveness: the manifest file must be updated for any cached page to be refreshed
  3. upon updated manifest file the browser will request all cached resources automatically

Example of (3), when a user refreshes the schedule (program/schedule) when there has been a manifest file update: first request will respond with resources from the browser cache, the updated manifest file will be detected and retrieved, all cached resources will then be downloaded in the background so user will have to refresh the schedule again to see the updates. The UpdateReady event can be detected with Javascript and then the browser could tell the user to refresh, or whatever.

On (1) and (2), if the entire site is cached (as when the manifest file is included on every page request -- regardless of what's specified in the cache itself), then we'll have to build in manifest file refresh for anything that could get updated.

I'm not too worried about issue (3) yet. It's 1 and 2 that are a bigger deal. If we limited the manifest file reference to any path under /program (for example) it would cache the schedule and session nodes. But, if a user updates their session node which refreshed the manifest file it will cause users to request every cached page. When they've visited a lot of session nodes that will mean new requests for all of those pages, not a good situation.

It might be better to move the schedule to a special path and include session descriptions within and use JS to show/hide them. Once a day, or if a session move requires it, we manually force a manifest file refresh.

ericduran’s picture

If there somewhere this can be tested?

/me is curious.

coltrane’s picture

@ericduran I'll get something setup soon

coltrane’s picture

An appcache for program/schedule/* is now setup on http://mobile-denver2012.redesign.devdrupal.org/ (basic auth drupal:drupal).

Visit any of the schedule pages and they'll be stored in the appcache. Sessions won't be. Use chrome and hit chrome://appcache-internals/ to view and remove the entries.

This is using forthcoming path-specific patch for http://drupal.org/sandbox/Crell/1284648

coltrane’s picture

Status: Active » Needs review

http://mobile-denver2012.redesign.devdrupal.org/program/schedule is updated to cache each day of the schedule as well as backend patches to manifest that are in the http://drupal.org/sandbox/Crell/1284648 queue

Graeme Blackwood’s picture

Works very well! I'd really like to see the CSS cached as well, but I can only assume that will be absolutely fine. Very cool

coltrane’s picture

Hmmn, if we have proper header set for CSS/JS then it should be served from regular browser cache I think.

Created #1449460: Test performance and caches of site to track work on caches (and general performance).

Crell’s picture

The deal-breaker issue for Manifest is that it always caches the HTML page you're on as a static resource. Drupal pages are rarely entirely static resources. There is no way around that. I am therefore unconvinced that Manifest is ever useful for a general Drupal site.

It would be useful if you could confine it to one single page served up by Drupal only, with that page intended to be used as an offline app that just happens to be built off of Drupal. But really, Manifest is a terrible solution for improved caching; if you're not serving up a full-on app, I would not recommend using it.

Graeme Blackwood’s picture

Yes it's certainly showing its failings! The CSS/JS is definitely not caching for me – is there a way to write the CSS and JS into the manifest dynamically? Guess it would need to be the aggregated versions, which may be interesting.

Graeme Blackwood’s picture

Issue summary: View changes

general goal

Crell’s picture

Issue summary: View changes
Status: Needs review » Closed (won't fix)

Long since irrelevant.