DEV Community

Cover image for Why Professional Websites Score 30-50/100 on PageSpeed
Daniel Tofan
Daniel Tofan

Posted on • Originally published at codecrank.ai

Why Professional Websites Score 30-50/100 on PageSpeed

In my previous article, I explained the techniques for achieving 100/100 on PageSpeed Insights—critical CSS inlining, modern image formats, eliminating render-blocking resources, and preventing layout shift.

These techniques aren't new or secret. They're documented, proven, and freely available.

So why do most professional websites ignore them?

After examining multiple agency portfolios and client sites over the past few months, I've found a consistent pattern. This article presents real performance data, explains why this gap exists, and demonstrates what different approaches actually deliver.


What does $5,000 buy in web development?

A friend recently showed me his new medical practice website. He paid $5,000 to a professional agency, spent months in back-and-forth communication, and received a visually appealing design. Out of curiosity, I ran PageSpeed Insights.

40/100 on mobile.

The site takes 20.2 seconds to fully load on a simulated mobile connection. For context, Google recommends under 2.5 seconds.

Then I checked the agency's own website to understand their typical performance standards.

36/100. This wasn't an anomaly—it was their baseline.

This experience prompted me to examine other professional web development work. What I found wasn't unique to this one agency.


The pattern across the industry

After analyzing sites from multiple professional agencies, a consistent pattern emerged. These aren't cherry-picked examples—they represent typical output from established businesses charging professional rates.

Medical Practice #1: 28/100 (39-second load time)

A physician's website built by a local IT company offering web development services:

  • Performance Score: 28/100
  • Largest Contentful Paint: 39.1 seconds
  • Total Blocking Time: 1,980ms
  • Technology: WordPress with outdated plugins
  • Issues: 10 render-blocking resources, unoptimized images

Patients wait 39 seconds to see the main content. For a medical professional whose reputation depends on trust and competence, this creates an immediate credibility problem.

Professional Services: 34/100 mobile (platform limitation)

A CPA's website built on a popular website builder platform:

  • Mobile Score: 34/100 (what Google actually uses for rankings)
  • Desktop Score: 68/100 (misleadingly acceptable)
  • Largest Contentful Paint: 7.4 seconds on mobile
  • Total Blocking Time: 2,960ms (3 seconds of frozen page)
  • Page Weight: 6.5MB

The desktop score looks mediocre but passable. The mobile score—the one Google uses for search rankings—is catastrophic. And here's the critical insight: this platform physically cannot achieve 90+ scores. The underlying architecture loads 2MB of JavaScript regardless of what the site owner does.

Dental Practice: 64/100 with broken functionality

A dentist's website from the same IT company:

  • Performance Score: 64/100
  • First Contentful Paint: 5.5 seconds
  • Issues: Broken navigation links, no online booking, outdated 2015 jQuery
  • Six empty frames: Users see a blank screen for 5+ seconds

Beyond the performance problems, basic functionality was broken. Links to "Cosmetic Dentistry" and "Invisalign" led nowhere. This represents a website that was built and abandoned.

The mobile reality

Desktop scores often appear acceptable (60-70 range) while mobile scores are significantly worse (28-40 range). This matters because:

  • Google uses mobile scores for search rankings (since 2019)
  • 70%+ of web traffic is mobile
  • Most agencies test on desktop development machines

A site scoring 68/100 on desktop might score 34/100 on mobile—and mobile is what determines your Google ranking.


What does poor performance actually cost?

Before examining why this happens, let's quantify the business impact.

Conversion losses

Google's research documents that 53% of mobile users abandon sites taking longer than 3 seconds to load. Their data also shows that as load time increases from 1 to 3 seconds, bounce probability increases by 32%.

For a small business with 10,000 monthly visitors:

  • Fast site (2 seconds): ~300 conversions/month
  • Slow site (8 seconds): ~210 conversions/month

That's 90 lost conversions monthly. At $100 average transaction value, that represents $108,000/year in lost revenue.

SEO compound effect

Core Web Vitals became Google ranking factors in 2021. Poor performance means lower rankings, which means less traffic, which means fewer conversions. The disadvantage compounds over time while competitors with faster sites capture the traffic you're losing.

Brand perception

A slow website signals something about attention to detail. Users form impressions about business quality based on website performance—often unconsciously. The 39-second medical site doesn't just lose the immediate conversion; it loses potential lifetime customer value.


Why does this performance gap exist?

This pattern isn't about competence. It's about business models, tooling choices, and economic incentives.

The page builder economics

Many agencies use WordPress with Divi or Elementor, or platforms like Wix and Squarespace, because it's economically efficient:

  • Fast to build: Templates provide professional appearance quickly
  • Client-editable: Clients can make content updates themselves
  • Familiar: Agencies already know the tools

However, these tools have inherent performance costs:

  • 500KB+ CSS/JavaScript loaded on every page (mostly unused)
  • Inline styles for every element (bloats HTML significantly)
  • Plugin accumulation (each feature adds overhead)
  • Platform limitations (some tools cannot optimize beyond 70-80/100)

The result: 3-5MB page weights for sites that could be 300KB.

The testing gap

Many agencies preview sites on fast development machines where everything appears responsive. Without mobile testing using CPU throttling, without PageSpeed audits during development, performance issues only become apparent to end users.

What renders instantly on a developer's MacBook Pro often struggles on a mid-range Android phone over 4G.

A different approach

We optimize for different priorities:

  • Static site architecture: No WordPress overhead, no plugin complexity
  • Performance-first development: Optimization techniques built in from the start
  • Modern tooling: Automated image optimization, critical CSS extraction
  • Testing protocol: Mobile testing with throttling, PageSpeed audits on every build

The difference isn't magic—it's prioritizing technical fundamentals from the beginning.


The Nuxt achievement: when heavy frameworks perform

Static HTML sites can achieve perfect scores relatively easily—there's minimal JavaScript, simple CSS, fast rendering. But what about real web applications with dynamic functionality?

HomeJourney, a Kentucky first-time homebuyer education platform, demonstrates what disciplined optimization achieves with a heavier framework:

  • Performance Score: 100/100 desktop, 99/100 mobile
  • First Contentful Paint: 0.3 seconds
  • Largest Contentful Paint: 0.5 seconds
  • Total Blocking Time: 0ms
  • Cumulative Layout Shift: 0
  • Technology: Nuxt 4 + custom CSS

These numbers represent near-instantaneous loading. For context, the human eye takes approximately 0.1 seconds to blink. This site fully renders in less time than three blinks.

Why this matters

Nuxt is not a lightweight framework. It includes Vue.js, a rendering engine, routing, and significant JavaScript. Achieving sub-second performance requires intentional optimization:

Critical CSS inlining: Approximately 5KB of above-the-fold styles are embedded directly in the HTML head. The browser renders meaningful content immediately—no waiting for external stylesheet downloads.

Static site generation: Pages are pre-rendered at build time. Users receive complete HTML, not JavaScript that builds the page in the browser.

Edge deployment: Cloudflare's global network serves pages from locations physically close to users, reducing latency to milliseconds.

The result proves that framework choice doesn't determine performance—implementation discipline does. A Nuxt site can outperform a static HTML site built without optimization.


The mobile 100 reality

I want to be direct about something: achieving 100/100 on mobile with dynamic frameworks is genuinely difficult, and sometimes the last point isn't worth chasing.

Why mobile is harder

Mobile devices have slower processors and constrained network connections. JavaScript that executes in 50ms on a desktop MacBook might take 200ms on a mid-range Android phone. Every framework has some JavaScript overhead—React, Vue, Svelte, all of them.

Static HTML sites with zero JavaScript can achieve 100/100 mobile consistently. Dynamic sites with interactivity face inherent trade-offs.

What matters more than the number

HomeJourney scores 99/100 on mobile. That missing point comes from CSS required for the desktop experience—specifically, styles that prevent layout shift on larger screens. It's a deliberate trade-off: we could squeeze out one more point by removing desktop-optimized CSS, but that would degrade the experience for desktop users.

And desktop is where it matters most for this application. Consider what 100/100 delivers there:

  • 0.3s First Contentful Paint (users see content almost instantly)
  • 0.5s Largest Contentful Paint (main content visible in half a second)
  • 0ms Total Blocking Time (page remains responsive throughout)
  • Zero layout shift (nothing jumps around)

These are desktop-focused applications where users research, read, and make decisions. The experience is near-instantaneous. Compare this to the industry examples: 34/100, 7.4-second load times, 3-second freezes. The difference in actual user experience is dramatic.

The honest answer: 96-99/100 with sub-second loading is excellent. Chasing that final point at the cost of functionality or user experience often represents diminishing returns.


How to evaluate web development quality

Here's a framework for assessing technical capability before hiring:

1. Test their own work first

Run PageSpeed Insights on the agency's own website. A developer's own site reveals their priorities clearly.

If their site scores below 70/100, that likely represents what you'll receive.

2. Request mobile scores specifically

Ask for mobile PageSpeed scores, not desktop. Desktop scores can be 30+ points higher and mask serious problems. Google uses mobile for rankings—that's the number that matters.

3. Ask about platform limitations

Some platforms cannot achieve high performance regardless of optimization effort:

  • Wix, Squarespace: Typically limited to 60-80/100
  • WordPress + heavy page builders: Often limited to 70-85/100
  • Custom development or lightweight frameworks: 90-100/100 achievable

Ask directly: "What performance scores do your sites typically achieve on mobile?"

4. Verify with live testing

Don't trust screenshots or claims. Run PageSpeed Insights on 3-5 live client sites from their portfolio. Look for consistency. Sites averaging below 75/100 suggest systematic issues rather than isolated cases.

5. Ask technical questions

A few specific questions reveal expertise quickly:

  • "How do you handle render-blocking resources?"
  • "What image formats do you use and why?"
  • "How do you prevent layout shift?"
  • "What causes poor mobile scores and how do you address it?"

A qualified developer will welcome these questions and provide specific answers. Vague responses or deflection suggest limited expertise in performance optimization.


The honest take

The agencies shipping 30-50/100 sites aren't incompetent—they've optimized for different outcomes. Fast delivery, easy client editing, familiar workflows. Performance simply isn't their priority.

That's a valid business decision for them. But it shouldn't be invisible to their clients.

If you're paying professional rates for web development, you deserve to know what performance you're getting. A 30-second PageSpeed test reveals more about technical quality than any portfolio page or sales call. The data is objective, free, and available to anyone.

I focus on performance because it directly affects business outcomes. Fast sites convert better, rank higher, and create better user experiences. This isn't the only valid approach—it's the approach I've chosen to specialize in.

Some businesses will prioritize performance. Some won't. For those who care, the evaluation framework above will help you find developers who share that priority.


What should you do with this information?

Test your current site: Run PageSpeed Insights (pagespeed.web.dev) on mobile. If you score below 70/100, there's significant room for improvement affecting your search rankings and conversions daily.

Verify these claims: Visit medconnect.codecrank.ai or ky.homejourney.app and test them yourself. Then test any agency portfolio site. The contrast is measurable.

Make informed decisions: Use the evaluation framework above when assessing web development options. Ask specific questions, test actual work, verify claims with data.


Performance data verified with Google Lighthouse, November 2025. Site identities anonymized.

Top comments (0)