Evolving the Customizer

The Customizer is great. I’ve been working in and around it to offer site customization features to our WordPress.com users since it launched with 3.41, coinciding with when I joined Automattic on Team Custom. We’ve especially used it to build great tools as part of the Custom Design upgrade, but as we’ve pushed the boundaries of what awesomeness we can unlock for our users, certain aspects of the Customizer have started to create roadblocks for us. Some of these are addressable, and some probably aren’t.


The Customizer doesn’t work on a phone/small screen. Anyone who thinks this isn’t a dealbreaker is just wrong. The UI was designed for the desktop web. This could possibly be addressed in core, but it will require a pretty fundamental rethinking of the interface.


The Customizer can get really slow. This is partly because of its two-requests-to-load model: one for the customize.php app, and one for the frontend XHR that gets injected into a preview iframe. Any slowness on your server is multiplied x2 since there are two requests that happen serially.2 We’ve seen this hit up to 60 seconds on WP.com sometimes3, with similar reports from WP.org users on underpowered hosts like GoDaddy. Some performance work could probably be done here to start fetching the frontend sooner in the customize.php load process.

Speed could possibly be better served by a more fundamental rethink: what if the user wants to start customizing from the frontend of their site and clicking Customize just transitioned you seamlessly into a customization mode via an already bootstrapped, frontend customizer app? This actually has some serious UX considerations I’ll touch on later, but the big advantage for performance is that you’re not throwing away a perfectly good DOM to get the Customizer up and running.

Speed will also be hampered as more things are put in the Customizer. Putting Widgets in there in 3.9 is a great example of this: it’s made Widgets better, but the Customizer worse. As more things are added, speed will suffer, not to mention the UX cost of dumping so much in there.

Uncanny Valley UX

You can enter the Customizer through wp-admin or the frontend of your site via a Customize link in the adminbar. In both cases, the transition begs the question: am I still where I started? Is this admin, or my site? I believe that we should optimize for the frontend flow, where the app is bootstrapped and the Customizer becomes an editing mode you can seamlessly enter. Frontend editing for appearance.

WP Tunnel Vision

One thing we’ve seen in our user testing is that users (especially new ones) don’t care about or really understand the distinction between themes and the things you can do to customize them. They just want to get their site looking the way they want it to look. Therefore, the best customizer UX would blur the line between themes and customize-able options, freely allowing you to preview different “designs” (themes) while then tweaking that theme’s options. The Customizer’s current architecture would make this impossible, as the Customizer “app” itself must do a full refresh for each theme previewed, kicking off the slow 2-request cycle.


The Customizer is the first true JS-driven feature in core.4 It reimplements a bunch of Backbone internally, since this was a release before Backbone made it into core. It’s also a JS-driven app wrapped around a PHP-only public API,5 which is I guess about what you’d expect from an early WP foray into something JS-driven. But this fundamental PHP dependency makes it basically impossible to account for a seamless switching of state while changing a previewed theme: a full page reload has to happen. If the Customizer is going to be awesome, it needs to a seamless way to customize how your site looks – themes vs theme options are just implementation details.

Also, looking forward, the Customizer itself should be a client app of WP-API. Everything related to site appearance should be an API call away, rather than the tightly coupled thing that is the Customizer. This will open the door for, say, a native Customizer on Android or iOS or some other platform that doesn’t exist yet but will be important.6

Patches Welcome

Some folks might be reading this and wondering why I’m not trying to contribute this vision to core. ‘dI love to, but I don’t think it’s possible architecturally, and particularly not in a backwards compatible manner. This is certainly a case where the optimal use-case on WP.com (new user signup, pre-picked list of themes) may not line up with the best user experience for core users. I might be wrong about this, thus this post. I would genuinely love to be wrong, but I’ve worked with the Customizer extensively over the past two years and I’m pretty sure I’m not.

  1. Actually, 3.4 dropped on June 13, 2012, but we launched the Customizer for WP.com users on May 17. 
  2. Also, since the preview iframe just gets the frontend request injected upon XHR completion, any browsers’ optimizations to do things like prefetch resources like images or DNS entries before the page has even started rendering are nullified. The frontend also tends to be the more resource-intensive side of things, which compounds the problem since it’s loaded last. 
  3. Obviously there are issues for us to address here, but the previous footnote contains some gotchas that can’t be addressed in the current architecture. 
  4. As in, without JS, it just doesn’t work. Until then, everything else in core admin worked with JS disabled. 
  5. Many aspects of the JS API are “public” in the sense that they’re not hidden inside a closure, but they are not documented anywhere on the Codex that I’ve seen. I’ve even spoken about this
  6. Maybe I will customize my blog from my fridge. 

7 thoughts on “Evolving the Customizer

  1. Pingback: Week in review: Evolving the customizer, WordPress philosophies, and more : Post Status

  2. I was never a big friend of the Customizer yet, due to most of the reasons laid out above. It’s in most cases way too slow and the user experience is not quite good.

    Preview loading in the theme lasts way too long, so users think they’ve done something wrong and lost confidence in the tool at all.

    The sidebar on the left is to small in most use cases, especially if a theme/ plugin makes extensive use of the Customizer. This leads to so many meta boxes that users get lost in the whole thing way too early.

    The overall idea of the Customizer is great and has potential. If it would be possible to address my 2 concerns above and the whole mobile issue then it could still have a bright future in my opinion.

    Liked by 2 people

  3. I think you’re right on point with your thoughts on the Customizer. Being a theme developer with themes on WordPress.com and developing themes for WordPress.org, I’ve thought extensively about how the Customizer should work and I agree, there are some things that are just plain wrong from a user experience standpoint. Additionally, the Customizer really should encompass more than just “theme customizations.” I think we need to reconsider the entire front-end of your WordPress-powered website. Ultimately, the Customizer is an intermediary in a truly user-friendly solution that includes real-time front-end content editing, widget/sidebar management, image management, etc.

    I think if we’re truly looking forward, everything should be right at the fingertips of the admin user already. Why do I have to click a poorly-placed menu item to enter “customize mode?” Why can’t I just already be in customize mode? If I just published an article and am currently viewing on the front-end of my site and notice a typo, why can’t I simply edit it right then and there and have the change pushed out to anyone who might be reading the article? New technologies like MeteorJS and AngularJS allow this type of two-way real-time data binding. Why shouldn’t WordPress allow that?

    These are good thoughts. The best way forward is to keep thinking about what users really want and figure out a way to meet them there, limitations and constraints be damned. WordPress moves like an iceberg at times, but I’d prefer to not be on the Titanic when it comes to embracing better UX.

    Liked by 2 people

  4. I think most if not all of these issues can be addressed in the Customizer in core. It’s just a matter of putting in the time and effort; we’e already starting to make iterative progress in several of these areas. But experiments can be good, and if .com ends up going in a different direction we may be able to incorporate some of the resultant ideas into the core Customizer.

    I’d also love to see user tests comparing the .com skinning of the Customizer to the core one, as I’ve heard a lot of mixed opinions about it. That along with the fact that much of .com’s implementation is tied to the Custom Design upgrade shows that perhaps .com should go in a different direction than core. I’ll point out that the core customizer does work on mobile via the “collapse” function; it wouldn’t take much to turn that into something that can be more realistically targeted for mobile users via a controls/preview toggling interface.

    For anyone who hasn’t seen it, the new “Panels” API being introduced in WordPress 4.0 should make it much easier to build more with the Customizer. Additionally, Weston Ruter has already created a core proposal for making the Customizer into an always-loaded front-end-editing mode, and I’m looking at approaches for improving the experience when the Customizer is accessed from the admin. Also, while the Customizer should not be theme-functionality-specific, it will work best in the long run in conjunction with a separate (but integrated) front-end content-editing experience.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s