Machine Experience (MX): Why Lighter Front Ends Work Better for People and Crawlers

We spend a lot of time on user experience, and rightly so. But a growing share of the “visitors” reading your website aren’t people. They’re search crawlers, AI assistants answering a question about your industry, screen readers, translation tools and, more and more, browser agents filling in forms for someone.

Machine Experience, or MX, is the name some designers and developers now use for designing with that second audience in mind. It sounds new, but most of it is old advice that finally has a commercial reason behind it: send real HTML, keep JavaScript for the things that need it, load fast and follow accessibility standards.

Who the machines are

• Search crawlers. Googlebot and Bingbot index your pages for search results.
• AI crawlers and assistants. GPTBot, ClaudeBot, PerplexityBot and others fetch pages to train models or to answer a user’s question in real time.
• Assistive technology. Screen readers, voice control and switch devices read the structure of the page to present it another way.
• Browser agents. Tools that click, scroll and type on a person’s behalf to book, compare or buy.
• Everyday utilities. Reader mode, translation, link previews in Slack and WhatsApp, and password managers all parse your markup.

They differ a lot in sophistication, but they share one thing: they do best with content that is already in the HTML and clearly labelled.

Why heavy JavaScript is a problem for them

A lot of modern sites ship an almost empty HTML file and build the page in the browser with JavaScript. A person on a fast laptop barely notices. Machines notice a great deal.

Google does render JavaScript, though rendering can lag behind crawling. Many AI crawlers don’t render it at all. When Vercel and MERJ analysed crawler traffic in late 2024, they found that OpenAI’s and Anthropic’s crawlers fetched JavaScript files but didn’t execute them. If your product descriptions, prices or case studies only appear after a script runs, those crawlers see a blank page, and an AI assistant asked about your services has nothing of yours to quote. I cover the crawler side in more detail in optimizing websites for AI crawlers.

Browser agents and screen readers have a related problem. A <div> with a click handler looks like a button to a sighted person and like plain text to everything else. A real <button> announces itself, takes focus and responds to Enter and Space with no extra code.

CSS now covers much of what JavaScript used to do

The good news is that leaner front ends don’t have to look plainer. Over the last few years browsers have added CSS and HTML features that replace whole libraries:

• Popovers and dialogs. The popover attribute and the <dialog> element handle menus, tooltips and modals, including focus and the Escape key.
• :has(). Style a parent based on its children, such as highlighting a form section when a field inside it is invalid, with no script.
• Container queries. Components adapt to the space they sit in, not just the screen width.
• Scroll-driven animations. Progress bars, reveals and parallax tied to scroll position, running off the main thread.
• View transitions. Smooth animated changes between states, and between pages in browsers that support it.
• <details> and <summary>. Accordions and FAQs that work with no JavaScript at all.

Support for the newer ones still varies, so check Baseline or caniuse before relying on them, and treat the effect as an extra rather than a requirement. I went through this shift in more depth in CSS is eating JavaScript’s lunch.

Speed is a machine metric too

Fast pages help people convert. They also help machines. Crawlers work to a budget, and slow, heavy pages get fetched less often. Agents time out. Screen readers on low-end phones stutter when the main thread is busy running scripts.

Google’s Core Web Vitals are a sensible yardstick for both audiences:

• Largest Contentful Paint (LCP) under 2.5 seconds: the main content shows up quickly.
• Interaction to Next Paint (INP) under 200 milliseconds: the page responds promptly when tapped or clicked. Heavy JavaScript is the usual reason this fails.
• Cumulative Layout Shift (CLS) under 0.1: things don’t jump around as the page loads.

If you want a dollar figure on what better speed is worth, I walk through one in what a 1-second faster site is worth in leads.

Accessibility is where MX and UX meet

Accessibility compliance is the part of MX with legal weight. The European Accessibility Act has applied to many consumer-facing digital services in the EU since June 2025, and website accessibility lawsuits remain common in the US. The practical standard behind both is WCAG.

The useful thing is that WCAG work and MX work overlap almost completely. Proper heading order, labelled form fields, descriptive link text, alt text, real buttons and visible focus all help a screen reader user, and they all help a crawler or an agent understand what the page is and what it can do. You fix it once and both audiences benefit. My guide to electronic accessibility covers the basics.

A practical MX checklist

• Render content on the server (static generation or server rendering), so it’s in the HTML on first load.
• Use semantic elements: <header>, <nav>, <main>, <article>, headings in order, real buttons and links.
• Give every important page its own URL and link to it with a normal <a href>.
• Add structured data (schema.org) for your organisation, products, articles and FAQs.
• Reach for CSS and HTML before adding a JavaScript library for menus, modals, accordions and animation.
• Audit your third-party scripts. Chat widgets, tag managers and heatmaps are often the heaviest things on the page.
• Check robots.txt and decide on purpose which AI crawlers you allow.
• Test with a keyboard, a screen reader and JavaScript switched off, at least once per release.

What this means for a redesign

You don’t need to throw out React or Next.js to get this right. This portfolio runs on Next.js. What matters is where the work happens. Pages are generated as HTML ahead of time, interactive pieces load only where they’re used, and the visual polish comes mostly from CSS. A visitor gets a fast, rich page, and a crawler or screen reader gets clean, complete content.

If a proposal for your new site leads with a long list of animation libraries, ask how the content looks with scripts turned off. It’s a quick way to find out whether the build was planned with both audiences in mind.

Frequently Asked Questions

What is Machine Experience (MX)?
Designing a site so that software reading it, such as crawlers, AI assistants, screen readers and browser agents, can fetch, parse and understand it as easily as people can.

Do AI crawlers run JavaScript?
Mostly not. Content that only appears after client-side rendering may be invisible to them. Googlebot does render JavaScript.

Is accessibility part of MX?
Yes. Screen readers rely on the same structure that crawlers and agents do, so accessibility work improves both.

Does a lightweight front end look plain?
No. Modern CSS handles most animation and interaction, so the design can stay rich while the page stays light.