Drupal CMS 2.0 Performance Testing

Gander: PHPUnit Performance Testing for Drupal

Drupal core’s performance tests allow PHPUnit assertions to be made for both back and front end performance metrics, including the number and size of CSS and JavaScript files, as well as the number of database queries and cache operations. Between these metrics, we get a high level overview of how a site performs. Additionally, timings from tests, which can vary based on external factors and aren’t precise enough to assert against exact values within a PHPUnit test, are sent to an Open Telemetry Grafana/Tempo dashboard. Gander is used to test Drupal Core, Drupal CMS and site templates, contributed modules such as the popular redirect module, and real sites via Drupal Test Traits integration, such as london.gov.uk

We added performance testing while Drupal CMS 2.0 was in alpha and Drupal Canvas was in release candidate, and that helped uncover a few issues.

Front End Performance

Drupal CMS’s new Mercury theme is based on Tailwind CSS, which allows for a lot of customization without having to write new CSS. While this should allow Drupal CMS theming to be very flexible, it does involve serving quite a lot of CSS out of the box.

When testing the Byte site template, we wrote a performance test that covers one of the more common front end performance problems that sites face.

Drupal’s CSS and JavaScript aggregation combines smaller files into minified larger files, to reduce HTTP requests and filesize. This is an effective strategy for most Drupal libraries and components, which often include many small CSS and JavaScript files attached to specific page elements, and which may only appear on specific pages or for users with certain permissions, etc. Serving these files on demand reduces unused CSS and JS when those elements aren’t there.

However, when a large CSS or JavaScript file is included on every page (or most pages), that file can be duplicated between different asset aggregates, meaning the same visitor downloads it over and over again if they visit multiple different pages with slightly different combinations of libraries. Our test shows over 2mb of CSS being downloaded across six pages, each page has around 350kb of CSS individually.

We filed an a issue and (Merge Request) MR against the Mercury theme to exclude the main.min.css file from minification (because it’s already minified, avoiding wasted CPU and memory trying to minify and already minified file) and aggregation, so that only a single copy is downloaded per visitor. This issue has already been committed and the improvement should be visible in the performance test for Byte once there’s a new release.

While we were looking for the source of those large CSS files in Chromium devtools, we also noticed some chained HTTP requests for both fonts and JavaScript files and opened issues to document both. When the browser has to first parse a CSS or JavaScript file before loading fonts or another file, this requires at least two round trips from the browser before the chained request can be served, which can significantly affect page loading performance.

Byte also includes a webform newsletter signup on the front page. We noticed that the Webform module attaches a details library to every page showing a webform , whether the webform will render a details element or not. Because the details library depends on jQuery, this adds around 100kb of JavaScript for anonymous users that otherwise might not be needed. This discovery is an example of how adding performance tests for Drupal CMS can test not only Drupal CMS itself, but also many of Drupal’s most popular contributed modules, finding performance issues that can affect many sites in the wild.

Canvas

Our original Drupal CMS 1.0 tests cover both anonymous and authenticated visitors. For Drupal CMS 2.0 we noticed that authenticated visitor page requests required many more database queries and cache operations than Drupal CMS 1.0. We tracked this down to the Canvas module which sets max_age: 0 when rendering its ComponentTreeItemList field in some circumstances, disabling the dynamic page cache for any requests that render Canvas’ page entity type. We also noticed that the tree rendering itself is quite expensive although this may become less of an issue once render caching is fixed.

These were the only backend performance issues we noticed, so assuming they’re fixed prior release, back end performance should be broadly similar between Drupal CMS 1.0 and 2.0.

Conclusion

These findings show how important it is to validate performance before releasing code to production, so that unexpected regressions in application or browser performance can be caught and fixed before reaching site visitors. At the time of writing, several of the issues we opened already had MRs attached or had already been committed by the Drupal CMS team. Drupal’s Gander testing framework, originally developed by Tag1, provides an ideal mechanism to add continual testing with repeatable results to any kind of Drupal project.

Lear more about website performance management and let us know how we can help!

Image by Lalmch from pixabay.