Shall we just get a theme?

With good reason, pre-built and packaged WordPress themes have emerged as a solid entry-level web solution for small business. We have began to see larger companies (even some marketing agencies) make use of them. They are making an appearance due to an apparently low price point, speed of development, easy setup, easy maintenance and managed updates.

We now consider the ‘theme’ option as part of any route-to-market for clients requiring a fast, low-priced solution. It’s smart and often fit-for-purpose. Not every small bakery, corner shop or Italian restaurant can justify commissioning custom design and layouts. Simple. However, we now have a wealth of experience using and maintaining pre-built themes to inform our proposals; where they work, and where they just cause a headache.

  • Custom development and scalability: Custom development within pre-built theme environments (depending on the quality of the themes codebase) can be difficult and time consuming. If you can’t find what you need out-of-the-box, find another theme.
  • Longevity: This be improved with frequent updates, however we find that themes can be quickly out-grown. Requirements change and themes become unsuitable (More often than not resulting in a custom theme development).
  • Quality of code (search and accessibility): These themes are generally bloated to accommodate the diversity of their use-cases, while giving users too much control over semantic HTML. Visual composers are a nightmare and although seemingly powerful for the end-user, they are not yet mature enough to ensure they produce good semantic HTML regardless of technical ability. This for us in many cases is a showstopper. Google penalise it, mainly because we are in turn penalising users requiring assistive devices such as screen readers with non sensical HTML.

Themes can be a brilliant starting point for a small business testing the water. My opinion is that this should be limited to proof-of-concept. I think many excuse them as being highly efficient and customisable. ‘No one will know’ – they will when your page takes 10 seconds to render because your theme has loaded every single JavaScript library known to man.


Hard learnt lessons

If you have to…

  • Make sure you at least have a good starting point. Put the theme examples through pingdom and page speed. If they can’t make the example score high you’re never going to.
  • Make sure it does everything you want and that is in your roadmap for the next year. Extending/amending functionality will be costly.

But really…

  • Avoid themes if you are able to shoulder the investment of a custom development – do it once, do it right. Its likely to cost you less in the long run.
  • If you cannot avoid them, you need proper training. You need to know by clicking h2 in the “Headings” drop down on the editor, you will be making a second level heading tag and should be aware of its semantic implications in context of the page. Unfortunately no visual editor in WordPress today is going to say “hang on, h2? where’s your h1!?”.

As a front-end developer, these WordPress themes bother me. They remove the control I need to serve a lean, semantically sound accessible web page that performs well in search and feels nice to use. They are innately bloated and therein often sluggish. If I were working for an agency that builds custom wordpress themes for clients (as I do), I would feel the need to do better (as we have).