Frontend Full-Chain Performance Optimization Guide

Metric Threshold Quick Reference

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)

setTimeout(fn, 0)

Promise.resolve().then(fn)

requestAnimationFrame(fn)

requestIdleCallback(fn)

scheduler.postTask(fn, {priority})

user-blocking

user-visible

background

• 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

• 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)

TTFB ≈ HTTP request time + Server processing time + HTTP response time

<link rel="dns-prefetch">

<link rel="preconnect">

FCP Optimization (White Screen & First Content)

FCP ≈ TTFB + Resource download time + DOM parse time + Render time

defer

async

next/script

Cache-Control: max-age=31536000

Font Optimization Strategies

unicode-range

local()

src: local('Font Name'), url(...)

font-display

swap

optional

block

fallback

auto

new FontFace()

font.load()

document.fonts.ready.then()

navigator.connection

LCP Optimization (Largest Contentful Paint)

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

• 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

<link rel="preload" href="..." as="image">

next/image

priority={true}

<link rel="preload">

next/image

priority

<link rel="preload">

CLS Optimization (Layout Shift)

Layout shift score = Impact fraction × Distance fraction

CLS = SUM(all shift scores)

width

height

<img>

aspect-ratio

srcset

<picture>

transform

top/left/width/height

transform: scale()

font-display: optional

font-display: swap

General Optimization Tips

navigator.connection.effectiveType

Practical Examples with External Services

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

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)

# 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

// 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

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

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

Standalone Usage Mode

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