Taking a static one-page site from 60 to 81 on mobile Lighthouse

The question

The subject is a static one-page site built in a visual site builder and exported as plain files. Exporting a site like that is easy. The open question was how much the export costs someone opening it on a phone, and how much of that cost can be removed without changing the design at all.

The starting point was a mobile Performance score of 60 in Lighthouse. That was the number to move, so the work focused on the mobile test. Desktop and SEO scores were only recorded after the work was done.

The setup

A builder export ships with the builder's own stylesheet framework, split across many files, and the site's own styles sit on top of that. The imported part is the natural place to start, since it's code nobody on the project wrote and much of it supports features this page doesn't use.

The builder brought along 13 CSS files, which were merged into one so the browser fetches a single stylesheet. That imported builder CSS was then trimmed from 651 to 208 KB.

Cutting the stylesheet written for this site was tried as well, but elements started drifting out of line, so that file was restored and left untouched. The styles written for a specific page are the ones most tied to how it looks, and the imported framework offered enough room on its own.

The finished package is 126 files and 4.2 MB, with no external dependencies, so nothing on the page waits on a third-party server to load.

• Before651 KB
• After208 KB

Source: Build size measurements

Measurement

There were two yardsticks. Lighthouse ran in its mobile and desktop modes, which is a lab test: it loads the page under a simulated slower phone and connection and scores what it sees. That makes it repeatable and useful for comparisons, but scores move a little from one attempt to the next, and a lab score says nothing about what real visitors experience on their own phones and networks. That kind of field data only builds up once a site is live and getting traffic.

The second yardstick covered the main constraint, which was that the cleanup shouldn't change how the site looks. 43 frames of the original and the cleaned version were compared pixel by pixel. If a score goes up because part of the page went missing, the page is broken, and comparing frames is how that gets ruled out.

Results

Mobile Performance went from 60 to 81. Desktop came in at 99 and SEO at 100.

• Mobile Performance before60 score
• Mobile Performance after81 score
• Desktop Performance after99 score
• SEO after100 score

Source: Lighthouse lab measurements

Across the 43 compared frames, there was 0 pixel difference between the original and the cleaned version.

The mobile score stopped at 81 for a known reason. Mobile LCP, the moment the largest visible element finishes appearing, measured 5.2 s, and that comes from a deliberate animation on the main headline. The animation stayed because changing it would change the design, and leaving the design as it was had been the whole point of the exercise.

A second audit on a 15-page site

The same mobile lab test was also run on a separate 15-page site built the same way, together with two automated accessibility checkers, a structured data check and a crawl of every page. The averages came to Performance 71, Accessibility 99, Best Practices 100 and SEO 100. Accessibility moved from 98 to 99 after a round of fixes. Performance ranged from 49 to 79 between pages, and the lowest one was the page with a 3D scene, the heaviest page visually.

The fixes were small and specific. An empty arrow link on 3 pages got a label, so screen readers have something to announce instead of silence. A step id that had been repeated across several pages was renamed on each. The FAQ sections on 9 pages got a landmark label, a short tag that tells assistive software what a section is so a listener can jump straight to it. The homepage's sharing address now matches its canonical address, the one official URL search engines are asked to treat as the real page.

A few findings were oddly specific. A plain paragraph carried a label that assistive software ignores on that element, so it got a group role and the label now gets read. A form that opens in a popup caught by a script returns a not-found page when a crawler asks for its address directly, and only a live deployment shows how that behaves for real visitors. Pages that still held the template's placeholder writing were kept out of the published build.

Overall, links with no readable name went from 2 to 0, and missing page regions went from 16 to 6. Duplicate element ids went from 51 to 34. The ones left are ids the builder generates, which its CSS depends on, and identical ids on repeated SVG filters, so they weren't renamed by hand. Color contrast came back as 14 warnings in one checker and 34 issues in the other, mostly a light gray main headline and inactive tabs. Those are deliberate design choices and were treated as a separate decision. A footer heading labeled "Monthly" still skips a heading level, a known issue that hasn't been changed yet.

The search basics were checked on every page: one main heading per page, no missing or repeated titles and descriptions, alt text on every image, and a sitemap with 15 URLs that match the 15 pages. Each page carries one block of structured data describing the organization, the website, the page and the service, and every block parses cleanly. Some things can only be checked after a site is live, including real-user speed data, the score from the live hosting setup, rich result checks and how search engines index the pages, so those remain open.

Takeaways

Start with imported code

The builder's framework CSS was the safest place to cut, because it carries rules for features the page never uses. Hand-written site styles are a different matter: they come last, and only with a visual check beside every change.

Prove nothing changed before trusting a number

Comparing frames pixel by pixel is what makes the 60 to 81 result trustworthy. The score showed that the page got lighter, and the frame comparison showed that it still looked the same.

Decide which slow parts are design

The headline animation costs score. Keeping it meant accepting a lower mobile score than the page might have reached without it. For similar work, it helps to write down which slow elements are deliberate before the audit begins, so the report doesn't make that decision.

Builder ids are part of the layout

Duplicate ids that a builder generates look like easy accessibility fixes, but here its stylesheet was tied to them. Those stayed, along with the repeated SVG filter ids, and only duplicates in hand-written parts were fixed.

Ask AI about this AI Lab note

Opens the assistant in a new tab with this page as the source.

ChatGPTClaudePerplexityGemini