A 100/100 website: how it's built

On October 21, 2026, PageSpeed Insights analyzed the hash42.xyz homepage, desktop version.

100 in Performance. 100 in Accessibility. 100 in Best Practices. 100 in SEO. And 3/3 in the new Agentic Browsing category.

A score like that does not come from a last-minute trick. It is the sum of many earlier choices, almost all of them invisible to visitors.

This guide covers the five choices that matter most and, for each one, how it translates into code.

What PageSpeed Insights measures

PageSpeed Insights uses Lighthouse to assess a page in five categories:

• Performance: how quickly the page shows content and responds, with metrics such as LCP, CLS and main-thread blocking time.
• Accessibility: whether the page works with screen readers, keyboards and low contrast.
• Best Practices: HTTPS, no console errors, libraries and APIs used correctly.
• SEO: whether search engines can read and understand the page.
• Agentic Browsing: whether an AI agent can understand and use it. It is an experimental category, and instead of a 0 to 100 score it shows how many checks the page passes.

Each category is won or lost on different choices.

01. Make the page light before making it fast

The fastest page is the one with the least to download. Before optimizing how things load, it pays to reduce what there is to load.

The hash42.xyz homepage has heavy elements: a 3D controller and a footer where letters can be dragged and thrown. They are only loaded when needed:

• the 3D library arrives after the rest of the page, and until then a static image stands in for it;
• the footer's physics engine is only downloaded when you get close to the bottom of the page;
• libraries used only by some sections of the site are no longer loaded on every page.

With the October redesign, the initial JavaScript of every public page dropped from 291 to 194 KB compressed.

All the code
  ↓
Needed now? → loaded with the page
  ↓
Needed later? → loaded as you get close
  ↓
Only needed elsewhere? → not loaded here

If you want to dig into images, lazy loading and caching, they are covered in the guide on how to make your website faster.

02. Load what matters first

Not everything on a page is equally urgent. The headline and the main message have to appear right away; the rest can arrive a moment later.

That is why pages are rendered on the server: the main content is already in the HTML that reaches the browser, and it does not wait for JavaScript to run.

The same goes for stability. Images and boxes have declared dimensions, so space is reserved before the content arrives and nothing jumps while the page loads. That is what CLS measures.

HTML from the server
  ↓
Headline and content visible
  ↓
Styles and main images
  ↓
Interactions and effects

03. Make the website easy to understand

A search engine does not look at the design. It reads the structure.

On hash42.xyz every page has:

• its own title and description;
• a canonical URL, to avoid duplicates;
• links between the Italian and English versions, with hreflang;
• structured data in JSON-LD following Schema.org, for example the data describing each blog article;
• an entry in the sitemap, with the date of the last change.

On top of that comes semantic HTML: a single main heading per page, sections with headings in order, links whose text says where they lead. This is the same information used by search engines, screen readers and, more and more, AI assistants.

04. Build for people, not just scores

Accessibility and best practices could be treated as a list to tick off. The real point is different: a website has to work for anyone who uses it.

In practice that means:

• contrast: normal text needs a ratio of at least 4.5:1 against its background;
• visible focus: keyboard users must always see where they are;
• names and labels: every button, link and field has a name a screen reader can announce;
• described images: alternative text that says what the image shows;
• no console errors: a JavaScript error ignored today is someone's problem tomorrow.

Lighthouse only checks part of these rules automatically. A 100 in Accessibility does not guarantee the site is accessible to everyone: it means there are no errors among those a machine can detect. The rest has to be tested by hand, for example by using the site with the keyboard only.

05. Prepare for agents

The Agentic Browsing category arrived in Lighthouse in 2026 and is still experimental. It measures how ready a website is for AI agents that browse and take actions on people's behalf.

Today the main checks are three:

Accessibility tree
  structure, roles and names an agent can read
  ↓
Stability
  the layout does not move while the agent interacts
  ↓
llms.txt
  a Markdown summary of the site at the domain root

The 3/3 on hash42.xyz comes from here. The first two checks reward the same choices as the previous sections: a site that is accessible and stable for people is accessible and stable for an agent too. The third is a file, llms.txt, that summarizes who Hash42 Labs is, its products, services and blog articles, with links to the pages.

There is also a fourth part, WebMCP, which will let websites declare the actions available to agents, such as filling in a form. For now it is experimental: assessing it requires joining a Chrome trial, so it is usually left out of the count.

Desktop, mobile and real users

The report has one detail worth noticing: the real-user experience section says "No data". PageSpeed Insights only shows that data when a page has had enough visits from Chrome over the last 28 days. For a young website, lab data is the only reference.

Then there is mobile, where Lighthouse simulates a mid-range phone on a slow network: there, every kilobyte and every millisecond weighs much more.

Checklist for a 100 website

Before publishing a page, check at least these five points:

• Code that is not needed right away loads later, or only on the pages that use it.
• The main content is in the server HTML and image and box dimensions are declared.
• Every page has a title, description, canonical, hreflang, structured data and a sitemap entry.
• Contrast, focus, labels and alt text are in place, and the site has been tested with the keyboard.
• There is a valid llms.txt at the domain root and the layout does not shift while loading.

The score is a consequence

A 100/100 is nice, but it is not the goal. It is a sign that a series of right decisions was made at the right time: what to load and when, how to describe pages, how to make them usable for anyone, people or agents.

If the score drops, chasing it with a trick does not help. What helps is figuring out which of these decisions was forgotten.

Sources

• Google for Developers, About PageSpeed Insights
• Chrome for Developers, Lighthouse agentic browsing scoring
• web.dev, How the Core Web Vitals metrics thresholds were defined
• W3C, Understanding WCAG 2.2: Contrast (Minimum)