PageSpeed Front-end (NDA): How We Actually Speed Up Real Sites Without Breaking Product Flow

Most teams meet performance too late.

At first, everything looks fine: animations are smooth on your laptop, design is approved, and the sprint closes on time. Then a real report arrives from a real device on a weak network, and suddenly your normal page opens like a heavy desktop app from 2014.

This guide is not about chasing a perfect Lighthouse screenshot. It is about making the site feel quick for people who do not have perfect hardware, perfect Wi-Fi, or infinite patience.

When we worked on a content-heavy site with modal flows, media sections, and interactive blocks, the biggest gain came from one mindset shift: stop loading everything "just in case".

Start with composables, not patches

A lot of optimization pain starts when UI logic is welded directly into page files. You cannot delay-load code safely if that code is tangled with five unrelated concerns.

So the first move is architectural, not magical: isolate behavior.

A small useModal composable is a good example. It does not care which modal is open or what fields are inside. It only manages state and page lock.

~~~ts import { ref } from 'vue'

export function useModal() { const isOpen = ref(false)

const open = () => { isOpen.value = true document.body.classList.add('modal-open') }

const close = () => { isOpen.value = false document.body.classList.remove('modal-open') }

return { isOpen, open, close } } ~~~

When this logic is isolated, you can import it exactly when user intent appears.

Dynamic import on click: user asked, now load

If a visitor never opens your feedback modal, there is no technical reason to parse its validation layer, masks, and UI helpers on first paint.

~~~ts let modalModulePromise: Promise | null = null

export async function openFeedbackModal() { if (!modalModulePromise) { modalModulePromise = import('@/features/feedback-modal') }

const modalModule = await modalModulePromise modalModule.mountFeedbackModal() } ~~~

This tiny cache pattern removes repeated network and parsing work and keeps interaction instant after the first open.

In practice, this usually gives you a better first render and less JavaScript pressure in the entry chunk.

Dynamic import on scroll: load only near visibility

Interactive sections are expensive even when they are visually beautiful. Sliders, 3D blocks, and heavy galleries should wake up only when the user is approaching them.

~~~ts export function observeAndLoad( target: Element, loader: () => Promise, rootMargin = '100px' ) { const observer = new IntersectionObserver(async ([entry]) => { if (!entry.isIntersecting) return observer.disconnect() await loader() }, { rootMargin })

observer.observe(target) } ~~~

Usage stays clean in page code:

~~~ts const galleryRoot = document.querySelector('[data-gallery-root]')

if (galleryRoot) { observeAndLoad(galleryRoot, async () => { const { initGallery } = await import('@/widgets/gallery') initGallery(galleryRoot) }) } ~~~

The rule is simple: if user never scrolls there, you never pay for that feature.

SVG sprite split: hidden win nobody sees, everyone feels

One giant sprite file looks convenient in development and quietly hurts in production. The browser still parses that huge markup even if the page needs only two icons.

A better structure is boring but effective:

• base-sprite.svg for icons shared across layout shell
• home-sprite.svg, pricing-sprite.svg, blog-sprite.svg for local usage

You keep global icons available everywhere and avoid dragging unrelated icon payload into lightweight pages.

Media strategy that respects bandwidth

A fast page is often decided by image and video behavior, not by framework choice.

Use modern formats, keep dimensions honest, and lazy-load what is below the fold.

~~~html ~~~

~~~ts const mediaNodes = document.querySelectorAll('img[data-src]')

const mediaObserver = new IntersectionObserver((entries, observer) => { for (const entry of entries) { if (!entry.isIntersecting) continue const img = entry.target as HTMLImageElement img.src = img.dataset.src || img.src observer.unobserve(img) } }, { rootMargin: '120px' })

mediaNodes.forEach((node) => mediaObserver.observe(node)) ~~~

The page feels smoother because it stops competing for bandwidth with assets the user has not reached yet.

Caching and CDN are multipliers, not medicine

Cloudflare and cache headers can amplify a good build. They cannot rescue an overloaded one.

If your initial payload is huge and main-thread work is heavy, CDN only delivers heavy bytes faster. So do cleanup first: split code, defer non-critical blocks, trim media, remove dead dependencies. Then add infrastructure acceleration.

How this changes delivery culture

The biggest long-term performance gain is cultural: each merge request is reviewed not only for correctness, but also for weight.

A healthy team asks:

• What did this feature add to the entry bundle?
• Can this logic wait for click or visibility?
• Did we increase CPU work on first paint?

When these questions become routine, PageSpeed grows steadily instead of jumping once and degrading every sprint.

Final thought

You do not need to rebuild everything to get a faster product. You need an architecture that allows selective loading, and a team habit that protects this architecture every week.

That is the real optimization system: less heroics, more engineering discipline.