Refactoring Hero Glow Effects into a Shared Next.js Component

While reviewing the Home, About, and Blog pages of my Next.js site, I noticed that the hero sections were visually close but not fully consistent. Each page had its own version of the glow background. The Blog page had the strongest visual direction, with a soft slate-to-white background and sky/indigo glow layers, while Home and About had separate versions that did not fully match.

The issue was not that any single page looked broken. The issue was that the site did not feel like one coherent interface.

This note documents how I refactored the hero glow effect into a shared HeroGlow component so Home, About, and Blog could use the same visual language.

The original problem was design inconsistency caused by duplicated visual logic.

Home, About, and Blog each had their own hero background implementation. They used similar ideas, such as soft gradients, light effects, and blurred glow shapes, but the details were not identical.

That created a subtle mismatch:

This kind of issue is easy to miss because nothing is technically broken. The page still builds, the layout still works, and the design still looks acceptable. But across multiple pages, the inconsistency becomes more visible.

Visual consistency is not only an aesthetic detail. It affects how stable and intentional a site feels.

For a small technical site, the hero section is often the first area a visitor sees. If the Home, About, and Blog pages each use a slightly different background language, the site can feel like separate pages stitched together instead of one system.

The better approach is:

This also makes future maintenance easier. If the glow effect needs to be adjusted later, I should not have to update three separate files.

At first, it is tempting to treat this as a small styling issue.

For example, I could manually adjust Home and About until they looked closer to Blog. But that would only fix the current surface-level mismatch.

The deeper issue was structural:

That is fragile. Manual consistency works only until one page changes and the others fall behind.

The better fix was to extract the glow effect into a reusable component.

The main change was to create a shared component:

Instead of letting each page define its own background glow layers, the shared component owns the hero background language.

The goal of the component is simple:

This turns the glow effect from a page-specific decoration into a reusable design-system element.

After creating the shared component, I updated the main pages that used hero glow styling:

The Blog page already had the visual direction I wanted to keep. So instead of redesigning everything from scratch, I used the Blog hero style as the reference and moved that visual structure into HeroGlow.

Then Home and About were updated to use the same shared glow system.

The result is:

Now the three pages share the same background language instead of each maintaining its own version.

The glow background was not the only consistency issue. The right-side cards on Home and About also needed to feel closer to the Blog page.

The adjustment was to move those cards toward the same visual style:

This matters because a shared background alone is not enough. If the cards sitting on top of the background use very different styling, the page can still feel inconsistent.

The goal was not to make every page identical. The goal was to make the pages feel like they belong to the same interface system.

Before the refactor, the structure looked like this:

That meant visual consistency depended on three separate implementations staying aligned.

After the refactor, the structure became:

This is a better structure because the design source of truth is now centralized.

Copying the Blog glow styles into Home and About would have produced a similar visual result in the short term, but it would not solve the maintenance problem.

Copy-paste creates hidden debt:

A shared component avoids that. It makes the design decision explicit:

That is cleaner than repeating the same glow layers across multiple pages.

After the refactor, I verified that the site still built and that the key pages still responded correctly.

The checks were:

This verification step matters because a shared component can affect multiple pages at once. If the component import or rendering logic is wrong, the error may break more than one route.

Since the build passed and all three routes responded correctly, the refactor was safe.

The useful mental model is:

A glow background may look like a small visual detail, but once it appears across several main pages, it becomes part of the site’s design system.

At that point, it should not be maintained separately on every page.

The biggest lesson is that visual consistency should be handled structurally, not manually.

If three pages are supposed to share the same hero language, they should not each implement that language independently. A shared component makes the design easier to maintain and reduces the chance that one page slowly drifts away from the others.

This is especially useful for personal technical sites, where the same person may be designing, writing, and coding. A small component extraction can make the site feel more polished without adding complexity.

The final takeaway is simple:

For this refactor, the shared HeroGlow component made Home, About, and Blog more visually consistent. It also made future changes easier because the glow effect now has one source of truth.

This is the kind of small frontend refactor that improves both design quality and code maintainability.