Frontend Fullchain Optimization

Frontend Full-Chain Performance Optimization Guide

A frontend performance diagnostic and optimization system based on Web Vitals core metrics. Core principle: User-centric — optimization is about doing less, not more.

Metric Threshold Quick Reference

Measurement advice: Don't rely on a single P75. Combine P60/P75/P90/P99 percentiles with daily avg/max/min trend lines. Desktop: target P98+; Mobile core pages: target P95–P99.

Diagnostic Decision Tree

Page loads slowly?
├── TTFB > 800ms → Network/server issue → See "TTFB Optimization"
├── FCP > 1.8s → Resource blocking/large files → See "FCP Optimization"
├── LCP > 2.5s
│   ├── TTFB & FCP normal → Slow viewport resource loading → See "LCP Optimization"
│   └── TTFB or FCP abnormal → Fix upstream metrics first
├── INP > 200ms → Long tasks blocking main thread → See "INP Optimization"
├── CLS > 0.1 → Layout shifts → See "CLS Optimization"
└── Lighthouse Performance Score
    ├── > 80: Few issues
    ├── 60-80: Needs focused analysis, priority: FCP → LCP → CLS
    └── < 60: Severe issues, full audit required

INP Optimization (Interaction Responsiveness)

Diagnosis: Chrome Performance panel — look for long tasks (> 50ms, highlighted red); inspect event handler duration in the flame chart.

Strategy — Break long tasks into shorter ones:

postTask priorities: user-blocking (high) > user-visible (medium) > background (low)

Layout & Rendering Optimization:

• Reduce calc() usage frequency; avoid unnecessary pseudo-class selectors (nth-child, nth-last-child, not())
• Avoid frequent JS modifications to element position/size; use className or cssText for batch updates
• Avoid alternating DOM read/write in loops (layout thrashing): cache reads into variables first, then batch write
• Use skeleton screens for lazy-loaded content
• Use <></> (Fragment) instead of meaningless <div> wrappers
• DOM nodes > 800: caution; > 1400: excessive
• Use virtualization for long lists (react-window / vue-virtual-scroll-list)
• Swiper lists: preload only current item ± 1

CSS Optimization:

• Avoid table layout; reduce deeply nested CSS selectors
• Use GPU-accelerated animations: transform/opacity trigger compositing layer; avoid top/left which trigger reflow
• Use semantic HTML elements; avoid meaningless tags (e.g., use <button> not <div> for buttons)

TTFB Optimization (Network & Server)

Diagnostic formula: TTFB ≈ HTTP request time + Server processing time + HTTP response time

Diagnosis: DevTools Network panel → click request → Timing → "Waiting for server response" = TTFB.

TTFB differences by page type: Static pages (CDN direct, fastest) < SPA (tiny HTML shell, near-static) < SSR (Node.js computation required, slowest). Adjust baseline by page type.

FCP Optimization (White Screen & First Content)

Diagnostic formula: FCP ≈ TTFB + Resource download time + DOM parse time + Render time

White screen time ≈ FCP time. Target: instant open (< 1s).

Font Optimization Strategies

LCP Optimization (Largest Contentful Paint)

Diagnosis: Performance panel — find the LCP marker element; Lighthouse report "Largest Contentful Paint element" entry.

4 element types LCP can mark:

1. <img> elements (most common) and <image> within SVG
2. <video> poster attribute image or first frame
3. Elements with CSS url() background images
4. Block-level elements containing text nodes

Key insights:

• LCP time is always ≥ FCP time
• If TTFB and FCP are normal but LCP is abnormal → problem is viewport resource loading
• SPA: FCP matters more than LCP; SSR/MPA: LCP matters more than FCP

Sampling advice: PV < 1M → full LCP collection; above that → ratio sampling or threshold-based reporting.

CLS Optimization (Layout Shift)

Diagnostic formula: Layout shift score = Impact fraction × Distance fraction, CLS = SUM(all shift scores)

Key conclusion: The farther the element shifts + the more viewport area affected → higher CLS.

General Optimization Tips

Practical Examples with External Services

The following examples demonstrate how to implement strategies with CDN, OSS, Redis, and other external services.

Example 1: Alibaba Cloud OSS — Adaptive Image Quality by Network

Use case: Prioritize visible content for slow-network users; reduce image size and download time.

const BASE_IMAGE_URL =
  "https://oss-console-img-demo-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/example.jpg";

function getNetworkLevel() {
  const connection = navigator.connection || {};
  const type = connection.effectiveType || "4g";
  // Slow network: slow-2g / 2g / 3g
  if (/slow-2g|2g|3g/.test(type)) return "slow";
  return "fast";
}

function buildOssImageUrl(baseUrl) {
  const level = getNetworkLevel();
  // OSS image processing params: lower resolution + quality for slow networks
  const ossParams =
    level === "slow"
      ? "x-oss-process=image/resize,w_100/quality,q_60/format,webp"
      : "x-oss-process=image/resize,w_300/quality,q_82/format,webp";

  return `${baseUrl}?${ossParams}`;
}

function updateHeroImage(imgEl) {
  imgEl.src = buildOssImageUrl(BASE_IMAGE_URL);
}

const heroImage = document.querySelector("#hero-image");
if (heroImage) {
  updateHeroImage(heroImage);
  // Update resource strategy on network change
  navigator.connection?.addEventListener("change", () => updateHeroImage(heroImage));
}

Example 2: CDN Proactive Purge (Post-Deploy)

Use case: Prevent CDN serving stale resources after SPA deployment, avoiding version inconsistencies.

# Executed by CI/CD or server-side — never expose keys in frontend
# Example: proactively purge entry HTML and critical static assets after deploy
curl -X POST "https://your-cdn-provider.example.com/purge" \
  -H "Authorization: Bearer $CDN_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "urls": [
      "https://example.com/index.html",
      "https://example.com/assets/app.abc123.js",
      "https://example.com/assets/app.abc123.css"
    ]
  }'

Example 3: SSR + Redis Cache to Reduce TTFB

Use case: SSR pages reading low-frequency config or first-screen data; reduce DB/remote API latency per request.

// Node.js (SSR) example
import Redis from "ioredis";

const redis = new Redis(process.env.REDIS_URL);

export async function getHomepageData() {
  const cacheKey = "homepage:data:v1";
  const cached = await redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  // Assume this is a slow API or DB query
  const data = await fetch("https://api.example.com/homepage").then((r) => r.json());

  // Cache for 60s to reduce backend pressure under high concurrency
  await redis.set(cacheKey, JSON.stringify(data), "EX", 60);
  return data;
}

Tool Usage Recommendations

Key Analysis Paths:

1. FCP appears late → Check JS/CSS load time; for SSR check server API latency
2. Long gap between FP and FCP → Check long tasks blocking rendering
3. Large gap between FCP and LCP → Too many or too large viewport resources; SSR underutilized
4. CLS spikes multiple times → Total > 0.25 needs priority fix

Manual Measurement Requirement

• By default, treat Lighthouse and Performance evidence as manually collected data
• Prefer measuring the same page/route 2–3 times and using the median result
• Record device type, browser version, network condition, and whether the page is SPA / SSR / SSG
• If possible, keep the measurement environment stable between before/after comparisons

Recommended manual collection flow

1. Open Chrome DevTools
2. Run Lighthouse manually for the target page or route
3. Record the key metrics: LCP / FCP / INP / CLS / TTFB
4. Open the Performance panel and manually record a trace for the same scenario
5. Use the Network panel to confirm TTFB, request waterfalls, and heavy resources
6. Keep screenshots or exported traces as evidence for before/after comparison

If Manual Measurement Is Missing

If the user has no manual Lighthouse or Performance measurements yet, do not claim a root cause with certainty.

Instead:

1. Explicitly state that the diagnosis is inferred without manual measurement
2. Give hypothesis-based suggestions according to visible symptoms, code structure, and page type
3. Label each suggestion with the metric it is most likely to improve
4. Recommend manually measuring Lighthouse and Performance after the change

Suggested fallback advice without manual data

• If the page visibly shows a long white screen → prioritize FCP suggestions
• If the hero image or first screen content appears late → prioritize LCP suggestions
• If clicking or typing feels delayed → prioritize INP / TBT suggestions
• If the page jumps during load → prioritize CLS suggestions
• If the whole page starts slowly before any content appears → prioritize TTFB suggestions

These recommendations are best-effort hypotheses, not verified conclusions.

Standalone Usage Mode

This Skill contains executable judgment criteria, optimization strategies, code examples, and external service implementation patterns. It can be used independently without requiring access to any course documents.

Standard Execution Flow

1. Collect current state
   • Get core metrics: LCP/FCP/INP/CLS/TTFB (at least P75 and daily average)
   • Gather evidence from manual Lighthouse + Performance + Network measurements
2. Determine priority
   • Fix worst metrics (Poor) first, then Needs Improvement
   • Suggested order: FCP → LCP → CLS → INP → TTFB (adjust per business needs)
3. Match strategy
   • Follow this Skill's diagnostic decision tree to select the corresponding optimization branch
   • For external services, prefer the "Practical Examples" section above
4. Implement & verify
   • Small incremental commits; one type of optimization per change
   • If possible, re-test 2–3 times using median values to confirm real improvement
5. Document & prevent regression
   • Record metrics before and after changes
   • Consider adding key checks to CI (Lighthouse / performance budgets)

Delivery Template

## Optimization Target
- Page/Feature:
- Target Metric:
- Current Value:
- Target Value:

## Evidence
- Manual Lighthouse evidence:
- Manual Performance evidence:
- Network evidence:

## Execution Strategy
- Approach:
- External services involved:
- Risk & rollback:

## Result Verification
- Before:
- After:
- Conclusion:

Usage Constraints

• Don't sacrifice core functionality correctness for perceived speed
• Don't treat a single user's anomaly as a global performance issue
• Don't claim optimization success without verification
• If manual Lighthouse / Performance measurement is missing, clearly mark the advice as inferred and recommend follow-up validation