Building really fast websites with Drupal 8
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.
See https://prague2013.drupal.org/session/building-really-fast-websites-drupal-8.
This was also presented at DrupalCamp Leuven on September 14, 2013: http://leuven2013.drupalcamp.be/session/building-really-fast-websites-drupal-8. Recording available on YouTube.
It was presented again at Drupal Developer Days Szeged 2014 on March 28, 2014: http://szeged2014.drupaldays.org/program/sessions/building-really-fast-websites-drupal-8.
Comments
s/p15n/p13n/g
Hah!
Such a fail on my part :( When I decided to shorten “personalization” to p15n, I actually searched the web to confirm I was not the only one using it. I found some Adobe blog posts, such as this one, which gave me enough assurance to know it’s correct. Apparently not!
I will use “p13n” in the future :) Thanks!
I watched your presentation that you presented at DrupalCon Prague 2013.
https://prague2013.drupal.org/session/building-really-fast-websites-drup…
I must say it is a very good presentation. The issues you spoke about are very important. However, any idea if anyone is looking at improving MySQL queries?
When I use Devel to look at the query log after I load a page I noticed that the following items are taking a long time to complete.
drupal_lookup_path()DrupalDatabaseCache::getMultiple()field_sql_storage_field_storage_load()These combined issues cause my pages to take 5000 ms to 9000 ms to load. With the addition of FTB, image and JS load the page can take 9 to 12 seconds to load. This only happens when I am logged in so maybe the personalized cache you spoke of could help. (See question 2 below.)
Thanks,
Spineless
MySQL queries are definitely something that is being improved as well, but most of that will probably only happen when we’re closer to a release. Only when the most egregious performance problems have been fixed, that will be dealt with.
However, 5000 to 9000 ms to just render a page seems … very excessive. On which paths does that happen? If it’s really taking that long due to SQL queries, then we’d probably tackle that right away. Although I can’t say I’ve experienced that myself, and I develop daily in Drupal 8, on a far from beefy machine. So either your machine is very slow, or you’re working in parts of Drupal 8 that I don’t touch :) Please let me know!
The whole point of the render cache is that you simply avoid those DB queries entirely. The goal is to have just a few cache retrieval queries per page, for each of the most expensive to build parts of the page. So the problematic
field_sql_storage_field_storage_load()stuff you’ve seen should go away once we have node render caching (we already have entity render caching, but not yet for nodes…).In general: please report this in the issue queue! :) Send me the issue links, I’ll definitely follow them. We need more people who care about performance in the issue queue, so I invite you to join us in helping to improve Drupal 8’s performance!
I am working with Drupal 7 on a development machine. So I have not tried developing with Drupal 8 yet. However, the issues I am experiencing are causing me to think I should abandon Drupal all together or migrate to Drupal 8 ASAP.
My site has a number of modules I wrote which can use some improvement for sure but my site is about to be released in a big way and I need to be ready for a lot of users. Most of the content will be personalized and highly dynamic so I anticipate having very few pages that are static. Cache does not work well with changing pages. The types of changes will be mostly comments added to a discussion page. If rendering cache can cache most of the page then query the individual “new” comments then this will help and I will be happy to migrate to Drupal 8.
I will consider participating in the Drupal 8 development once I make the decission to use Drupal 8.
Thanks,
Spineless