Tips from the Dev Team: Using Config Split and Config Ignore to Fine-Tune Your Configuration Management Process

O8 Config Drupal

One of the many great features introduced in Drupal is configuration management. This enables developers to easily push configuration changes from their development environment to staging, then production environments. It is a robust way to ensure that all of our content types, views, menus, and other settings are correctly deployed with minimal manual work.

What is configuration and what is content?

One of the challenges with configuration management is that there can be a fuzzy line between what is content and what is configuration. Content should not be exported as configuration: Editors should be free to change that content without it being overridden when the configuration is imported again.

Some elements are easy to divide into configuration and content: A menu is configuration but menu links are content. A block placement is configuration but custom block content is content. A taxonomy vocabulary is configuration, but the term items are content.

But there are some types of elements that are a little fuzzier. Take, for example, a webform. A form is configuration, but it also has content fields such as an instructions field and thank-you message. 

On the O8 website we found that there were some configuration items that changed often on production while the marketing team did their work. Every time we pushed new configuration to production we would have to make sure to export these changes and commit them to git without accidentally overwriting the new configuration we were trying to deploy. We needed a better solution.

Developers also commonly use several utility modules while doing their work: we also need to make sure that this configuration is not enabled on production.

Luckily, there are a few additional modules we can use to solve these problems: Config Split and Config Ignore.

Using Config Split for development configuration

Config split is an excellent way to create a set of configuration that should only be enabled in certain environments. The classic use case for this is for modules and settings that are only needed for development work.

Follow these steps to implement a development-only config split:

  1. Download and install Config Filter and Config Split modules
  2. Move your main configuration directory to a subdirectory if it isn’t already in one (e.g. config/sync). Edit your settings.php file and change the update the main config directories path to the new subdirectory:

    $config_directories[CONFIG_SYNC_DIRECTORY] = '../config/sync';
  3. Create a directory for your new config split (e.g. confg/dev)

  4. Set up the config split:

    Screenshot showing the Config Split settings screen

    Make sure the machine name of your split matches the name of the folder you set up in step 3.

  5. Add your development modules to the config split settings. In this case we are going to completely split the configuration for Database Logging, Devel, Kint and Stage File Proxy modules.

    Screenshot showing the Config Split settings screen, where config items are added to the split

    As you can see, it is possible to export individual configuration items here, or even use wildcrards to select sets of configuration.

  6. To enable this split on your development environment only, add the following line to your settings.local.php file:

    $config['']['status'] = TRUE;
  7. Export your configuration using drush csex.

You should see that your development modules have been exported to the dev directory set up in step 3. A normal config export using drush cex should respect your config split, but there may be a bug with some versions of drush that prevents this from working. Always make sure to check the unchanged files list in git to make sure your dev config hasn’t accidentally been exported to the main sync directory. If it has, just run drush csex again.

More detailed instructions can be found in the Drupal documentation, including an explanation of when you could choose a Conditional Split instead of Complete Split as described above.

Using Config Ignore for items that change on production

We could have used a config split for our webforms as well, but this presented a few logistical issues. We really don’t need to enable or disable this config in certain environments - we just need to prevent it from being overwritten on production. Config Ignore is a much better fit for this purpose.

Config Ignore simply prevents configuration from being imported. The process for setting this up is simple. 

Follow these steps to implement a development-only config split:


  1. In your development site, download and install Config Ignore module.

  2. On the config ignore configuration screen, add the entries that you don’t want to ignore on import:

    Screenshot showing the Config Ignore settings page

    These machine names match the names of the yml files that are normally exported in a config export and displayed on the Configuration Synchronization screen when there are changes to import. As you can see with the webform example, you can use wildcards here.

  3. Export configuration and deploy to production. 

  4. If changes are made to the ignored configuration items, you’ll see something like this when you try to import configuration:
    Screenshot showing how ignored items appear on the Configuration Synchronization screen

What’s next for Configuration Management

The Configuration 2.0 initiative is a new effort to improve configuation management in Drupal core. Some of the work going on in that initiative will integrate functionality currently provided by config filter and config split (planned for Drupal 8.7), along with fixes for some other ongoing headaches for developers. Find out more about the Configuration Management 2.0 initiative here and here.

Clients Will Love Drupal 8 Because...

Clients Will Love Drupal

The buzz about Drupal 8 is real, and the upgrade is ready for primetime.

At ORIGIN EIGHT, we are proud to have a talented and diverse development team with lots of experience of working with client partners in a multitude of industries. We asked them what they thought clients would like about Drupal 8 and we got some enthusiastic feedback. Here is a compilation of responses that reveal concrete benefits that clients will appreciate:


Drupal 8 provides improved editorial experience, coupled with streamlined internationalization and translation. This will appeal to clients who are heavy on content, especially with an international presence and shifting the control over to editorial teams.


Drupal 8's "fast-by-default" performance improvements will allow clients to see rewards in page load times as soon as they build their D8 site. In addition, the more granular caching system will allow clients to create customized pages without sacrificing page load times.


Drupal 8 has been geared towards Responsive Design from the beginning and includes all the building blocks needed to make a Righteous Responsive Site!!!


Easier to integrate with other platforms/services
More flexible caching for better server performance
Better user interface and user experience


I think that what a client will like depends on the client and what is important to them. If they produce a lot of content, and need to manage it on a day-to-day basis, they'll appreciate the streamlined user interface and improved content management tools. If they are worried about maintaining separate dev/staging/production environments, they'll like the new configuration management. If they're worried about site speed and performance they'll like that performance has been a big focus for Drupal 8.

You could say that all clients care about these things, but I think they all have different priorities :)


Drupal 8 is more than mobile friendly, It’s mobile first--all built-in themes are responsive. Also, multilingual capabilities have been improved a lot, allowing translation of anything in the system. Performance with Drupal 8 has also been improved; basic sites can be spun up in a matter of minutes.


Drupal 8 was designed for growth. It is scalable and it allows projects to grow in the future as required. Drupal 8 = responsive + performance + scalable = the base your project needs.

With Drupal 8 you will receive constant updates, and fixing security issues and adding new functionality will be easier than ever.


So, the response from our developers is a resounding yes to Drupal 8 being a win for clients. It is rightly hailed as a ground-breaking release that offers an improved developer experience, and an enhanced platform for client partners to offer a better digital experience for site users, content creators and administrators.

If you’d like to discuss what a Drupal 8 upgrade can do for your business, please contact us. We will evaluate your site and determine if an upgrade is timely and appropriate for your organization. If you agree that it is, we can put together an appropriate action plan for you.

Contact us for a free consultation:

(612) 276-5880

Use our online contact form.

Drupal Performance Testing Case Study

Drupal Performance Boost

Recently, a client came to us asking for help with performance problems. The reported problem was simple: the homepage loaded really slowly on mobile devices! As developers, we know that bug reports frequently hide a lot of complexity. Performance problems are no different, and they can fool us, too. Site performance issues can implicate as much as, oh, ALL of the code. So, when we see a slow page, what do we try to fix? In this situation we may be tempted to just use our favorite hammer and see everything as a nail, but the real challenge is how to address specific underlying causes and make changes that will make a concrete difference, instead of blindly hammering away.

The Project

The client's site is an online news outlet focused on a particular topic/community. It features news articles, polls, image galleries, and a few types of reviews of community resources. Its revenue comes from advertising, particularly from vendors that cater to this community of people. This brings us to our first set of complications: the client wants a dynamic, complex homepage in order to attract and retain eyeballs; and also wants to display as many ads as possible. It turns out ads are bad for performance! But I'll save the debate about the merits of the Internet ad-economy for another day.

The Basics

First things first. There are a few things for which we should do blind checks, right off the bat. This is a Drupal 7 site. Is site caching turned on? Are all Views being cached? Is the database being used as the cache backend, or something fast (like Memcache or Redis)? Are most users anonymous (using caching) or logged-in (possibly not using caching)? Before digging deeper, we did a sanity check for the low-hanging fruits that are known, common pitfalls with Drupal sites (Here are some additional recommendations:

In this case, most visitors to the site were anonymous. There wasn't a lot of interactivity, and so there was not much chance that visitor behavior was triggering a bunch of costly operations based on varying queries. The site did have caching enabled, and was using a Redis backend caching. Redis is fast, so I'd expect it to be a pretty swift solution. I actually spent a little time digging into it, which was probably a bad use of time. If a speedy cache backend is in place and enabled, it's probably not the best place to start with optimization work and analysis. However, there were two Views that had caching disabled. I turned it on for those, and also enabled a sitewide minimum cache lifetime of five minutes.

Take a Step Back

Now is the time to take a deep breath. Don't start digging into the guts of Views queries or the MySQL slow query log. Don't send the client a recommendation to double the number of server nodes (well, unless the site is literally melting down at that moment). Depending on your professional background, you may be familiar with certain sets of performance problems to watch out for, and strategies to mitigate them. But now is not the time to start hammering away. Now is the time to measure.

Page Performance Hides a Lot

The web applications we write today are complicated. Content Management Systems and Platforms-as-a-Service can open up a lot of power to folks who do not have the time or resources to build that power themselves. But just because it's easier to deliver functionality doesn't mean the underlying process of building, sending and rendering that webpage is simpler. A lot of steps are hidden behind a slow page load. So, which one is going to give the most value per hour of optimization work?

The answer is to start using tools to measure what's happening. If you don't have measurements, you can't do good performance optimization work, and you can't demonstrate the value of your work, because you have nothing concrete to point to at the end of the project. What if the client says that the site is still slow? "Well, it's fast enough for me" is probably not going to fly.

In this client's case we have a hint where to focus our efforts: they specifically mentioned mobile device performance. It indicates that the client side may be the key to the problem. If your background is in PHP or other server-side stuff, all the tweaks in the world may not actually solve the problem. Without measuring to confirm where the bulk of the bad performance is occurring, we could waste a lot of time in areas that are relatively unimportant, or already well-optimized.

Measurement Tools

Here are a few measurement tools I used on this project:

  • NewRelic: NewRelic increasingly has competitors, but for PHP-based sites, it's still the best tool to start measuring both server-side and client-side performance, in the context of overall performance. NewRelic breaks both sides into several main components, and provides analysis of individual transactions/pages. It doesn't necessarily give you the "why", but at minimum it will give you helpful direction to the "what." Its Browser component conveniently breaks performance down by browser and mobile vs. desktop.
  • Chrome/Firefox developer tools/Firebug: Essential tools for doing a deep-dive into what is happening on the client-side of the website. Keep in mind that using these tools introduces a bias: you're measuring with one particular computer/browser. Don't assume that what happens on your late-model MacBook holds true for other (or even most) site users.
  • Google PageSpeed Insights: A client-side analysis that provides some recommendations, including a mobile-focused report.
  • WebPageTest: A client-side analysis that focuses a little more on the requests involved in loading the page.

What Did We Find?

NewRelic was super helpful in giving us an overview. We found:

Server-side processing did show some slowness. The APM component reported that average requests were taking around 1300ms, which is kinda slow for a site on a robust hosting platform that uses fast caching. My changes were eventually able to get these down to around 620ms.

More importantly, client-side performance was really slow. The Browser component reported that pages did not load completely in visitors' browsers until an average of 15 seconds. Some, especially mobile, visitors were taking 25 - 30 seconds to fully load a page. Whoa! This stood out as a clear, high-value target for optimization. I was eventually able get averages closer to 8-12 seconds. Still not great, but those numbers were somewhat inflated by ads on the site. Those ads are powered by 3rd party networks, which means each visitor's browser is waiting (at some point) for requests to and rendering of resources that we don't control.

What is Taking These Browsers So Long?

Another reason measurement tools are critical: your subjective experience on a particular browser is not representative. The site was loading much more quickly on my desktop browser than shown in the NewRelic averages. Google PageSpeed helped show why. It has a useful concept of the resources that must be loaded in order to display above-the-fold content. This is especially important in mobile browsers, where network speed and CPU are often not good. In the case of this client's site, a LOT of resources needed to be loaded and processed by the browser before it could show the content at the very top of the page. Fast on desktop, much slower on mobile. PageSpeed has related documentation with a lot of recommendations in this area:

In the case of this client, we found a variety of smaller problems that contributed to the mobile browser page load problem, and some solutions:

  • Blocking JavaScript that could be inlined. The browser waits while it loads external scripts in the HEAD of the browser ( Changing JavaScript to be output as inline code can cause problems. I turned this feature on specifically for the homepage, because I knew it needed to be as fast as possible, and was worth any possible debugging time. The AdvAgg module ( has a feature for inlining JavaScript on particular pages.
  • Limiting the external JavaScript that was being executed. Several third-party JS tools had been added during prior development that were no longer used, or not very important. We stripped these out.
  • Combining requests to external resources. The site was making several requests to the Google Fonts API to load custom fonts. I reduced this to just one request. And then I realized: why make this an external request at all? I used this tool to download the free fonts and changed CSS to load them from the site's server:
  • Unnecessarily complex HTML. The site was built to be mobile-responsive. However, it exclusively used CSS media queries to selectively hide elements that were not used in the mobile layout. That meant that desktop-only markup was still loaded and processed by the mobile browser. Elements hidden by CSS rules do improve mobile speed, but not as much as omitting those elements altogether. A complex set of HTML elements needed to be processed and rendered before the top of the mobile page could be displayed. Unfortunately, once the site is built, this is not an easy mess to untangle. We didn't end up getting the budget to do the bulk of that work.
  • Many CSS rules were being loaded on each page. Only a fraction of those were needed to style the homepage.
  • Lots of resource requests overall. The browser needed to request around 200 resources overall. That's a lot!

Speeding Up Resource Requests

We reduced some of the browser requests for resources like JavaScript files and CSS files, but the site still required a lot of requests in the form of images. These images were deemed essential by the client as the site needed to be visually enticing. Luckily, these images were already being provided by Drupal's image styling system, so they were appropriately sized and compressed. It was still a lot of requests. So, the question remained, how do we speed that up?

The client was already using a Content Delivery Network (CDN): Amazon's CloudFront. This provides low-latency access to static resources (like images). However, a critical limitation of HTTP 1.1 is that the browser will only request between two and six resources in parallel (ie, at the same time). Even if images are small and cached in a CDN, the browser still is going to load them in small batches until all are loaded. With about 80 images on the page, this was a problem.

We made two changes to help with the situation: domain-sharding and far-future expiration. The HTTP 1.1 limits are on a per-domain basis. By serving static assets from several domains, we allow the browser to do more work in parallel. The CDN module ( can support multiple CDN domains, so we changed CloudFront settings to add to the client's CDN account, and enabled those in the CDN module's settings. The CDN module randomly picks among the domains in serving each resource. This is domain sharding. As a result, the browser could chew through those images more quickly.

CDN also supports far-future expiration. Your CDN typically looks for a header that tells it how long it can retain a resource in its edge cache. Images, for example, typically don't change once cached (or if they do, the filename also changes). They're great candidates for being cached a long, long time. That's far-future expiration: don't expire my resources from the cache until far in the future. Expiration for particular file types is best set via your web server's configuration files.

In the client's case, however, we did not have control over the web server configuration files. The CDN module far-future expiration feature rewrites resource URLs so that they go through a special menu path that ensures the file is sent along with special headers to define cache expiration times far in the future. This mode is a little problematic (it can conflict with AdvAgg in certain ways, for example), but in our case it was the best option.

CDN Gotchas

One problem with loading resources from a different domain than your website is that you can run into browser security problems. It is no problem to load images from a different domain, but browsers will complain about web fonts, and these fonts won't work. You need to make sure you have a proper Cross Origin Resource Sharing (CORS) setup with your CDN domains for those resources to work, which can be tricky. In our case, it was further complicated by a mix of HTTP and HTTPS requests to the site. I ended up excluding web fonts from the CDN setup using the CDN module's advanced settings.

Wrapping Up and Lessons Learned

In the end, we were able to demonstrate some concrete performance gains in our measurements and the client was happy. We didn't make any recommendations that would have substantially increased the client's monthly hosting bills, because we could tell that most of the problem was on the client-side.

Of course, some entrenched problems remained that we couldn't address in the short term. If you're building a site in which mobile clients need great performance while also viewing complex, visually-rich content, then performance measurement ought to be part of the development process from the beginning. A CMS, like Drupal, makes it easy to add lots of features and put them together on a page, but automatic feature-building tools like Views, Panels and various dynamic HTML plugins for galleries and carousels often tend to output complex HTML. Any one in isolation will be fine on mobile, but throw a bunch together without incrementally measuring performance, and you won't notice what a mess you're creating. Responsive design needs to be more than about just hiding some content and changing column sizes with CSS.

In cases where we are building the site from scratch, we do the due diligence to structure it with performance optimizations in mind and we keep monitoring it as it develops. Even after the project is complete we recommend periodic performance reviews through the life of the site so that it can stay optimally tuned, and ahead of the competition.