Voting starts in March for the Drupal Association Board election.
Caching HTML reliably currently has several inter-related issues. This affects both caching stuff inline with the cache APIand *SI requests. The latter have their own special issues on top.
Adding stuff to HTML head
This counts for CSS/JS/page title/link tags, whatever.
Inline + *SI caching:
There's also an issue if any of this is done in an *SI callback since we currently rely on PHP to collect that information globally after rendering the rest of the page has happened (i.e.
<head> is built based on information in
For assets, at DrupalCon Munich and BADCamp we discussed rendering them as a json object with the block HTML, and then have a script loader in the parent that finds these, compares against global assests already in the page (which is in Drupal.settings now anyway), and loads them asynchronously. This bit doesn't need to be done in core, as long as aggregation itself is pluggable and the information is provided cleanly.
Some of this is discussed inhowever that's also a straight performance issue (i/o on shared filesystems, aynchronous asset generation) that's not strictly related to ESI.
Arbitrarily breaking caching of HTML by adding current user-specific markup
Modules that hook into rendering then do arbitrary things based on the global user mean that the HTML can only be cached per user. However the pipeline for rendering that HTML doesn't know it's per-user usually.is a current example that's also broken in Drupal 7 quite badly.
has further exacerbated the original bug.
Creating markup that's specific to the current request
All links generated by l() attempt to determine whether the link is "active" based on the current request which means that any markup containing rendered links can't be cached on anything but a per-page basis.
Not actually trying to cache rendered output in core
EntityNG, the new router system, menu links as entities and various other things have slowed down entity rendering and menu block generation. Two issues are open to improve caching of these. There isn't a dependency for these on the above issues (which are mostly enforcing best practices that core should already be following).