Add Mermaid diagrams and Overview sections to 8 performance snippets

Enhanced documentation with visual diagrams and contextual overviews:

## Mermaid Diagrams Added:
- LCP-Sub-Parts: Flowchart of 4 phases + optimization decision tree
- Script-Loading: Sequence diagram (replaces ASCII art) + loading strategy decision tree
- Interactions (INP): Sequence diagram of 3 phases + simplified flowchart + optimization decision tree
- CLS: Calculation flow + lifecycle state diagram
- Find-render-blocking-resources: Render-blocking timeline sequence + optimization decision tree
- Long-Animation-Frames: Frame lifecycle flowchart + LoAF vs Long Tasks comparison
- LongTask: Blocking time flowchart + severity levels flowchart
- Layout-Shift-Tracking: Shift phases flowchart + CLS counting logic

## Diagram Improvements:
- Replaced hard-to-read Gantt charts with clear flowcharts
- Added emojis (⏱️📥🎨👆⚙️) for visual recognition
- Consistent color coding (red=critical, orange=warning, green=good)
- Descriptive text with <small> tags for additional context

## Overview Sections Added:
All 8 snippets now include consistent Overview sections with:
- Brief description of the snippet's purpose
- "Why this matters" explaining user impact and performance implications
- Context on when and why to use each snippet

Total diagrams added: 20+
Lines changed: +404 -34 across 8 files

Author: nucliweb

pages/CoreWebVitals/CLS.mdx

@@ -1,6 +1,12 @@
 # Cumulative Layout Shift (CLS)
 
-Quick check for [Cumulative Layout Shift](https://web.dev/articles/cls), a Core Web Vital that measures visual stability. CLS tracks how much the page layout shifts unexpectedly during its lifetime.
+### Overview
+
+Quick check for [Cumulative Layout Shift](https://web.dev/articles/cls), a Core Web Vital that measures visual stability. CLS tracks how much the page layout shifts unexpectedly during its lifetime, providing a single score that represents the cumulative impact of all unexpected layout shifts.
+
+**Why this matters:**
+
+Unexpected layout shifts are frustrating and can cause users to click the wrong element or lose their reading position. CLS directly impacts user experience and is a ranking factor for Google Search. Common causes include images without dimensions, web fonts, and dynamically injected content.
 
 **CLS Rating Thresholds:**
 
@@ -90,6 +96,40 @@ CLS = Σ (impact fraction × distance fraction)
 - Shifts within 500ms of user input (`hadRecentInput: true`)
 - Shifts caused by scroll anchoring
 
+**CLS Calculation Flow:**
+
+```mermaid
+flowchart TD
+    Start[Layout Shift Detected] --> Recent{Within 500ms<br/>of user input?}
+
+    Recent -->|Yes| Exclude[❌ Exclude from CLS<br/>hadRecentInput: true]
+    Recent -->|No| Calculate[✅ Include in CLS]
+
+    Calculate --> Impact[Calculate Impact Fraction<br/>% of viewport affected]
+    Impact --> Distance[Calculate Distance Fraction<br/>distance moved / viewport]
+    Distance --> Score[Shift Score = Impact × Distance]
+    Score --> Accumulate[Add to CLS total<br/>CLS += score]
+
+    style Exclude fill:#FFE5E5
+    style Calculate fill:#E5FFE5
+    style Accumulate fill:#E5F2FF
+```
+
+**CLS Lifecycle:**
+
+```mermaid
+stateDiagram-v2
+    [*] --> PageLoad: Navigation Start
+    PageLoad --> Accumulating: First Shift
+    Accumulating --> Accumulating: More Shifts<br/>(CLS += score)
+    Accumulating --> Final: Page Hidden
+    Final --> [*]
+
+    note right of Accumulating
+        Only shifts where<br/>hadRecentInput = false<br/>are counted
+    end note
+```
+
 ### Common Causes
 
 | Cause | Solution |

pages/CoreWebVitals/LCP-Sub-Parts.mdx

@@ -1,11 +1,28 @@
 # LCP Sub-Parts
 
-Breaks down [Largest Contentful Paint](https://web.dev/articles/lcp) into its four phases to identify optimization opportunities. Based on the [Web Vitals Chrome Extension](https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma).
+### Overview
+
+Breaks down [Largest Contentful Paint](https://web.dev/articles/lcp) into its four phases to identify optimization opportunities. Understanding which phase is slowest helps you focus your optimization efforts where they'll have the most impact. Based on the [Web Vitals Chrome Extension](https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma).
+
+**Why this matters:**
+
+LCP is a critical Core Web Vital that measures when the largest content element becomes visible. By breaking it into sub-parts, you can pinpoint exactly where delays occur and apply targeted optimizations instead of guessing.
 
 **The four phases of LCP:**
 
-```
-Navigation Start → [TTFB] → [Load Delay] → [Load Time] → [Render Delay] → LCP
+```mermaid
+flowchart LR
+    A([Navigation<br/>Start]) --> B["⏱️ TTFB<br/><small>Server Response</small>"]
+    B --> C["⏳ Load Delay<br/><small>Resource Discovery</small>"]
+    C --> D["📥 Load Time<br/><small>Download Resource</small>"]
+    D --> E["🎨 Render Delay<br/><small>Paint Element</small>"]
+    E --> F([✅ LCP<br/>Complete])
+
+    style B fill:#FFE5E5,stroke:#FF4444,stroke-width:2px
+    style C fill:#FFF3E5,stroke:#FF8800,stroke-width:2px
+    style D fill:#FFFBE5,stroke:#FFBB00,stroke-width:2px
+    style E fill:#E5FFE5,stroke:#44AA44,stroke-width:2px
+    style F fill:#E5F2FF,stroke:#4488FF,stroke-width:3px
 ```
 
 | Sub-part | What it measures | Common causes |
@@ -265,6 +282,26 @@ The snippet adds measures to the Performance API. To see them:
 | **Load Time** | Image size, format, compression, CDN |
 | **Render Delay** | JavaScript blocking, CSS parsing, client-side rendering |
 
+**Optimization Decision Tree:**
+
+```mermaid
+flowchart TD
+    Start[Identify Slowest Phase] --> TTFB{TTFB > 800ms?}
+    Start --> Delay{Load Delay > 10%?}
+    Start --> Load{Load Time > 40%?}
+    Start --> Render{Render Delay > 10%?}
+
+    TTFB -->|Yes| TTFB_Fix["✓ Use CDN<br/>✓ Enable caching<br/>✓ Optimize server"]
+    Delay -->|Yes| Delay_Fix["✓ Preload LCP image<br/>✓ Remove render-blocking<br/>✓ Inline critical CSS"]
+    Load -->|Yes| Load_Fix["✓ Compress images<br/>✓ Use WebP/AVIF<br/>✓ Use responsive images"]
+    Render -->|Yes| Render_Fix["✓ Defer non-critical JS<br/>✓ Avoid client-side rendering<br/>✓ Use fetchpriority=high"]
+
+    style TTFB_Fix fill:#FFE5E5
+    style Delay_Fix fill:#FFF3E5
+    style Load_Fix fill:#FFFBE5
+    style Render_Fix fill:#E5FFE5
+```
+
 ### Further Reading
 
 - [Optimize LCP](https://web.dev/articles/optimize-lcp) | web.dev

pages/Interaction/Interactions.mdx

@@ -1,6 +1,12 @@
 # Interactions
 
-Tracks all user interactions in real-time to help debug and improve [Interaction to Next Paint (INP)](https://web.dev/articles/inp). Based on the [Web Vitals Chrome Extension](https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma).
+### Overview
+
+Tracks all user interactions in real-time to help debug and improve [Interaction to Next Paint (INP)](https://web.dev/articles/inp). INP measures responsiveness by tracking the latency of all interactions during a page visit. This snippet breaks down each interaction into three phases to identify bottlenecks. Based on the [Web Vitals Chrome Extension](https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma).
+
+**Why this matters:**
+
+INP is a Core Web Vital that directly affects user experience. Slow interactions make your site feel sluggish and frustrating. By identifying which phase causes delays (input delay, processing, or presentation), you can apply targeted optimizations to make your site feel more responsive.
 
 **INP Rating Thresholds:**
 
@@ -20,9 +26,42 @@ Every interaction consists of three phases:
 | **Processing Time** | Event handler execution | Complex JavaScript, slow handlers |
 | **Presentation Delay** | Rendering after processing | Large DOM updates, layout thrashing |
 
+```mermaid
+sequenceDiagram
+    participant User
+    participant Browser as Main Thread
+    participant Handler as Event Handler
+    participant Renderer
+
+    User->>Browser: Click/Tap/Keypress
+    Note over Browser: ⏳ Input Delay<br/>(waiting for main thread)
+
+    Browser->>Handler: Start processing
+    Note over Handler: ⚙️ Processing Time<br/>(event handler execution)
+    Handler->>Handler: Run JavaScript
+    Handler->>Handler: Update state
+
+    Handler->>Renderer: Request render
+    Note over Renderer: 🎨 Presentation Delay<br/>(render + paint)
+    Renderer->>Renderer: Layout calculation
+    Renderer->>Renderer: Paint
+
+    Renderer-->>User: Visual feedback
+
+    Note over User,Renderer: Total = Input Delay + Processing Time + Presentation Delay
 ```
-User clicks → [Input Delay] → [Processing Time] → [Presentation Delay] → Paint
-              ↑ waiting      ↑ JS executing       ↑ rendering
+
+```mermaid
+flowchart LR
+    Start([👆 User<br/>Input]) --> Phase1["⏳ Input Delay<br/><small>Waiting for main thread</small>"]
+    Phase1 --> Phase2["⚙️ Processing Time<br/><small>Event handler execution</small>"]
+    Phase2 --> Phase3["🎨 Presentation Delay<br/><small>Render + Paint</small>"]
+    Phase3 --> End([✅ Visual<br/>Feedback])
+
+    style Phase1 fill:#FFE5E5,stroke:#FF4444,stroke-width:2px
+    style Phase2 fill:#E5F2FF,stroke:#4488FF,stroke-width:2px
+    style Phase3 fill:#E5FFE5,stroke:#44AA44,stroke-width:2px
+    style End fill:#F0F0F0,stroke:#666,stroke-width:3px
 ```
 
 > **Tip:** The sub-part with the longest duration is usually where to focus optimization efforts.
@@ -255,6 +294,27 @@ Call `getInteractionSummary()` in the console to see:
 | **Processing Time** | Slow event handlers | Optimize handlers, debounce, use web workers |
 | **Presentation Delay** | Expensive rendering | Reduce DOM size, avoid layout thrashing, use `content-visibility` |
 
+**Optimization Decision Tree:**
+
+```mermaid
+flowchart TD
+    Start[INP > 200ms?] --> Analyze{Identify longest<br/>sub-part}
+
+    Analyze --> InputDelay{Input Delay<br/>is longest?}
+    Analyze --> ProcessTime{Processing Time<br/>is longest?}
+    Analyze --> PresDelay{Presentation Delay<br/>is longest?}
+
+    InputDelay -->|Yes| InputFix["⚡ Break up long tasks<br/>⚡ Use scheduler.yield()<br/>⚡ Defer non-critical work<br/>⚡ Use requestIdleCallback"]
+
+    ProcessTime -->|Yes| ProcessFix["🔧 Optimize event handlers<br/>🔧 Debounce rapid events<br/>🔧 Move work to Web Workers<br/>🔧 Reduce JavaScript complexity"]
+
+    PresDelay -->|Yes| PresFix["🎨 Reduce DOM updates<br/>🎨 Avoid layout thrashing<br/>🎨 Use content-visibility<br/>🎨 Batch DOM changes"]
+
+    style InputFix fill:#FFE5E5
+    style ProcessFix fill:#E5F2FF
+    style PresFix fill:#E5FFE5
+```
+
 ### Further Reading
 
 - [Interaction to Next Paint (INP)](https://web.dev/articles/inp) | web.dev

pages/Interaction/Layout-Shift-Loading-and-Interaction.mdx

@@ -1,6 +1,12 @@
 # Layout Shift Tracking
 
-Tracks all layout shifts during page load and user interaction, identifying the elements causing [Cumulative Layout Shift (CLS)](https://web.dev/articles/cls).
+### Overview
+
+Tracks all layout shifts during page load and user interaction, identifying the elements causing [Cumulative Layout Shift (CLS)](https://web.dev/articles/cls). This debugging-focused snippet logs every shift with detailed information about which elements moved and when.
+
+**Why this matters:**
+
+While the [CLS quick check](/CoreWebVitals/CLS) gives you a score, this snippet helps you debug **which specific elements** are causing layout shifts. It shows you the exact selectors, movement distances, and whether shifts were excluded due to user input. This is essential for fixing CLS issues.
 
 **CLS Rating Thresholds:**
 
@@ -22,6 +28,37 @@ Tracks all layout shifts during page load and user interaction, identifying the
 
 > **Note:** Shifts with `hadRecentInput: true` (within 500ms of user input) are excluded from CLS, as they're considered expected by the user.
 
+**Layout Shift Phases:**
+
+```mermaid
+flowchart LR
+    Start([Page<br/>Load]) --> Loading["📄 Loading Phase<br/><small>Initial layout shifts<br/>✅ Count toward CLS</small>"]
+    Loading --> Interact[👆 User<br/>Interaction]
+    Interact --> Window["⏱️ 500ms Window<br/><small>❌ Shifts excluded</small>"]
+    Window --> After["⏳ After Window<br/><small>✅ Count toward CLS</small>"]
+
+    style Loading fill:#E5FFE5,stroke:#44AA44,stroke-width:2px
+    style Window fill:#FFE5E5,stroke:#FF4444,stroke-width:2px
+    style After fill:#FFFBE5,stroke:#FF8800,stroke-width:2px
+```
+
+**CLS Counting Logic:**
+
+```mermaid
+flowchart TD
+    Start[Layout Shift Detected] --> Input{hadRecentInput?<br/>User input within 500ms?}
+
+    Input -->|true| Exclude[❌ Exclude from CLS<br/>Shift within interaction window]
+    Input -->|false| LoadingPhase{During loading<br/>or interaction?}
+
+    LoadingPhase -->|Loading| CountLoad[✅ Count toward CLS<br/>Loading phase shift]
+    LoadingPhase -->|After loading| CountNormal[✅ Count toward CLS<br/>Post-load shift]
+
+    style Exclude fill:#FFE5E5
+    style CountLoad fill:#FFE5F2
+    style CountNormal fill:#FFF3E5
+```
+
 ### Snippet
 
 ```js copy

pages/Interaction/Long-Animation-Frames.mdx

@@ -1,6 +1,12 @@
 # Long Animation Frames (LoAF)
 
-Tracks [Long Animation Frames](https://developer.chrome.com/docs/web-platform/long-animation-frames) to identify JavaScript and rendering work that blocks the main thread. LoAF is the underlying API that powers INP debugging.
+### Overview
+
+Tracks [Long Animation Frames](https://developer.chrome.com/docs/web-platform/long-animation-frames) to identify JavaScript and rendering work that blocks the main thread. LoAF is the underlying API that powers INP debugging and provides detailed attribution for slow interactions.
+
+**Why this matters:**
+
+LoAF is the successor to the Long Tasks API and provides much more detailed information about what's blocking your page. It tells you exactly which scripts ran, how long they took, and whether they caused forced layouts. This is essential for debugging slow interactions and improving INP scores.
 
 **What is a Long Animation Frame?**
 
@@ -25,6 +31,51 @@ A frame is considered "long" when it takes more than 50ms. The API provides deta
 
 > **Tip:** LoAF helps answer "Why was my interaction slow?" by showing exactly which scripts ran and how long each phase took.
 
+**LoAF Timeline Breakdown:**
+
+```mermaid
+flowchart LR
+    Start([Frame Start]) --> JS1[Script 1<br/>Execution]
+    JS1 --> JS2[Script 2<br/>Execution]
+    JS2 --> Render{Rendering Phase}
+    Render --> Style[Style<br/>Calculation]
+    Style --> Layout[Layout]
+    Layout --> Paint[Paint]
+    Paint --> End([Frame Complete])
+
+    Threshold[50ms Threshold] -.-> Render
+
+    style JS1 fill:#FFE5E5
+    style JS2 fill:#FFE5E5
+    style Style fill:#E5F2FF
+    style Layout fill:#E5F2FF
+    style Paint fill:#E5F2FF
+    style Threshold fill:#FFA500
+```
+
+**Comparison: Long Tasks vs LoAF:**
+
+```mermaid
+graph TB
+    subgraph LT[" Long Tasks API ❌ "]
+        LT1["⏱️ Task > 50ms"]
+        LT2["❓ Limited Attribution"]
+        LT3["🚫 No Render Time"]
+    end
+
+    subgraph LA[" Long Animation Frames API ✅ "]
+        LA1["⏱️ Frame > 50ms"]
+        LA2["✅ Full Script Attribution"]
+        LA3["🎨 Includes Render Time"]
+        LA4["🔍 Detects Forced Layouts"]
+    end
+
+    LT -->|Replaced by| LA
+
+    style LT fill:#FFE5E5,stroke:#FF4444,stroke-width:2px
+    style LA fill:#E5FFE5,stroke:#44AA44,stroke-width:2px
+```
+
 ### Snippet
 
 ```js copy

pages/Interaction/LongTask.mdx

@@ -1,6 +1,12 @@
 # Long Tasks
 
-Tracks tasks that block the main thread for more than 50ms. Long tasks prevent the browser from responding to user input, causing poor [Interaction to Next Paint (INP)](https://web.dev/articles/inp).
+### Overview
+
+Tracks tasks that block the main thread for more than 50ms. Long tasks prevent the browser from responding to user input, causing poor [Interaction to Next Paint (INP)](https://web.dev/articles/inp) and sluggish user experience.
+
+**Why this matters:**
+
+When the main thread is blocked by a long task, the browser cannot respond to clicks, taps, or keyboard input. This creates a frustrating experience where the page feels "frozen". Long tasks are the primary cause of poor INP scores and should be broken up into smaller chunks.
 
 > **Recommendation:** For better debugging, consider using [Long Animation Frames (LoAF)](/Interaction/Long-Animation-Frames) which provides full script attribution and render timing.
 
@@ -240,6 +246,37 @@ Blocking time: 150 - 50 = 100ms
 
 Total Blocking Time (TBT) is a key metric for understanding main thread responsiveness.
 
+**Blocking Time Visualization:**
+
+```mermaid
+flowchart LR
+    Start([Task<br/>Start]) --> Normal["✅ First 50ms<br/><small>Non-blocking</small>"]
+    Normal --> Threshold{50ms<br/>Threshold}
+    Threshold --> Block["⚠️ Blocking Time<br/><small>Everything beyond 50ms</small>"]
+    Block --> End([Task<br/>Complete])
+
+    style Normal fill:#E5FFE5,stroke:#44AA44,stroke-width:2px
+    style Threshold fill:#FFF3E5,stroke:#FF8800,stroke-width:2px
+    style Block fill:#FFE5E5,stroke:#FF4444,stroke-width:2px
+```
+
+**Severity Levels:**
+
+```mermaid
+flowchart TB
+    Task[Long Task Duration] --> Check{How long?}
+
+    Check -->|50-100ms| Low["🟢 Low Severity<br/><small>Minor delay</small>"]
+    Check -->|100-150ms| Medium["🟡 Medium Severity<br/><small>Noticeable lag</small>"]
+    Check -->|150-250ms| High["🟠 High Severity<br/><small>Poor responsiveness</small>"]
+    Check -->|> 250ms| Critical["🔴 Critical Severity<br/><small>Severe blocking</small>"]
+
+    style Low fill:#E5FFE5,stroke:#44AA44,stroke-width:2px
+    style Medium fill:#FFFBE5,stroke:#FFBB00,stroke-width:2px
+    style High fill:#FFF3E5,stroke:#FF8800,stroke-width:2px
+    style Critical fill:#FFE5E5,stroke:#FF4444,stroke-width:2px
+```
+
 ### Limitations
 
 The Long Tasks API provides limited information: