Deep dive: web development

What makes a website good, and how your site does it: the web half of the talk at the start of the workshop, slide by slide, with something to try. The AI half is on Deep dive: AI.

On this page

• AI can build a great site or a bad one
• What makes a good website
• Your model stopped learning
• DevTools: measure, don't guess
• Check yourself

AI can build a great site or a bad one

The same chat box can give you either one. What decides it is what you know, in three areas:

• Know the topic. Know what good means for a website: fast, accessible, private, built on today's web, easy to find. Then you can ask for it, and you see when it is missing. The next section is that topic.
• Know the AI. Know how agents work, and set them up with rules, skills, the right context and the right model. Deep dive: AI and Deep dive: building blocks are this part.
• Know the code. Read what the agent writes, so you judge whether it is good, not only whether it runs. A good setup makes the agent write code that a person can maintain later. Without one, a big project gets complex fast, and nobody understands what the AI wrote.

Try it: in a fresh chat in your repo, ask Explain site/index.html to me. The agent explains the file in plain words, points to the lines and changes nothing. Ask about every line you do not understand.

What makes a good website

Four things every visitor feels, and one that brings them to your site.

Performance

Google measures how a page feels in three numbers, the Core Web Vitals:

• LCP, Largest Contentful Paint: how long until the main content shows. Google calls 2.5 seconds "good"; aim for under one second.
• CLS, Cumulative Layout Shift: how much the page jumps while it loads. Good is 0.1 or less.
• INP, Interaction to Next Paint: how fast the page answers a tap or a click. Google calls 200 milliseconds "good"; aim for under 100.

A page passes when three in four real visits meet the mark, on the visitors' own phones, not on your laptop. What usually makes a page slow, and what your site does instead:

• Content built by JavaScript shows only after the script ran. Your site's content is already in the HTML: the build step writes it there.
• A large image takes long to load. Your photo is a small square WebP file, at most 480 pixels wide, and the browser fetches it first.
• Images without a size make the page jump when they arrive. Your images carry their width and height, so the browser keeps the space free.
• Fonts from another server need an extra connection before the text can look right. Your fonts come from your own site.
• Long scripts block the page when someone taps. Your site has one tiny script, for extras only.

Accessibility

People use the web with a keyboard, a screen reader or a magnifier, and with weak eyesight. The common standard is the Web Content Accessibility Guidelines, WCAG 2.2, at level AA. Five habits cover most of it:

• Contrast: at least 4.5 to 1 between normal text and its background, 3 to 1 for large text. Your Designer checked every colour pair.
• Alt text: a short description of every image that carries meaning, such as your photo. Describe what it shows; leave out "image of".
• Real elements: one h1, headings in order, links that go somewhere and buttons that do something. A screen reader uses them to jump through the page.
• Keyboard: everything works with Tab and Enter, and you can see where the focus is.
• Motion and language: movement calms down for visitors who ask for less motion, and the page names its language, so a screen reader pronounces it right.

Try it: the Check finds many problems, but not all of them. Open your site, put the mouse away and press Tab through the page. Then listen to it with a screen reader: VoiceOver on a Mac (Cmd+F5), Narrator on Windows (Win+Ctrl+Enter).

Privacy

Your site uses no tracking and loads nothing from other servers. Every file a page loads from another server sends the visitor's IP address there, and in the EU an IP address counts as personal data. In 2022 a court in Munich ruled against a website that loaded its fonts from Google's servers: the visitors' IP addresses went to Google without their consent.

So your site serves its fonts and its photo itself and sets no cookies. Its legal page names the little data there is: GitHub Pages logs IP addresses. Want visitor numbers one day? Then your privacy notice has to say so, and many tools need the visitor's consent first.

Today's platform

Browsers now do much of what used to need JavaScript, and a model trained on older code does not know it (see Your model stopped learning). One example, a panel that opens on a click, with no JavaScript at all:

<button popovertarget="about">About me</button>
<div id="about" popover>I build fast, accessible websites.</div>

The browser opens and closes it, closes it on Esc, and puts it on top of the page. More of the same kind: <dialog> for modal windows, prefers-color-scheme for dark mode, prefers-reduced-motion for calmer motion, container queries for layouts that fit their box. Less code means fewer bugs and faster pages. Modern Web Guidance has a guide for each.

Visibility

People have to find your site first. Search engines and AI assistants read its HTML, and many AI crawlers and link previews run no JavaScript. Optimising for search engines is SEO; being found and quoted in AI answers is called GEO, generative engine optimisation. Your site does four things for both:

• Its content is in the HTML itself: the build step writes it there before publishing. That is pre-rendering.
• The facts about you are in JSON-LD, structured data that machines read: a profile page about a person, with your name, your job, your city and your profiles elsewhere.
• A sitemap.xml lists your pages, and a robots.txt says what search engines may read.
• An llms.txt gives AI tools a short text version of your site.

What helps most after that: the same name and photo everywhere you appear, links from your GitHub and LinkedIn profiles to your site, and content that stays current.

Try it: start a fresh chat and paste this, with your GitHub username in place of YOUR-USERNAME. The agent should name you, your headline and your projects.

Agent chat

Read the HTML of https://YOUR-USERNAME.github.io/portfolio/ without running JavaScript. What does it tell you about me?

Your model stopped learning: Modern Web Guidance

Developers stay current by reading release notes, blog posts and talks. A model cannot read on. It learned from the web as it was up to its training cutoff, and then it stopped. Worse, most of what it read is old: the web has ten years of pop-ups built from div elements and JavaScript, and much less of the native way. So the agent writes yesterday's code, and it sounds sure of itself.

Modern Web Guidance is the Chrome team's answer: more than 160 short guides on current HTML, CSS and JavaScript, written for agents, open source. Your repo has it as a skill, and AGENTS.md tells the agent to read the matching guide before it builds any part of the page.

The guides in your repo are about 350,000 tokens, far more than a chat can hold. So the skill works in three steps, like every good skill:

1. The agent always sees one line: the skill's name and what it is for.
2. When the task matches, it reads the skill's instructions, which point to an index with one line per guide.
3. It opens only the one to three guides it needs: about 15,000 tokens for a typical task.

For your next project, install it with npx modern-web-guidance@latest install; the repository's README shows the other ways, agent by agent. The same idea works for any tool that changes fast: give the agent current documentation to read, instead of trusting what it remembers.

DevTools: measure, don't guess

Chrome's developer tools are built in: press Cmd+Option+I on a Mac, F12 on Windows and Linux. The parts QA used today, and how to use them yourself:

• PerformanceOpen the Performance panel and click the reload button in it: Chrome records the load and shows LCP and CLS, and INP as you click around.
• Device modePress Cmd+Shift+M (Ctrl+Shift+M on Windows and Linux) for a phone-sized page; its network and CPU menus make it as slow as a mid-range phone.
• ScreenshotsOpen the command menu with Cmd+Shift+P (Ctrl+Shift+P) and type full size screenshot.
• LighthouseThe Lighthouse panel scores accessibility and best practices in a minute. The Check runs its accessibility rules.
• ConsoleEvery error the page throws. The Check reports them.

Your agent can use the same tools: Chrome DevTools for agents is an MCP server, and your repo sets it up (see MCP). What DevTools measures is lab data, one run on one machine. What your real visitors get is field data: Do it professionally shows where to find it.

Check yourself

Five questions on this page. Pick one answer each, then check them.

Why does your site put its content into the HTML before publishing?

GitHub Pages accepts only HTML files It makes the colours load faster Search engines, AI assistants and link previews often read the HTML without running JavaScript

Why does your site serve its fonts itself, instead of loading them from Google Fonts?

Loading them from another server sends every visitor's IP address there, which is personal data in the EU Google Fonts costs money Browsers block fonts from other servers

Why does the Developer read Modern Web Guidance before it builds?

To use fewer tokens Its model learned mostly old web code and missed what the web shipped since its training cutoff Because the browser asks for it

Your page jumps while it loads, when the photo arrives. What fixes it?

A bigger photo The photo's width and height in the HTML, so the browser keeps its space free Loading the photo with JavaScript

The Check says Accessibility passes. What do you try yourself?

Nothing: the Check covers everything A bigger font everywhere Tab through the page without a mouse, then listen to it with a screen reader

Check my answers