“Did Adding Videos Make the Site Heavier?” — How We Started Checking Page Weight Before Launch

“After we added more videos, the site somehow feels heavier.”

“The page looks fine, but the first screen takes a little longer to show.”

“We want to use video, but we’re not sure we’re checking performance properly before launch.”

These are the kinds of concerns that often come up in day-to-day website operation.

Videos are powerful. On recruiting pages, service pages, facility tours, and brand pages, they help communicate atmosphere and detail that text and images alone cannot always convey.

But the more videos you add, the easier it becomes for the page to feel heavy.

What makes this tricky is that nothing may look broken. The layout is fine. The links work. The video appears where it should. Yet the first screen may still take longer to load.

In Chrome 148, loading="lazy"—previously available for images and iframes—became usable on <video> and <audio> as well. This allows video and audio loading or autoplay to be deferred until just before the element enters the viewport.

When we saw this update, what struck us first was not the syntax itself.

It was this question:

“On video-heavy pages, who is checking page weight before launch?”

This article reorganizes our original note into a practical WebOps workflow: how to add “weight” checks to your pre-launch process, how to turn findings into Feedback, and how to review the impact afterward.

---

Why this issue happens

A video-heavy page does not become a problem simply because “video files are large.”

The issue is also operational. In many website teams, visual checks and performance checks are treated as separate tasks. As a result, page weight can slip through the cracks.

Background 1: If the page does not look broken, it is easy to call it “done”

When adding videos to a recruiting page or facility page, teams usually check the visible output first.

Does the video display?
Is the layout broken?
Are the links working?
Does it look okay on mobile?

These checks are necessary.

But they do not always reveal page weight.

A page may look perfectly fine while still trying to load multiple videos as soon as it opens. If that happens, the first screen can take longer to appear. For visitors, even a few seconds of lag can be enough to leave the page.

In other words:

“Displayed correctly” and “displayed lightly” are not the same thing.

That distinction needs to become part of the pre-launch check.

Background 2: Videos lower down the page may load too early

On pages with several videos, even videos that are not visible at first may start loading as soon as the page opens.

For example:

• videos below the first screen
• videos placed in the middle or lower part of the page
• videos users will only see after scrolling

If these are loaded immediately, they can affect the experience before the visitor even reaches them.

With Chrome 148 supporting loading="lazy" for <video> and <audio>, it becomes easier to defer loading for media that does not need to appear right away.

But knowing the feature exists is not enough.

The important operational question is:

“Which videos need to load immediately, and which can wait?”

---

Steps to solve it

We added “page weight” to our pre-launch checks for video-heavy pages.

Here is the workflow we now use.

STEP 1: Make the current state visible

The first step is to understand where videos and audio appear on the page, and when they are being loaded.

Before launch, we check points such as:

• Is this video visible on the first screen?
• Is it only visible after scrolling?
• Does it really need autoplay?
• Is the first paint heavy on desktop?
• Is the first paint heavy on mobile?
• Are there related issues, such as broken images or broken links?

The most important check is whether videos that are not visible on the first screen are being loaded too early.

Relying on memory for this kind of check is risky. So we added speed-related items to the checklist feature in MONJI+.

For example:

1. Did we set lazy loading (loading="lazy") for video or audio that does not appear on the first screen?
2. Did we separate videos that must appear immediately from videos that can be deferred?
3. Did we sort videos that need autoplay from videos that do not?
4. Did we check first-paint weight on both desktop and mobile?

Turning these into checklist items makes the review easier to repeat, even when the person in charge changes.

STEP 2: Record issues as part of monthly operation

When we find a heavy page, we turn it into Feedback immediately.

It is easy to think, “We’ll make it lighter later.” But in daily website operation, that kind of issue often gets buried. That is why we create Feedback on the spot, assign an owner, and set a due date.

For example, we may record items like:

• This lower-page video should use lazy loading.
• This video may not need autoplay.
• The first load feels heavy on mobile.
• After the fix, we should check whether drop-off changes.

In MONJI+, these findings can be managed as Feedback tied to the relevant page.

When production is handled by an external vendor, sharing only the in-progress Feedback through a public link also makes communication easier. Instead of saying “the page feels heavy,” we can point to a specific issue: “this video on this page is heavy.”

Video-heavy pages are also more likely to have related issues such as broken images or broken links. We use MONJI+’s website issue detection to crawl pages in bulk, then route detected issues into Feedback.

The point is not to treat video weight as a one-time technical check.

It should become part of the normal website operation flow.

STEP 3: Review the results over time

Fixing the issue is not the end.

After making changes, we check how the page’s drop-off changed using the Google Analytics integration in the same project.

Of course, drop-off is not determined by page weight alone.

Content, traffic source, timing, user intent, and many other factors can affect the numbers. So we do not assume that “making it lighter” automatically improves everything.

Instead, we connect the fix with the movement in the numbers and look back on whether the change seemed meaningful.

We also record which video was placed, when it was placed, and why it was placed in the project Wiki.

That makes the next review easier.

For example, we can look back and see:

• This video was needed for recruiting.
• This video helped explain the service.
• This video was placed lower down the page, so we deferred loading.
• This video may be a candidate for replacement later.

In WebOps, decisions become harder to review when the reason behind them is not recorded. For videos especially, where teams must balance visual impact and page weight, leaving a decision trail matters.

---

What changed in practice

After adding “can this video loading be deferred?” to our pre-launch checks, our review perspective changed.

Previously, we mostly checked whether the video appeared correctly and whether the layout looked right.

Now we also check:

• Does this video need to load immediately?
• Can this video be deferred?
• Is autoplay necessary?
• Is the first screen heavy on mobile?
• Can we review the numbers after the fix?

By turning heavy pages into Feedback right away, we also made it less likely that issues would be noticed once and then forgotten.

Using video is not the problem.

In many cases, video is exactly what a page needs.

The important thing is to check not only whether the video was added, but also whether the page can still be viewed comfortably.

---

Notes and limitations

Even with a better workflow, not everything can be automated.

Tools and checks can help surface the fact that a page is heavy. But they cannot fully decide which videos should stay, which should be deferred, and which should be removed.

That decision depends on the purpose of the page.

On a recruiting page, a video showing the atmosphere of the workplace may be important. On a facility page, video may communicate details better than text. On the other hand, a supporting video lower down the page may be fine to defer or reconsider.

A tool can help find the weight.

But the final decision—“keep this,” “defer this,” “remove this”—needs to stay with the people who understand what the page is trying to communicate.

That is the line we draw: let the system help us find issues, and let people make the final content decisions.

---

MONJI+: A WebOps platform born from the field

As this example shows, checking video-heavy pages is not only about adding one more technical item to a launch checklist.

It also involves recording issues, assigning Feedback, reviewing results, and preserving the reason behind content decisions.

MONJI+, the WebOps platform, was born to solve the challenges we have felt firsthand in the field.

MONJI+ brings the people involved in website operation together into one team, and works across every phase of website operation to solve their challenges.

From the start, we have never aimed to build a “finished product.”

The challenges truly worth facing are out in the field of website operation. That is why we keep engaging with the real voices there.

Taking in each voice one by one, we have continued making updates that resolve small points of friction. New features have also grown out of the field’s challenges.

Through that accumulation, MONJI+ has become something supported by users across 77 countries.

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

A world where the people working in website operation can say, with pride, “I love this work.”

▼ To make that real, we are waiting to hear your voice
https://monji.tech/plus/co-creation/

---

Summary

Video-heavy pages may feel slow even when nothing looks broken.

With Chrome 148, loading="lazy" can be used on <video> and <audio>, making it easier to defer video and audio that do not need to load immediately.

But simply knowing about the feature does not change website operation.

What matters is adding “page weight” to the pre-launch checklist.

We now check whether videos outside the first screen can be deferred, record heavy pages as Feedback, review changes through the Google Analytics integration, and keep the reason for each video placement in the Wiki.

Videos can make a website more expressive.

That is exactly why we believe teams should not stop at “we added the video.” They should also ask, “Does the page still feel light enough?” and “Does this video serve the purpose of the page?”