In Drupal 8, we’ve significantly improved the way pages are rendered. This talk explains the entire render pipeline, in some detail.

But it also covers:

• render caching — blocks and entities are now render cached automatically!
• cache tags — finally we have the cache invalidation system we’ve always needed!
• assets — only the necessary assets are loaded anymore, thanks to asset dependencies!
• bubbling — rather than relying on global statics that broke caching, we now correctly bubble up all attached metadata — no more frustrations!

Besides that, I also cover a few of the most interesting new possibilities in Drupal 8:

• anonymous page loads: invalidating Varnish/CDNs with perfect precision
• authenticated page loads: not completely regenerated on every page load, but assembled from render cached parts
• alternative render strategies, like Big Pipe

Update (November 14, 2014): since I gave this talk, https://www.drupal.org/node/2352155 was committed, so this talk is now indeed a comprehensive, correct talk about the finalized Drupal 8 render pipeline!

Update (March 20, 2015): there is now an official Drupal 8 documentation page: https://www.drupal.org/developing/api/8/render/pipeline.

Together with Fabian Franz & Marco Molinari from Tag1 Consulting, I had a session about render caching in Drupal 7 and 8 at DrupalCon Amsterdam.

Marco explained the render performance problems in Drupal 7, the way the Render Cache module for Drupal 7 mitigates these performance problems as well as possible in Drupal 7, but can’t solve everything, because the necessary mechanisms to solve it properly aren’t available there. I explained how cache tags in Drupal 8 have fixed this problem in Drupal 8 completely. And Fabian demonstrated very cool things for the near future: different rendering strategies, such as Facebook’s Big Pipe — which already works in the render_cache module for Drupal 7, and will only be simpler to implement in Drupal 8!

For this short talk, I chose two particular improvements in Drupal 8 that will make a big difference for future Drupal sites’ performance and ops (infrastructure requirements).

The addition of cache tags is the most important new feature to have a huge impact on back-end performance: it allows for much smarter/better cache invalidation, and hence through better cache hit ratios help increase performance and reduce infrastructure requirements.

On the other hand, the move towards a pluggable asset optimization system (instead of the non-pluggable one in Drupal 7) allows for much greater flexibility in adjusting the asset optimization pipeline to suit a specific site’s needs. Changing the JS minifier or even the complete asset optimization pipeline will become easy, whereas in Drupal 7 you’d need incredibly intricate knowledge of other Drupal internals — making such front-end performance changes much more expensive than they should be.

Neither helps current production sites on Drupal 7 since they’re major improvements in Drupal 8, but both solve fundamental flaws in previous versions, so they will probably make you (even more) excited about Drupal 8!

Note: these slides are a shortened version of my Building really fast websites with Drupal 8 talk — but presented from a different angle and with a different focus.

We had two CKEditor Q&A BoFs at DrupalCon Prague: one for site builders, one for developers. They both used the same presentation to get everybody up to speed, but we applied different nuances.

This was presented together with the CKEditor team.

• If you’re a site builder, see the Q&A for site builders BoF!
• If you’re a developer, see the Q&A for developers BoF!

Note: the slides including screenshots and screencasts are on GitHub at https://github.com/wimleers/talk-ckeditor-drupal8-qa, feel free to reuse them in your blogs & talks!

Demo

1. Why the Drupal 7 modules (CKEditor/WYSIWYG modules) sucked and the Text Editor/CKEditor modules in Drupal 8 rock 2. How to enable CKEditor for a text format. 3. How to configure CKEditor, and how that UI automatically updates your filter settings. 4. The things CKEditor can do out of the box (Advanced Content Filter, image uploading, image alignment and captioning, in-place editing, and so on). 5. How Advanced Content Filter prevents crappy HTML. 6. The things CKEditor can do with additional configuration (site-specific “styles” for content e.g. for callouts). 7. The things CKEditor can do if you install additional plugins. 8. How Drupal 8’s caption filter plus the corresponding CKEditor widget provide the end user with a great UX, yet with clean, non-blobby content in the database. 9. CKEditor plugin demos that show the range of things you can achieve with CKEditor.

Q&A

After that, we opened the floor to any and all questions you might have.

---

Were present to answer questions:

• Wim Leers, who was the liaison between Drupal and CKEditor, and led the integration
• Frederico Knabben, CKEditor founder/project lead, CKSource owner
• Wiktor Walc, CKSource CTO, worked on CKEditor modules for ages
• Piotrek Koszuliński, CKEditor developer, developed the CKEditor Widgets system and worked on the Advanced Content Filter system and pasting support
• Olek Nowodziński, CKEditor developer, worked on the Advanced Content Filter system, HiDPI (retina) support and many parts of CKEditor

Drupal 8 is going to have better front-end performance for anonymous users out of the box: it is now smart enough to no longer load unnecessary JavaScript. It’s also (finally!) going to cache all entities efficiently, so that it doesn’t waste time rerendering the same content over and over again.

Because less time needs to be spent on generating the HTML, the page will show up faster on visitors’ devices — also mobile devices.

However, you of course still want pages to be personalized. Different visitors have different permissions (and hence different contextual links), different interests (and hence have “new” or “updated” indicators in different places), and so on. In Drupal 8, we’ve introduced the necessary foundations to easily serve the same HTML (well, >90% the same — i.e. the most expensive parts), yet still personalize the page by using client-side caching (localStorage/sessionStorage) in combination with clever client-side cache invalidation.

Furthermore, we finally have pluggable CSS and JavaScript optimization (aggregation), where you can easily plug in a specific JS minifier, or data-mining-applied-to-visitor-navigation-paths-powered CSS/JS grouping (to calculate globally optimal groups)!

The end result: really fast websites, with superb perceived performance!

Note: where possible, I’ve explained how to achieve the same in Drupal 7.

At DrupalCon Portland, I presented together with fellow Acquia Spark team member Jesse Beach on the accessibility improvements that we helped bring to Drupal 8. See http://portland2013.drupal.org/node/2158.

---

Drupal 8 will be the most accessible version of Drupal yet. We are expanding the foundational HTML markup support into APIs that make it easy to express the state of the page components, not just their properties. One example is Drupal.announce, which passes strings to an ARIA-live region to be read by a speaking User Agent. Another is simple management of tab ordering for constrained page navigation by keyboard (Drupal.TabbingManager). And we intend that these APIs be utilized throughout Drupal core and contrib.

As front-end developers, we are well familiar with oft-touted techniques of visual presentation — layouts, grids and typography to name a few. In this session, we will make the case for the aural user interface. Our pages should be accessible just as well by sound as they are by sight. The aural UI cannot be an afterthought. It must be designed, iterated and tested like any other UI.

Drupal 8 will provide the tools to build amazing aural UIs. Find out how you can incorporate these techniques into your modules so that your work will be accessible to the widest possible audience.