This is the second article in a two part series on using Claude to build a reusable optimisation playbook for sitecore. In Part 1 we looked at how to identify what is worth optimising and the safe steps to actually do it. In this post we look at the tooling that makes it work in practice - a Sitecore MCP server.
The safety net - ASIS / TOBE
The thing that gives me the confidence to ship these is what we call the ASIS / TOBE comparison. Render a spread of real pages before the change (ASIS), render the exact same pages after (TOBE), then diff the two.
If they come back byte identical, then by definition you havent changed what the visitor sees - youve only changed how fast they see it. Which, when youve just moved half a components data behind a cache, is exactly the reassurance you want.
Doing that by hand is tedious though, and tedious is the first thing to get skipped under pressure. Which is where the Sitecore MCP server comes in
If you havent come across it, an MCP server effectively gives an AI assistant like Claude a set of tools to talk to a system directly. A Sitecore MCP server gives it the tools to do the things youd normally do by hand in the content editor or the admin pages - read the content tree, render a page, inspect the renderings on an item, create items, run a bit of Sitecore PowerShell. That last part is what turns the playbook from a document into something Claude can actually carry out.
Once you have the MCP server setup, a couple of the tools I leaned on most:
- A "render this page" tool (returns the server-rendered html for a given item).
- A "find rendering errors" tool (renders a page and scans it for yellow screens / null refs).
- A "get renderings" tool (tells you which renderings - i.e. which controller - are actually bound to an item).
- A "create item" / run-SPE tool (for generating test content).
Finding ASIS / TOBE examples
The first job is getting a represenative spread of pages to compare. You dont want to test against one course page and call it done - you want one of every flavour (a page with modules, one without, one with a video, an oddball legacy one, etc).
Rather than hunt for these by hand, I had Claude use the MCP to find items by template and pull back a handful of each. Then for each one it called the render tool and saved the html as the ASIS baseline.
Note: render against the published (web) version where you can, i.e. what the public actually gets - not a preview url. The preview pipeline can behave differently and youll end up comparing apples with pears.
This is also where the "find rendering errors" tool earns its keep - before you even start optimising, render your spread and confirm they are all clean. Theres no point baselining a page thats already throwing a null ref...
Seeing it, not just diffing it
A byte diff is great for the machine, but Im not going to sign something off Ive not actually looked at - and ideally I want whoever is reviewing it to be able to see it too.
So as well as the html comparison, we drive a real browser with Playwright. For each page in our spread it opens the page and takes a screenshot at a few different viewport sizes - mobile, tablet and desktop - so we can confirm nothing has shifted at any breakpoint, not just on a full size desktop.
The handy bit is that before it grabs the shot, we have Playwright drop a highlighted box around the actual component we are optimising. So when you line the ASIS and TOBE screenshots up next to each other, your eye goes straight to the bit that changed - or rather, straight to the bit that very much should NOT have changed. Which with a caching change is rather the whole point... it should look identicial, just arrive quicker.
It turns a folder full of html into something you can flick through in a few seconds and actually sign off with confidence. i.e. instead of "the diff came back empty, trust me", you get a proper before and after, at three sizes, with the component ringed - which is a far easier thing to put in front of a reviewer, or drop into the pull request.
Generating content items to test against
One thing that always made these comparisons a bit fragile was depending on real content - content changes, editors move things, and suddenly your baseline is meaningless.
So part of the playbook is to have Claude generate its own throw-away content items as fixtures, using the create-item / SPE tools. That gives you known inputs - a course with exactly [N] modules, one with none, one with a really long title, and so on - that you control and can recreate on any environment.
It also means you can deliberately create the akward edge cases that never seem to exist in your test data until they blow up in production. The empty one, the one with a missing field, the one with a daft number of child items...
Running the comparison
With the baseline captured and the change made, the TOBE pass is just the same render step again - same pages, same tool - saved to a second set of files. Then Claude diffs ASIS against TOBE.
The first time you do this, the diff is almost never empty - but not because youve broken anything. Its because pages contain per request noise, i.e. anti-forgery tokens, cache-busting hashes on asset urls, the odd GUID. So part of the playbook is a list of known noise patterns to filter out. Once those are stripped, a genuine optimisation should come back byte for byte identical.
If it doesnt, the diff points you straight at what changed, which is far better than finding out from a user three weeks later.
The final comparison
Last of all, the bit that tells you whether any of it was worth it - re-pull the same stats and cache pages from Part 1, after the change has bedded in.
For our slow data-layer component, the before / after on stats.aspx told the story:
| Avg time (ms) | From cache | |
|---|---|---|
| Before | [~Xms] | 0 |
| After | [~Xms] | [N] |
And on the cache that was bumping its cap, cache.aspx showed it had dropped from [~X MB against a Y MB cap] down to a fraction of that, because we were finally caching the right (i.e. much smaller) set of data.
Seeing the before and after side by side, with the byte-identical comparison sat alongside it, is what gives you the confidence to say "this is faster, and it behaves exactly the same" - which is a much nicer thing to take to a deployment than "I think this should be ok".
Summary
In this post we looked at how a Sitecore MCP server let Claude do the heavy lifting of the optimisation playbook - finding a represenative spread of pages, generating throw-away test content, capturing the ASIS / TOBE renders and running the byte comparison, then proving the win with the before/after stats and cache figures.
The playbook itself is the real takeaway here, not the AI - Claude just makes following it a lot less tedious. If it saves someone else from a few late-night "I hope this is ok" deployments, then its done its job.