DEV Community

Cover image for Are We Actually Building Faster Websites, or Just Using Fancier Tools?
Kudzai Murimi
Kudzai Murimi Subscriber

Posted on

Are We Actually Building Faster Websites, or Just Using Fancier Tools?

Let's talk about something that's been bugging me lately.

Every few months, there's a new framework promising to make our websites faster. React Server Components. Astro. Svelte 5 with its new runes. Fresh. Qwik. The list keeps growing.

And here's my question: Are our websites actually getting faster, or are we just moving complexity around?

The Promise vs. The Reality

These frameworks all sound amazing on paper:

  • "Zero JavaScript by default!"
  • "Instant page loads!"
  • "Better developer experience!"

But then I look at real websites in the wild, and I still see:

  • Loading spinners everywhere
  • Slow interactions
  • Massive JavaScript bundles
  • Sites that feel sluggish on mobile

What's Actually Changed?

React Server Components - Mixing server and client code sounds great. But how many teams actually need this? Are we solving real problems or just adding complexity?

Astro - The islands architecture makes sense. Send less JavaScript. But couldn't we have just... written less JavaScript in the first place?

Svelte 5 - Runes look cleaner than the old reactive syntax. But does cleaner code mean faster websites for users?

My Controversial Take

Maybe the framework doesn't matter as much as we think. Maybe the real problem is:

  • We're building bloated apps when simple pages would work
  • We're not measuring real user performance
  • We're optimizing for developer experience, not user experience
  • We're adding frameworks when vanilla JS would be fine

The Questions I'm Wrestling With

  1. Have you actually measured performance improvements after switching frameworks? What did you find?

  2. When was the last time a framework choice actually solved a real user problem vs. a developer problem?

  3. Are we being honest about whether we need all this tooling, or are we just chasing shiny new things?

  4. What about the sites that are actually fast? A lot of them use "boring" tech. WordPress sites with good caching. Static HTML. Simple server-rendered pages.

Let's Be Real

I'm not saying these frameworks are bad. React Server Components are genuinely useful for certain apps. Astro is perfect for content sites. Svelte is a joy to write.

But I wonder if we've lost sight of the fundamentals:

  • Optimize images
  • Lazy load what you don't need immediately
  • Cache aggressively
  • Ship less code
  • Measure real-world performance

These work regardless of your framework.

My Challenge to You

Next time you reach for a new framework, ask yourself:

  • What problem am I actually solving?
  • Will users notice the difference?
  • Am I adding complexity just because it's trendy?

Let's Discuss

What's your experience? Have these new frameworks actually made your sites faster? Or are we just rearranging deck chairs?

What metrics matter to you? Time to Interactive? First Contentful Paint? Or just "does it feel fast?"

What's working in production? Forget the demos and benchmarks. What actually ships fast in real projects with real deadlines and real teams?

Drop your thoughts below. Let's have an honest conversation about this.

What framework are you using right now, and why? Would you choose it again?

Top comments (2)

Collapse
 
apogeewatcher profile image
Apogee Watcher

I would argue we should focus on field data: GSC Core Web Vitals and CrUX. Lab tools (Lighthouse, PSI) are good for debugging, but 50% of sites with strong lab scores still fail CWV in the field. Track by template type (home, product, cart, checkout). If you’re curious about real impact, compare CrUX before/after any framework migration.

Collapse
 
respect17 profile image
Kudzai Murimi

Absolutely spot on. That 50% failure rate between lab and field is the wake-up call most teams need, I've seen too many celebrate perfect Lighthouse scores while their actual CWV tanks.
Template-level CrUX tracking is gold, especially for product/checkout pages where conversions actually happen.