I Rebuilt a Slow Local Business Website and Increased Its Speed from 38 to 95 — Here’s Everything I Learned

🟦 Introduction

A few months ago, I got a chance to work on a local business website that honestly looked fine at first.

The design wasn’t bad.

The content was okay.

The animations looked modern.

But the moment I opened the website on my phone, something felt wrong.

It loaded slowly.

Scrolling didn’t feel smooth.

Images appeared late.

Sometimes the page shifted while loading.

It was one of those websites where users probably leave before even exploring the content.

Out of curiosity, I tested the website on Lighthouse/PageSpeed Insights.

The mobile performance score was around 38.

That number didn’t fully surprise me because I could already feel the slowness while using the site, but seeing it that low made me realize how much optimization work was needed.

At that point, I decided not to just “fix a few things.”

I wanted to properly rebuild and optimize the website the way I personally believe modern websites should be built.

If you want to explore more about my development work and approach, you can check my portfolio.

🧠 The First Thing I Noticed

The website was trying too hard to look fancy.

There were:

• large animations everywhere

• oversized images

• unnecessary JavaScript

• effects loading all at once

On a high-end laptop, it looked acceptable.

But on an average mobile device, the experience felt heavy.

And honestly, this is something I see very often now while analyzing business websites and frontend projects.

A lot of websites focus so much on visuals that performance gets ignored completely.

That’s one reason I’ve recently started prioritizing lightweight and SEO-friendly frontend architecture in my projects.

⚙️ Starting the Optimization Process

I didn’t begin by changing the design.

First, I opened DevTools and started checking what was actually slowing the website down.

The biggest issue turned out to be images.

Some images were extremely large for no reason. A few were even multiple megabytes in size.

That was probably one of the biggest lessons for me during this project:

good-looking images mean nothing if the website becomes frustrating to use.

So I started optimizing every asset carefully.

I converted images into WebP, compressed unnecessary files, resized oversized assets, and added lazy loading where it made sense.

Just doing this already made the website feel noticeably lighter.

I’ve actually talked more about website optimization and development structure in another article.

🚀 The JavaScript Problem

After images, I moved toward the frontend bundle.

This part was interesting because the website was loading several libraries that were barely being used.

There were animation packages being imported for tiny interactions.

Some effects honestly looked cool, but they were hurting the experience more than helping it.

I remember sitting there thinking:

“Most users probably don’t even notice these effects, but they definitely notice slow loading.”

So I started removing unnecessary dependencies and simplifying sections one by one.

The funny thing is, after simplifying the website, it actually started feeling more professional.

• Cleaner.

• Faster.

• Less distracting.

That was another important lesson for me:

simplicity often feels better than overengineering.

This experience also changed how I think about frontend development overall, especially while building modern React applications.

📱 Mobile Optimization Changed Everything

The desktop version was never the real problem.

Mobile was.

And this completely changed the way I think about frontend development now.

Before this project, I used to design desktop-first sometimes and then adjust for mobile later.

Now I do the opposite.

Because most users are opening websites on phones.

While rebuilding sections, I started testing almost everything on smaller screens:

• spacing

• font sizes

• image behavior

• loading speed

• scrolling smoothness

Small improvements added up very quickly.

I also realized that performance optimization and SEO are deeply connected. Faster websites usually provide better user experience, which indirectly helps search visibility as well.

🧩 One Mistake I Used to Ignore

Earlier, I used to think performance optimization mainly meant:

• lazy loading

• image compression

• Lighthouse scores

But during this rebuild, I realized architecture matters just as much.

• Some components were rendering unnecessarily.

• Some sections loaded too early.

• The structure itself wasn’t optimized.

So I refactored parts of the frontend into cleaner reusable components and improved how things were loaded.

This not only improved performance but also made the codebase much easier to manage.

As someone who mostly works with React and full stack web development, this project genuinely improved my understanding of scalable frontend architecture.

You can also read my thoughts on frontend, backend, and full stack development.

📈 Seeing the Score Jump to 95

After hours of testing and optimization, I finally ran Lighthouse again.

This time the performance score jumped above 95.

Honestly, the score itself felt satisfying, but the real difference was the user experience.

The website finally felt smooth.

• Pages opened quickly.

• Scrolling felt responsive.

• Everything looked cleaner.

And for the first time, the website felt modern not because of animations — but because it respected the user’s time.

💡 What This Project Changed for Me

This project genuinely changed how I approach frontend development.

Earlier, I used to get excited mainly about:

• UI design

• animations

• visual effects

Now I think much more about:

• speed

• responsiveness

• accessibility

• real-world usability

Because users remember how a website feels.

And performance is a huge part of that feeling.

That’s also one reason I’ve recently been focusing more on building fast and SEO-optimized web experiences instead of only visually impressive interfaces.

🧠 My Biggest Realization

A lot of websites become slow not because developers are bad.

Usually it happens because:

• too many libraries get added

• optimization gets postponed

• visual complexity keeps increasing

It happens slowly.

And by the time the project is finished, the website becomes unnecessarily heavy.

Now whenever I build websites, I try to keep asking myself:

“Does this actually improve user experience, or is it just extra?”

That one question has improved my development decisions a lot.

🚀 What I Focus on Now

After this experience, performance optimization became part of my normal workflow.

Now when I build websites, I focus much more on:

• clean frontend architecture

• lightweight UI

• SEO-friendly structure

• responsive design

• optimized assets from day one

Instead of fixing performance later, I prefer building with performance in mind from the beginning.

If you're interested in my work or want to collaborate on a project, you can explore my portfolio.

Or contact me directly.

🔗 Final Thoughts

Getting the performance score from 38 to 95 wasn’t about one trick or one tool.

It was mostly about:

• simplifying things

• removing unnecessary weight

• optimizing carefully

• and thinking more about users than visuals

And honestly, this project taught me more about frontend development than many tutorials ever did.

You can also explore my other technical blogs and development insights.

✍️ About the Author

Written by Aamir Jawed — Full Stack Developer focused on modern web applications, SEO-friendly websites, and scalable frontend architecture.