Judging a front end

Page weight is the total size of the files a page downloads. The Web Almanac 2025, a yearly study by the HTTP Archive, measured millions of sites in July 2025. The median home page on a phone weighed about 2.6 MB, up from 2.4 MB a year earlier. Pages keep getting heavier.

The chart shows what that weight is made of, kind by kind. Each figure is the median for that kind of file, so they don't add up to the total. Images weigh the most, about 910 KB (a kilobyte, KB, is a thousandth of a megabyte). JavaScript comes next, about 630 KB, then fonts, about 120 KB, style sheets (CSS), about 80 KB, and the HTML itself, about 20 KB.

The two biggest don't cost the same. An image is downloaded, then shown. JavaScript is downloaded, then the phone has to run it, and an ordinary phone runs it much more slowly than a recent laptop. Frameworks add JavaScript, and apps built in the browser add the most, since their script builds the whole page.

Chrome measures how real visits feel on real phones, with three measures that Google calls the Core Web Vitals. The first is how fast the main content appears. The second is how fast the page reacts when you tap. The third is whether things jump around while the page loads. Google uses them when it ranks pages in its results.

The HTTP Archive publishes, for each tool it can detect, the share of sites that pass all three on phones. In September 2026, 53% of all sites passed. Sites on Wix passed most often, at 81%, then Shopify at 76% and Astro at 71%. WordPress sites were at 48%, React at 44%, Next.js at 36% and Angular at 17%. The chart shows these figures.

They aren't a verdict on each tool. Hosted builders do the speed work once, for all their sites, while large web applications are heavier by nature, whatever they're built with. But they show that some tools make speed the default, and others leave it to the developers. And unlike a Lighthouse score, measured once on one computer, these figures come from real visits.

Search engines rank what they find in the page's HTML, so the content has to be in it. Pages made in advance or by a server have it. Apps built in the browser may not, as the lesson Three ways to make a page showed.

Each page also needs a few lines that visitors don't see on the page itself. A title and a short description, which search engines show in their results. And a preview picture, which WhatsApp or LinkedIn show when someone pastes the link. When every page has the same ones, copied from the home page, all the results look alike.

Google runs scripts, but later and not always. Other robots often don't run them at all. In December 2024, a study by Vercel found that none of the main AI crawlers ran JavaScript: the robots of ChatGPT and Claude downloaded the scripts but never ran them. You can check a page yourself: "View page source" shows what robots receive, and pasting a link into a chat shows its preview.

The WebAIM Million tests the home pages of the million most visited sites every year. In February 2026, 96% of them failed automated accessibility checks, with 56 errors per page on average. The most common were text with too little contrast (84% of pages), images without alternative text (53%) and form fields without labels (51%).

The study also counts errors by tool, while warning that the tool isn't always the cause. Pages built with Astro had 9 errors on average, Wix 33, React 44 and WordPress 53, while Vue had 65 and Shopify 75.

Frameworks don't make a site accessible or not, but components multiply whatever they contain. A component with an error, such as a box that acts as a button without being a real button, repeats it on every page that uses it. Fixed once, it's fixed everywhere. And automated tools find only part of the problems: someone has to try the site with the keyboard alone and with a screen reader. The lesson Leaving people out explains what French law requires.

A site lives for years, but each version of its framework is fixed for a limited time. The diagram shows the frameworks of this topic since 2010.

Two have already reached the end. AngularJS, released in 2010, stopped receiving any fixes in January 2022. Vue 2 reached its end of life on 31 December 2023. Its successor, Vue 3, comes with a guide for moving from one to the other. Others publish their plans: Angular's website gives its calendar, and since version 22 it releases one major version a year and supports each for 24 months. React has no fixed calendar: React 19, its current major version, came out in December 2024.

The tools around a framework age too. Create React App was for years the usual way to start a React project. In February 2025, React's own blog announced it was deprecated, noting that it had no active maintainers. A site that follows each new version with small, regular updates stays supported. One that waits for years faces a large jump, or a rewrite.

Choosing a framework also chooses who can maintain the site after its first developer. So look at the job market where you are.

In France, Angular appears in as many job offers as React, or more. On 23 October 2026, Indeed France showed more than 2,000 offers mentioning Angular, more than 1,000 for React, more than 400 for Vue.js and more than 25 for Svelte. Free-Work, a job site for IT work and freelance missions, showed 377 offers for Angular, 261 for React, 194 for Vue.js and 9 for Svelte. So in France, employers ask for Angular at least as often as for React.

The freelancers tell another story. On Malt, a French platform for freelancers, about 6,600 offer React, against about 670 for Angular (which Malt lists under the name AngularJS) and 670 for Vue. Experienced ones charge similar day rates: about €560 a day for React or Angular, and €520 for Vue, according to Malt's 2026 rates. A rarer framework, such as Svelte, leaves fewer people who could take over.

Ask these questions before signing off a front end, and again a year later.

Ask how heavy the main pages are, and how fast they are on an ordinary phone, with figures from real visits rather than a single score. Ask what a search engine finds in the HTML, and check it with "View page source" and a link pasted into a chat: each page should have its own title, description and picture. Ask who tested the site with a keyboard and a screen reader, not only with an automated tool. And ask which version of the framework the site uses, until when it will receive fixes, and who else could maintain it where you are.