Since the election, I’ve been doing some light consulting for a few area non-profits. On a few of these jobs, the discussion’s invariably turned to the question of “theming”: namely, whether a client should work on creating a custom design for their CMS, like we did for The Toast, or if they should simply install an off-the-shelf theme, and use that to publish their content.

Now, the first time I had that discussion, I could feel my opinions bubbling up, perhaps reacting as many designers reading this might: of course we should invest in a full redesign! There’s value in having a design tailored to the organization’s mission, to their brand, to their audience. Given that, there’s value in investing time and energy in a design that reflects their unique needs.

The thing is, some of these non-profits have dedicated web/IT staff; many, however, do not. In fact, some organizations don’t have the time to consider a full redesign: they offer critical services to underserved communities, often on a considerably constrained budget. Between the urgency of their work and the size of their resources, spending months on a full redesign isn’t something they can afford to do. Given that, a free theme for, say, WordPress can yield a considerable amount of value, especially to budget-constrained organizations. They can launch their redesign more quickly, and continue reaching the people who need their information most.

This being web design, of course, no decision comes without caveats.

On one of these projects, the client had picked a dozen or so prospective themes, which I offered to audit. While most of the designs touted their responsive layouts, they often had a raft of issues on devices that were older than a year or so. (An issue Stephanie Rieger’s touched on before.) If someone visits a site using hardware that’s more than a year old, they’re left with a broken, inaccessible experience.

Equally troubling was how slow most of these themes were. I ran the themes’ demo pages through WebPageTest (thanks to Andy Davies’ 💖 WebPageTest Bulk Tester 💖), and the results were surprising: on a 3G connection, the slower themes I tested took anywhere from 45-90 seconds for any content to appear. In other words, the pages took roughly a minute before they were usable. From that point, additional code would continue to download, adding to the already-high cost of downloading that page over a metered data connection.

Now, not all the themes were this slow and heavy, of course. Some were responsive and fast. (As all responsive sites can — and should — be.) And this is a dozen or so themes I tested out of the thousands available for this particular CMS; hardly an exhaustive, scientifically rigorous survey. But I thought it was interesting to contrast this against what I’d heard from these organizations, given that they serve at-risk communities. It’s not uncommon for me to hear that their audiences hold onto their phones longer than you and I might, or that cheaper, limited data plans are quite popular. “So why,” you might ask, “did they choose themes that were so slow?”

Well, of the organizations I’ve spoken with recently, I’ve found these two things to be true:

  1. Organizations aren’t necessarily aware they need to care about site speed.
  2. Given the time and resources available to them, organizations can’t always prioritize site speed over other business needs.

These two items aren’t unique to non-profits, of course. But I think they point to a huge opportunity here for the broader web community. If we’re designing or developing web software for general use, how can we make it so that organizations don’t have to worry about how fast it is?

A couple ideas come to mind:

  1. There’s an opportunity for CMS vendors to showcase performance best practices in their documentation. For example, WordPress’ documentation for theme and plugin development focus on layout and code standards, but don’t seem to suggest methods for, say, responsibly loading CSS and JS assets. By contrast, Drupal’s theme documentation is framed by “a high-level principle” to “not load every assets on every page.”
  2. Many of these CMS themes and plugins are distributed through galleries and marketplaces. For example, WordPress has their own official Theme Directory and Plugin Directory, but there are many, many third-party clearinghouses out there. I’d love to see performance added as a ranking factor on these sites, even if it’s to flag “fast” themes/plugins against “slow” ones.

I should acknowledge this is way outside my bailiwick — my practice usually involves full, custom redesigns. Given my relative lack of familiarity with open source themes, it’s highly likely there are folks already thinking about this particular problem. (I’ll try to add any names I find to this post; do email me if you have any suggestions.) And I know there are a number of plugins available to help mitigate performance issues on some of these platforms. But even with all of that, I think a broader discussion about the health of our free products could help our clients — be they mission-driven organizations, or for-profit corporations — better deliver faster, more accessible experiences.

Update: A few folks have already started sharing excellent resources. I’ll keep a running list here, with the newest entries at the top.