“We know our site speed needs work, but we don’t know where to start” — why we stopped chasing all three Core Web Vitals at once

“We know our website is slow, but we don’t know what to fix first.”
“We check Core Web Vitals, but the numbers don’t tell us where to start.”
“We improved the score once, but after a few months, the site got heavy again.”

These are the kinds of comments that often come up in website operations.

Site speed is important, but it is also easy to postpone. You open a tool, see LCP, INP, and CLS lined up, and understand that something needs to improve. But when all three scores look like problems, it becomes hard to decide what to do first.

We were in the same situation.

We knew what Core Web Vitals were. We knew our scores were not great. But because we were trying to look at all three metrics at once, the work kept getting stuck.

So we changed the way we approached it.

Instead of trying to fix LCP, INP, and CLS evenly, we focused first on “the single worst one.” That shift made both the work and the numbers easier to move forward.

In this article, we’ll walk through how we approached Core Web Vitals improvement, how we measured the problem, and how we turned site speed work into something we could continue as part of regular operations.

Why this problem happens

Background 1: Core Web Vitals can make priorities unclear

Core Web Vitals are three metrics Google uses to evaluate user experience on a page.

• LCP, or loading speed: how long it takes for the main content to finish appearing. The target is within 2.5 seconds.
• INP, or response to input: how quickly the page responds after a user taps a button or link. The target is within 200 milliseconds.
• CLS, or layout shift: how much the page jumps around while loading. The target is within 0.1.

The important point is that these scores are not judged by whether the page loads quickly once on your own phone.

What matters is the experience of real users visiting the site from different devices, networks, and environments. In other words, a site can feel fine in your own environment and still have problems for actual visitors.

Once you understand that, the list of possible fixes quickly grows.

You might need to reduce image size.
You might need to review scripts.
You might need to reserve space for banners or images.
You might need to adjust elements that load late.

Each task may be valid, but trying to handle everything at once can make the priority order blurry.

Background 2: the issue is often not technical skill, but not knowing what hurts the experience most

At first, we tried to improve all three metrics at the same time.

We worked on images for LCP, scripts for INP, and layout stability for CLS. On paper, that sounds reasonable. But in practice, we spread ourselves too thin.

Each fix stayed half-finished, and we could not clearly tell which work should come first.

Looking back, the issue was not simply a technical one.

The real problem was that we started working before identifying which metric was hurting the user experience most.

For site speed improvement, listing every possible fix is less useful than finding the biggest bottleneck first.

Steps to solve it

STEP 1: make the current situation visible

The first step is to compare the three Core Web Vitals metrics and identify the single worst one.

At this stage, it is important to separate lab data from real-user data.

A lab measurement, taken once in your own environment, is useful for investigation. It can help you find whether an image is too heavy, a script is slowing things down, or a layout element is shifting during load.

But lab data alone is not enough to judge whether the page is truly passing for users.

For that, you need field data: the experience of people who actually visited the site.

Our rough process was:

1. Look at real-user data first to see which of LCP, INP, or CLS is performing worst.
2. Use lab measurements to investigate what element on the page is causing the issue.
3. Fix only that one issue first.
4. Check again after the data has had time to settle.

The key is not to start by fixing everything.

Start by choosing one metric.

STEP 2: record and review it as part of monthly operations

In our case, the metric dragging us down was CLS.

The page was jumping while loading. Images and banners were loading late, then pushing down text that had already appeared on the screen.

The fix itself was not flashy. We reserved space for those images and banners in advance so they would not push the content down after loading.

But because we focused on the worst metric first, the improvement was much easier to see.

What mattered just as much was recording the work.

We kept track of:

• when we measured the page
• which metric was performing worst
• which page we checked
• what we changed
• how the score moved afterward

This record helps prevent site speed work from becoming a one-time project.

Websites are always changing. Images are added. Banners are updated. Features are introduced. Even if the site becomes faster once, it can gradually slow down again through normal operations.

That is why speed improvement needs to become part of a regular review cycle.

When checking access data alongside site performance, a feature like MONJI+’s Google Analytics integration can help keep the numbers close to the usual website operations workflow.

STEP 3: use several weeks of data before deciding what to do next

Site speed improvements do not always show their full effect the next day.

Lab scores can change quickly after a fix. Field data, however, reflects the experience of real visitors over time. That means the numbers may not immediately move to a perfect score after one update.

This waiting period is important.

If you panic and start changing other parts of the page too soon, it becomes harder to understand which fix actually worked.

Our workflow looked like this:

1. Use real-user numbers to identify the weakest metric.
2. Use lab measurements to find the likely cause.
3. Fix only the weakest metric first.
4. Record what changed and when.
5. Wait a few weeks and check the real-user numbers again.
6. Once things settle, move on to the next weakest metric.

This made the work easier to explain, too.

For website operators and production teams, there are often moments when you need to explain to a client or internal team why a certain fix was prioritized.

Having a record of what was measured, what was changed, and how the number moved makes that conversation much clearer.

MONJI+’s WebOps platform is one way to support this kind of ongoing website operation, review, and improvement across a team.

What actually changed

Once we stopped chasing all three metrics at once and focused on the single worst one, the work became much easier to move forward.

The biggest change was that we had less hesitation.

Before, LCP, INP, and CLS all felt important. Because everything looked urgent, it was hard to choose where to begin.

After narrowing the focus to one metric, investigation and implementation became more concrete.

In our case, that metric was CLS.
Images and banners loading late were pushing text downward, so we reserved the display area in advance.

As a result, the CLS number improved significantly.

Of course, that did not mean the work was finished forever. Site speed can get worse again as pages are updated. That is why we now see recording, checking, and reviewing as part of the improvement itself.

Limits and cautions

There is one thing we want to be honest about.

Improving site speed does not automatically create results.

Even if a page becomes faster, it will not lead to sign-ups if the content does not communicate clearly. Even with a perfect score, users may still leave if the path to the next action is hard to understand.

We see site speed as maintenance for the entrance.

It helps prevent visitors from leaving before they even see the page properly. But it is not, by itself, the thing that creates conversions.

That is why it is important not to chase Core Web Vitals scores too narrowly.

We try to look at speed together with access data and visitor drop-off. When these are reviewed together, site speed improvement becomes part of broader website operations rather than just score chasing.

MONJI+, a WebOps platform born from the field

Site speed improvement should not end after one fix.

Measure.
Fix the single worst metric.
Record what changed.
Measure again.

This quiet loop is what helps keep a website fast over time.

MONJI+ is a WebOps platform created to solve the kinds of website operations challenges we have felt firsthand in the field.

MONJI+ brings the people involved in website operations together into one team, helping them work across different phases of website management and improvement.

We are not trying to build a product that is “complete” from the beginning.

The challenges that truly matter are found in the day-to-day reality of website operations. That is why we continue listening to real voices from the field.

By taking in each comment, resolving small points of friction, and continuing to update the product, new features have grown out of actual operational challenges.

“I wish this part worked differently.”
“This check would be easier if the team could see it together.”
“We want to catch small issues before they become bigger problems.”

When those thoughts come up, we would be glad to hear them through the MONJI+ co-creation page.

▼ Learn more about MONJI+
https://monji.tech/plus/

▼ Start free
https://tool.monji.tech/signup

Summary

When improving Core Web Vitals, trying to fix LCP, INP, and CLS all at once can make it difficult to set priorities.

In our case, we started by focusing on the single worst metric. That made both investigation and implementation easier, and it led to a significant improvement in CLS.

The workflow that helped us was:

• Look at real-user data and identify the weakest metric.
• Use lab measurements to find the cause.
• Fix only that one metric first.
• Record the fix and the date.
• Watch the field data for a few weeks.
• Once things settle, move to the next weakest metric.

Site speed does not create results on its own.

But it does prepare the entrance so visitors can view the page without unnecessary stress. By looking beyond the score and reviewing speed together with access data and drop-off points, site speed improvement becomes a sustainable part of website operations.