Performance Is Just a Myth

Who am I

Mandela Winnie Product Associate , AHA

Performance in Angular Applications

• Debugging the myth around application perfomance in Angular . Covering from SSR , Partial Hydration to Web Core Vitals

Core Web Vital

1. Largest Contentful Paint (LCP): How Fast Does it Load?

• Time to render the largest visible content element.

• Examples of LCP Elements:

  • <img> elements

  • <img> elements inside an <svg> element

  • <video> elements

  • Elements with a url() loaded background image

  • Block-level elements with text nodes

• **What affects this : ** Image handling, placeholder content for deferrable views, hydration configuration.

2. Cumulative Layout Shift (CLS): How Stable is the Application?

• Quantifies unexpected changes to the page layout.

• Calculation: Impact Fraction (how much of the viewport) * Distance Fraction (how far from the start position).

• Mitigation Strategies (Preview): Image handling, placeholder content for deferrable views, hydration configuration.

3. Interaction to Next Paint (INP): How Responsive are User Interactions?

• Measures the latency of all interactions from the user.

• Examples :

  • Mouse clicks
  • key presses
  • touchscreen taps.

• What affects them : Change detection cycles, code efficiency, bundle size.

---

Tree Shaking: The Code Diet

• Removing "dead code"

• Doesn't handle private class properties, methods, dependencies, styles

• Goal: Only ship the code your users need, including general code cleanup.

Code Splitting

• Breaking down the large bundle into smaller, on-demand chunks.

• Angular Builder & ESBuild: How Angular handles code splitting (especially when ESBuild becomes the default build system).

• When to AVOID Code Splitting:

  • Large Enums,
  • Catch-all classes,
  • Large barrel files,
  • Angular Modules (can prevent effective splitting).

• Key Technique: Lazy Loading (e.g., routes, defer blocks).

---

Deferrable Views (Angular @defer)

• Making the HTML dynamic by adding JavaScript to portions of static HTML.

• Introducing @defer (Angular v17+ Preview, v18 Stable):

  • Tells ESBuild to split code inside the block into a lazy-loaded bundle.

  • Before v17: Lazy loading was done mainly in the Router Module (misuse of auxiliary routes).

Basic Structure and Blocks

• @defer

  @defer {
   }
  
  

• @placeholder (Optional, but Recommended):

  Code snippet

  @defer { /* ... */ }
  @placeholder (minimum 500ms) {
    }
  
  

  • Default Trigger: on idle (wraps requestIdleCallbackAPI to queue requests; no guarantee to run in the next cycle).

• @loading (Optional):

  Code snippet

  @defer { /* ... */ }
  @loading {
    }
  
  

  • Can use after and minimum options.

• @error (Optional):

  Code snippet

  @defer { /* ... */ }
  @error {
    }
  
  

  • (Not sure if there's a retry feature.)

---

Defer Triggers: When to Load?

• on Options (Specify a trigger, can be combined as OR conditions):

  • on viewport (element): Wraps the IntersectionObserver API to watch the trigger element. Watches the placeholder by default, or can accept a template reference variable.

  • on interaction (element): Triggered by click or keydown event (same as above).

  • on hover (element): Triggered on mouse hover.

  • on immediate: Triggered when rendering is finished.

  • on timer(duration): Loads after a specified duration.

  • on idle: Default, when the browser is idle.

  • when (truthy expression): Useful for feature flags.

• prefetch Option:

  Code snippet

  @defer (on interaction; prefetch on idle) { /* ... */ }
  
  

  • Accepts fine-tuning by preloading chunks. Fetches and stores the code until the trigger is met.

Side Effects

• Limitations:

  • Content projections don't work as expected.

  • Loading/injection of environment variables within defer blocks can be challenging.

• Requirements:

  • The deferred component must be Standalone.

  • The parent component must also be Standalone.

  • The deferred component must not require an import in the parent's imports array.

---

Server-Side Rendering (SSR)

• Client-Side Rendering (CSR) means an empty HTML skeleton initially, leading to slow LCP.

• Send an HTML skeleton with content on the first load, reducing the amount of time for the user to see content (improving LCP).

The Journey of Angular SSR

• Angular Universal (Angular 4, 2017): Introduced to handle performance and SEO.

• Destructive Hydration (Angular v16): Initially, Angular destroyed the server-rendered content to show a new one.

• Non-Destructive Hydration (Angular v17, 2023): Welcome! Reuses server-rendered DOM instead of killing it.

• Enhanced SSR (Angular v18, 2024): Further improvements and debugging tools.

• SSR Application Builds: Requires two builds – one for the server (e.g., Node.js Express) and one for the browser.

---

Non-Destructive Hydration in Detail

• Introduced in v16, refined in v17: Reuses server-rendered DOM, significantly improving Web Vitals and SEO.

• How it Works: Transfers data fetched on the server and persists the application state by attaching client-side Angular to the existing DOM.

Event Replay

• Addresses the time gap between when the view is usable versus when the view is seen.

• Uses the event dispatch primitive to record user interactions during this gap and replays them when the client-side application is fully connected.

How to Add & Considerations

• Can be added using the Angular CLI (ng add @angular/ssr) to new or existing projects.

• Manual configuration involves provideClientHydration().

• DOM Manipulation Concerns: Direct DOM manipulation (accessing the document, querying specific DOM elements, appendChild, innerHTML/outerHTML, detaching/moving DOM nodes) can conflict with hydration.

SSR-Specific Hooks & Opt-Outs

• Browser-Only Hooks:

  • afterNextRender(): Runs one time, useful for initializing third-party APIs or browser-specific functionalities.

  • afterRender(): Runs after every change detection cycle.

• ngSkipHydration: A directive to opt out components that cannot be refactored to be hydration-compatible.

---

Static Site Generation (SSG) / Prerendering

• Angular Prerendering: Prerenders HTML files at build time, which can then be cached and served.

• Benefits: Lowers Time to First Byte (TTFB Web Vital). Good for static views.

• Limitations: Not good for highly dynamic views.

• Hybrid SSG: You can configure a hybrid approach, combining SSG for static parts and SSR/CSR for dynamic parts.

Files Added with SSR/SSG Configuration

• server.ts: Node.js Express server to redirect static assets and API routes.

• main.server.ts: The main application bootstrap file for the server.

• provideServerRendering(): For server-side rendering setup.

• provideClientHydration(): For client-side hydration setup.

---

Angular Rendering Modes: A Quick Recap

• 1. Server-Side Rendering (SSR): Renders the application for each request made (client receives HTML).

• 2. Client-Side Rendering (CSR): The default Angular behavior (client receives an HTML skeleton, then JavaScript renders content).

• 3. Prerender (SSG): Pre-renders the HTML at build time for static views.

---

Tracking Performance & Gathering Metrics

• Why Track? What gets measured, gets improved!

• Key Metrics to Monitor: LCP, CLS, INP, Bundle Size, TTFB.

• Tools & Techniques:

  • Lighthouse audits.

  • Web Vitals Chrome extension.

  • Google Search Console (for real-user data).

  • Real User Monitoring (RUM) solutions.

  • Browser DevTools Performance tab.

  • Custom application-specific metrics.

---

---

Q&A

Questions?

Thank You!

---

This Markdown output provides the full content of your presentation, organized with headings and bullet points, ready to be used as a script or pasted into a document. Let me know if you'd like any specific sections rephrased or expanded!