Why the Same Site Lagged on an Older PC

When the Problem Finally Showed Up

So what happened is, I was almost done with the design, and everything felt fine on my PC. I was using AI for design ideas and the visual side — animations, transitions, and small effects — mostly to work faster. Everything was running smoothly, so performance wasn’t really on my mind.

Once the main part of the design was ready, I published the site and sent the link to a friend so he could test it on his PC and see how it looked there.

That was the first time I really saw the problem. The same page that felt smooth for me was noticeably heavier on his machine. Some animations were lagging, and the site simply didn’t feel the same.

That was when I stopped looking only at the design and started trying to understand what was actually going wrong.

Why Was the Antigravity Site Still Smooth?

At first, I tried the normal things. I made some animations simpler, changed a few parts, asked AI, tried different optimizations, and tested again.

Some of it helped, but the lag was still there.

What confused me was that I had already seen websites with much more animation than mine running smoothly. One of them was Google’s Antigravity.

Their website had much more going on visually than my project, so I opened it on the same older PC where my site was struggling.

It was still smooth.

If the same computer could handle a website with more animation than mine, then I couldn’t just say the PC was too weak or that animations were the problem.

So I started looking deeper into what was actually happening while those animations were running.

What Was Still Running?

That’s when I realized some of my animation loops were still doing work when they didn’t need to be.

While building the design, I was mostly thinking about the visual result — how the animation moved, how smooth it looked, and whether it matched the page. I wasn’t really thinking about what happened after I scrolled away from that section.

In my case, some animation loops were still doing work even after those sections were no longer visible. One loop by itself might not be a big deal, but when you have several animations and effects across the page, that extra work starts adding up.

My PC could handle it well enough that I didn’t really notice. On an older machine, the cost was much easier to feel.

Once I understood that, I finally had something real to fix instead of just trying random optimizations.

Fixing It Was Harder Than Finding It

Finding the problem was one thing. Fixing it this late in the project was another.

By that point, the design was already almost finished. The animations were already connected to different components and sections, and I hadn’t built them from the beginning thinking about when they should run or when they should stop.

So I started going back through the project and changing that behavior. If an animation wasn’t needed anymore, I didn’t want it doing unnecessary work in the background. When the section became relevant again, the animation could run again.

The idea sounds simple, but applying it to a project that was already almost finished wasn’t.

What happens when the user scrolls back? Should the animation restart? Does another part of the component depend on it? Will changing this break something else?

Those were the things that made the fix harder than I expected.

I had to reopen parts of the project I already thought were finished and change how they worked. I spent around a week or two testing different approaches, fixing problems, and slowly getting the performance into a much better state.

The more I worked on it, the more obvious it became that most of this would have been easier if I had thought about performance earlier.

What I Learned From It

The mistake wasn’t using animations.

It was thinking about performance too late.

I had been treating design and performance like two separate jobs: first make the page look good, then optimize it later. I don’t want to work that way anymore, especially when I know I’m building something with a lot of animation, video, 3D, or anything else that can keep the browser busy.

Performance needs to be part of the thinking while I’m building those things, not after everything is already connected.

I learned the same thing about AI.

I use AI a lot, and I’m going to keep using it because it helps me work faster. But I can’t depend on it completely. If I ask AI to build an animation or improve a visual section, it can help me do that, but I still need to understand what the code is doing, whether some of that work really needs to keep running, and how the result behaves on a weaker machine.

The other lesson was testing.

My own PC made the project look fine because it was powerful enough to handle what I had built. I only saw the real problem when I tried the same site somewhere else.

Next time, I want performance to be part of the design from the beginning, not something I think about when the design is almost done.