28 Dec 2024 // 5 min read
WebflowPerformanceSEOPageSpeed technical

How I took proGrow from PageSpeed 52 to 97

A Webflow site with 21MB pages, 1321 unused CSS classes, and hidden lorem ipsum. Here's what I found and fixed.

One page on proGrow’s website was 21.3MB. That’s bigger than most desktop applications. It was a team page with photos.

proGrow is a manufacturing intelligence platform built in Porto. Their Webflow site looked professional, but under the surface, things were falling apart. They asked me to figure out why the site felt slow and what could be done about it.

I audited all 13 key pages. What I found wasn’t one big problem. It was dozens of small ones, compounding across every page.

What the audit revealed

The numbers told a clear story:

  • Average performance score: 83.85%
  • Average page size: 4.73MB
  • Average load time: 7.58 seconds
  • Average requests per page: 85
  • Worst page: Team page at 52% performance, 21.3MB

The team page was the worst offender, but it wasn’t alone. The homepage weighed 7.23MB with a performance score of 70%. Even the better-performing pages had structural issues hiding beneath decent scores.

The problems were systemic

Every page had the same recurring issues:

1321 unused CSS classes. The Webflow project had accumulated over a thousand styles that weren’t attached to anything. Dead weight in every page load.

19 unused animations. Webflow’s interaction engine loads a script to handle animations. Each unused animation adds to that payload for nothing.

Broken heading hierarchy on almost every page. Missing H1s, duplicate H1s, H2s jumping to H4s. One page had “35%” and “5%” as its H1 elements. This kills both SEO and accessibility.

Hidden elements still in the DOM. Sections set to display: none but still loading their images and scripts. Some contained lorem ipsum placeholder text that had never been replaced.

Missing OpenGraph images across the board. Not a performance issue, but it meant every social share showed a generic preview.

Unoptimized images everywhere. No dimension attributes, missing alt text, and file sizes far larger than needed. The team page’s photos alone accounted for most of its 21.3MB.

What I fixed

The fixes were methodical, not glamorous. No clever hacks, just cleaning up what shouldn’t have been there.

Code cleanup: Removed all 1321 unused classes, 19 unused animations, and every hidden element. Stripped out unnecessary breakpoints that were generating extra CSS. Consolidated duplicate navigation and footer components into reusable blocks.

Image optimization: Compressed and resized every image. Added dimension attributes so browsers could allocate space before loading. Added alt text across the board.

Heading restructure: Rebuilt the heading hierarchy on every page. One clear H1, logical H2/H3 structure, proper semantic HTML elements.

Meta and SEO: Wrote proper meta descriptions, created OpenGraph images, fixed URL inconsistencies (some slugs were in English on a Portuguese page), and corrected broken hreflang tags.

Video embeds: Replaced non-native YouTube embeds with Webflow’s native video elements where possible, removing third-party script overhead.

The results

Tested two weeks later on GTmetrix (Europe-based traffic):

PageBeforeAfterChange
Team page52%97%+45
Homepage70%86%+16
Nestlé case study76%96%+20
Blog article83%100%+17
Demo85%98%+13
Pricing93%100%+7
Quality Management95%99%+4

Structure scores improved across every page, with most jumping 5-10 points. Two pages hit a perfect 100% performance score.

The remaining opportunities were minor: replacing a YouTube player on two pages and converting some background images to standard img elements.

What this taught me

Most Webflow performance problems aren’t about the platform. They’re about accumulation. Every hidden element, unused class, and uncompressed image adds a tiny bit of weight. Multiply that across a few dozen pages and a year of development, and a 21.3MB team page starts to make sense.

The fix is always the same: audit everything, remove what isn’t needed, optimize what remains. Not exciting work, but it’s the difference between a 52% and a 97%.

Read the proGrow case study for the project overview and full results.

Frederico Leonardo
Frederico Leonardo
Founder & Lead Developer

25+ years building for the web. Specialises in hybrid architectures and pushing platforms beyond their limits.