Best practices for Minify or Merge CSS and JS files in a aem-boilerplate-commerce project ?

@rabiirahmouni 

1. Build Pipeline Integration: Monorepo vs. Split Repos for ClientLibs

Best Practice: Keep the frontend build tooling co-located within the AEM repo, especially for Content and Experience-Driven projects (like AEM Commerce).

Why:

• Tighter integration with the ui.apps structure (eg. clientlibs paths)

• Easier local dev experience using mvn clean install and npm run build

• Simplifies deployment via Cloud Manager or Jenkins pipelines

Alternative (if you're scaling fast):

• Use a separate frontend repo (monorepo style or micro-frontend-based)

• Output the final /dist or /build assets directly to:

  ui.apps/src/main/content/jcr_root/apps/<project>/clientlibs/<bundle>

• Sync it using a Git submodule, CI/CD artifact copy step, or symbolic linking (npm run build:copy-to-clientlib)

Choose this route if you have independent teams maintaining design systems or shared components across multiple sites.

2. Performance Monitoring of Page-Type Bundling

Absolutely - here’s how we measure performance gains per bundle:

Core Web Vitals (CWV) – Our Go-To Metrics:

• LCP (Largest Contentful Paint) -> most sensitive to CSS blocking

• FID (First Input Delay) -> influenced by JS bundle execution

• CLS (Cumulative Layout Shift) -> mostly layout CSS + async script order

Tools We Use:

• Lighthouse CI -> integrate into PR validation

• WebPageTest -> simulate 3G/mobile loads

• New Relic / Datadog RUM -> enterprise-level Real User Monitoring

• Adobe Monitoring (Cloud Manager pipeline also gives some CWV)

• Custom window.performance.mark() hooks to measure JS load time for each bundle

Bundle-level Tracking:

We use bundle-specific names (eg. pdp-bundle.js, plp.css) and:

• Track in browser DevTools -> see which bundle blocks rendering

• Set up performance budgets in Webpack -> alert on bloat

3. Lazy-Loading 3rd-Party Scripts w/ Intersection Observer

Yes! Intersection Observer (IO) is game-changing for fine-tuned lazy-loading of widgets like chat, reviews, recommendation carousels, etc.

Example: Lazy-load Zendesk on visibility

const loadZendesk = () => {
  const script = document.createElement('script');
  script.src = 'https://static.zdassets.com/ekr/snippet.js?...';
  script.async = true;
  document.body.appendChild(script);
};

const observer = new IntersectionObserver((entries, obs) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      loadZendesk();
      obs.disconnect();
    }
  });
}, { threshold: 0.25 });

const target = document.getElementById('zendesk-widget-placeholder');
if (target) observer.observe(target);

This keeps the main thread clean during page load and improves TTI/FID scores dramatically.

4. Scaling Page-Type Bundling with Large Product Catalogs

Yes, it scales extremely well, if you scope bundles smartly.

Strategy:

• Bundle per layout complexity, not SKU volume.

  • eg. PLP = grid + filter UI, PDP = tabs + image zoom.

• Reuse shared libraries (react, swiper, etc.) via vendor chunking (eg. vendor.js)

• Use code splitting with Webpack dynamic import() for:

  • Size charts

  • Reviews

  • Personalized recommendations