Most designers and developers have got their fair share of horror stories about clients finding cruel and unusual ways of mangling the CMS that they’ve spent months on setting up.
For instance, the other day I found myself cursing someone who had added enormous images to an article - a 1200 x 799px JPG weighing in at 850k, resized via the WYSIWYG to be 240 x 160px.
It was the kind of frustrating facepalm moment that’s all too common for anyone who cares about web performance. It wasn’t the first, I’m sure it won’t be the last, and my colleagues and I briefly enjoyed chortling patronisingly.
But a lot of those horror stories miss the point entirely.
For one thing, if the content editor has resorted to some mind-meltingly bizarre workaround, it’s a sign that the way the site has been set up doesn’t match their requirements. Let’s not get started on “requirements” gathering, but suffice to say that Heath Robinson content is generally a sign of a problem somewhere.
The people who use a CMS aren’t technical - they’re content editors, not developers. They shouldn’t need to know the myriad reasons why WYSIWYGs are a bad idea - the CMS should “just work”™. Their job is to understand language and how to use it effectively
The CMS should have sensible defaults that make the content workflow as easy as possible, and steer the content editors away from doing things that will hurt their site, whether that’s in terms of performance, accessibility or legal compliance.
For the specific example of bloated images in a Drupal site, there are modules like ImageAPI Optimize that can help with this.
As I keep being reminded, in an ideal world there would be no such thing and there wouldn’t be enormous body fields that can be filled with big blobs of crazy markup generated by a WYSIWYG - editors would be able to stick to what they can do best, and focus on what should be the most important thing - the content.