[CM30]

The A/B testing use case is probably the one good one there, at least if you can't serve the variations on the server side. So many issues come from trying to overwrite the page without it flickering/being blatantly obvious to the user.

[csswizardry]

Honestly, I should add the point that client-side A/B testing is the devil and should be avoided in the first place.

[CM30]

Ideally it should be on the server side, so you're right there. Client side A/B testing isn't the best way to handle things.

However, it's sometimes a necessary evil due to:

1. The original company not budgeting time/effort from their existing dev teams to work on A/B testing, and wanting to outsource it instead.

2. Said company and their tech department being nervous about letting outsiders actually access the source code for their site/app.

3. Or said company wanting the analytics/features that VWO/Target/Optimisely/whatever offer, and not wanting to have code up the same analytics toolbox themself.

[csswizardry]

All three of your points are correct, so please don’t resent my response: Client-side A/B testing exists because ‘we should be able to do this without a deploy’. And they’re right.

[wizzwizz4]

But sorting all the paragraphs in alphabetical order increased reader engagement metrics! How would I ever have discovered readers wanted that without A/B testing?