Refactor/lazy load page components

[s0merset]

Summary

This PR implements lazy loading for page components, addressing the performance issue described in #212 . The goal is to optimize initial load time by reducing the main bundle size, while still supporting smooth navigation between routes.

Changes

• Updated App.tsx to use React.lazy and Suspense for route-based code splitting.
• Ensured fallback UI is displayed while components are being loaded.
• Updated .gitignore to exclude build artifacts (dist/, dist-main/, dist-lazy) and keep the repository clean.

Performance Comparison

Non-Lazy Load:

Lazy Load:

Observations

• Reduced bundle size: Lazy loading cuts down the initial payload, improving the first-page load experience.
• Increased requests: Lazy loading increases the number of requests since chunks are loaded on demand, but each request is smaller.
• Navigation: Once a route has been visited, caching ensures subsequent navigation is instant.

[codegino]

@frb21 are the screenshots from production or dev setup?

[s0merset]

@frb21 are the screenshots from production or dev setup?

The screenshots are from my local dev setup sir...

[KishonShrill]

Hmmmm, I don't know about using this method. It might be too huge of a change that might break other else's code. Wouldn't be:

const <component> = lazy(() => import('path-to-component'));

be better? Then wrapping just one <Suspense> over the whole return function than wrapping every <Route>? I wanna hear your thoughts on this.

[s0merset]

Hmmmm, I don't know about using this method. It might be too huge of a change that might break other else's code. Wouldn't be:

const <component> = lazy(() => import('path-to-component'));

be better? Then wrapping just one <Suspense> over the whole return function than wrapping every <Route>? I wanna hear your thoughts on this.

Hi po, I've updated the PR based on your feedback about the lazy loading approach.

Changes include:

• Moved all lazy component definitions to the top of the file
• Replaced individual createLazyRoute() calls with direct lazy components
• Used a single <Suspense> wrapper around the entire <Routes>

[codegino]

@frb21 are the screenshots from production or dev setup?

The screenshots are from my local dev setup sir...

Would be better if we can see the prod build performance improvement.

Also, it might be better to measure first the components that are really problematic. If they need optimization, then we do proceed.

I'm not a fan of premature optimization, but I don't want to gate keep this very good contribution. I'm leaving to other maintainers.

[niculistana]

Per @codegino could you please deploy to vercel and upload the link here? We see the bundle size diff pero would also like to see if how big of a difference it is with initial loading time.

Either way I'm impartial to this improvement. Since majority of the website is static content, we could look into prerendering?

[s0merset]

Per @codegino could you please deploy to vercel and upload the link here? We see the bundle size diff pero would also like to see if how big of a difference it is with initial loading time.

Either way I'm impartial to this improvement. Since majority of the website is static content, we could look into prerendering?

hello po @niculistana @codegino, is the link for the deployed build on Vercel already available?

[niculistana]

@frb21 familiar po kayo sa vercel? Pwede po kayong gumawa ng account tapos create ka ng project tapos connect nyo yung fork nyo.

For example ito yung fork ko: https://github.com/adobocorp/bettergov

Tapos connect ko sa vercel. After deploy may custom link kayo: https://bettergov-adobo.vercel.app/.

[s0merset]

@frb21 familiar po kayo sa vercel? Pwede po kayong gumawa ng account tapos create ka ng project tapos connect nyo yung fork nyo.

For example ito yung fork ko: https://github.com/adobocorp/bettergov

Tapos connect ko sa vercel. After deploy may custom link kayo: https://bettergov-adobo.vercel.app/.

ay okay po, salamat po sir!

[s0merset]

Hello po @niculistana @codegino, I tried to compare the separate versions after deployment. I navigated to the different components sa two versions and here's what I have found:
Non-lazy:

Lazy:

[niculistana]

Salamat @frb21 paki send po url dito from vercel

[s0merset]

Salamat @frb21 paki send po url dito from vercel

https://bettergov-main.vercel.app/
https://bettergov-main-git-refactor-lazy-load-pa-bdcbee-frb21s-projects.vercel.app/

[niculistana]

Does main have your lazy-load changes? If so can you verify the following report?

Ran pagespeed against main and prod and I don't really see the a big difference because our pages contain bundle sizes that aren't too heavy.

Main: https://pagespeed.web.dev/analysis/https-bettergov-main-vercel-app/wuw4y9oewf?form_factor=mobile

Prod: https://pagespeed.web.dev/analysis/https-bettergov-ph/oweys6ywz0?form_factor=mobile

Not sure if this is the best recommendation but for now why not run a bundle analyzer and see which bundle is the heaviest and lazy-load just that route? Eager loading is fine for a majority of small bundles.

https://github.com/nonzzz/vite-bundle-analyzer