How this site works

On Google’s Lighthouse test, which simulates a mid-range phone on a slow mobile connection, the homepage scores 100 out of 100 for performance. The main content appears in about 1.6 seconds, and the whole page is about 250 KB.

• The fonts are stored on this site instead of loaded from another service, and the headline font is trimmed to the one weight the site uses. That cut its main file from 132 KB to 57 KB.
• The logo was redrawn as a vector image. It went from a 62 KB picture to about 2 KB, and it stays sharp at any size.
• Files that rarely change, like the fonts and the stylesheet, are saved by your browser for up to a year, so a returning visitor downloads them once.
• The server sends each page in about 0.2 seconds.

Each page includes structured data: a block of code, in the schema.org format, that search engines read and visitors don’t see. On the homepage, it describes the business, who runs it, and the three services. Each practical answer and case study is marked as an article, with me as its author. Answers also include the date I last checked their facts.

The sitemap is generated from the site’s content, so a new page is added to it automatically.

The site doesn’t block AI tools from reading it.

The llms.txt file is a plain-text summary written for AI tools. It’s built from the same content as the pages, so it changes when they do. llms.txt is a proposed standard, and not every AI tool reads it yet.

The contact form is marked up with WebMCP, an experimental Chrome feature that lets an AI assistant in the browser fill in and send a form. Other browsers ignore it. When an assistant sends the form, the message is marked that way, so I know.

Every page is built to meet the WCAG 2.2 accessibility guidelines at level AA. In practice, that means:

• Text has enough contrast to read, in both the light and dark themes.
• Every part of the site works with a keyboard, and the element you’re on is clearly outlined.
• Form fields have labels that screen readers announce.
• Pages have landmarks and a “skip to content” link, so screen reader users can move around quickly.
• Movement on the page is minimal and turns off if your device asks for reduced motion.

Automated accessibility checks run on every change: the homepage in both themes, at desktop and phone widths, with the phone menu open, and the other main pages. Automated checks don’t catch every problem, but they catch many of the common ones before a visitor does.

Each change is built from scratch, then tested: pages load, the contact form saves and emails messages, spam is rejected, and the accessibility checks pass. Only if every check passes is the new version published, and it replaces the old one without the site going down.

Messages are stored on this site’s server and emailed to me. Spam is kept out by Cloudflare Turnstile, which usually checks that a person is sending the form without asking them to do anything, and by a hidden field that only automated spam fills in. Each message records which page it was sent from, so I know what the visitor was reading.

The analytics code is part of the site’s own files instead of loaded from the analytics company’s servers. It starts only after the page has finished loading, so it doesn’t slow the page down, and it sends data through a santansystems.com address.