pseo-performance（伪绩效）

pSEO Performance Optimization

Optimize the application for fast builds, excellent Core Web Vitals, and reliable performance at 1000+ page scale.

Core Principles

1. Static first: Pre-render as many pages as possible at build time
2. Incremental where needed: Use ISR for pages that change frequently
3. Minimal JavaScript: Pages should be functional with minimal client-side JS
4. Image optimization: All images processed, sized, and lazy-loaded
5. Cache aggressively: Cache data fetches, API calls, and rendered output

Optimization Areas

1. Static Generation Strategy

Choose the right rendering strategy for scale:

Next.js App Router:

// Generate most important pages at build time
export async function generateStaticParams() {
  const topPages = await getTopPages(500);
  return topPages.map((p) => ({ slug: p.slug }));
}

// ISR for the rest
export const revalidate = 86400; // 24 hours

Fallback handling:

• Always configure a proper fallback (loading state, not blocking)
• Return notFound() for genuinely invalid slugs
• Set dynamicParams = true to allow ISR for pages not in generateStaticParams

2. Build Performance

For builds with many pages:

• Parallelize data fetching: Fetch all data once at the start, not per page
• Memoize data access: Use React.cache() or module-level caching to avoid redundant reads
• Limit build concurrency: If the build server has limited memory, configure worker limits
• Incremental builds: Use ISR to avoid rebuilding all pages on every deploy
• Monitor build time: Track build duration and set alerts for regressions

// Memoize INDEX-TIER data at module level (lightweight: slug, title, category)
// NEVER cache full page content this way — see section 7 Memory Management
import { cache } from "react";

export const getAllIndexData = cache(async () => {
  // Returns PageIndex[] (~1KB per page) — safe to hold in memory
  return fetchAllIndexDataFromSource();
});

3. Core Web Vitals

Largest Contentful Paint (LCP) < 2.5s:

• Use next/image or equivalent for all images (automatic sizing, WebP, lazy loading)
• Preload the LCP image with priority prop or <link rel="preload">
• Minimize render-blocking CSS; inline critical CSS
• Serve from a CDN with edge caching

Cumulative Layout Shift (CLS) < 0.1:

• Set explicit width and height on all images and embeds
• Reserve space for dynamic content with CSS (min-height, aspect-ratio)
• Never inject content above the fold after initial render
• Use font-display: swap with size-adjusted fallback fonts

Interaction to Next Paint (INP) < 200ms:

• Minimize client-side JavaScript
• Defer non-critical scripts
• Avoid long tasks in event handlers
• Use React.lazy() for below-fold interactive components

4. Bundle Optimization

• Analyze the bundle: Run the framework's bundle analyzer
• Tree-shake unused code: Ensure imports are specific, not barrel imports
• Code split by route: Each page route should have its own chunk
• Externalize large dependencies: Move heavy libraries to CDN or dynamic imports
• Remove unused dependencies: Audit package.json for dead dependencies

# Next.js bundle analysis
ANALYZE=true next build

5. Caching Strategy

Build-time caching:

• Cache data source responses during build
• Use file-system or in-memory caching for computed values
• Cache static assets with immutable headers

Runtime caching:

• Set Cache-Control headers for static pages (e.g., s-maxage=86400, stale-while-revalidate)
• Use ISR revalidation to keep cached pages fresh
• Cache API responses with appropriate TTLs

CDN caching:

• Deploy behind a CDN (Vercel, Cloudflare, etc.)
• Configure cache keys to avoid unnecessary invalidation
• Use stale-while-revalidate for non-critical freshness

6. Image Optimization

• Use the framework's image component (next/image, etc.)
• Serve images in WebP/AVIF format
• Implement responsive srcSet for different viewports
• Lazy load below-fold images
• Set explicit dimensions to prevent layout shift
• Use a CDN image optimizer for dynamic images

7. Memory Management at Scale

Node.js default heap is ~1.5GB. At 1000+ pages with rich content, builds will OOM without explicit memory management.

Increase Node.js heap when needed:

# In build script or CI
NODE_OPTIONS="--max-old-space-size=4096" next build

Limit build worker concurrency:

// next.config.js
module.exports = {
  experimental: {
    workerThreads: true,
    cpus: 2, // limit parallel workers to reduce total memory
  },
};

Split data loading into light and heavy tiers:

• Index data (slug, title, category, lastModified) — safe to hold all in memory. ~1KB per page = ~1MB for 1000 pages.
• Full page data (body content, FAQs, images) — load per-page, never cache the full set. ~50-500KB per page = 50MB-500MB for 1000 pages. This will OOM at scale if cached.

// GOOD: Load full data per page
export async function getPageData(slug: string) {
  return fetchSinglePage(slug); // loads ~100KB, GC'd after render
}

// BAD: Cache all full data in memory
const ALL_DATA = await fetchAllPages(); // 500MB+ in memory for entire build

Image processing concurrency:

• Process images in batches, not all at once
• Use sharp's built-in concurrency limiter: sharp.concurrency(1)
• If using next/image with remote images, limit simultaneous optimizations

ISR cache eviction:

• Next.js ISR caches rendered pages in memory (or disk). At 10,000+ pages, configure: // next.config.js module.exports = {experimental: {isrMemoryCacheSize: 0, // rely on disk cache only},};

- Disk-based cache (default in recent Next.js versions) - Set isrMemoryCacheSize: 0 to disable in-memory ISR cache entirely if memory-constrained

Sitemap generation:

• For 50,000+ URLs, stream the sitemap XML to disk rather than building the full array in memory
• Use sitemap index files to split into chunks of 10,000-50,000 URLs each

Monitor memory during builds:

# Track peak memory usage
/usr/bin/time -v next build  # Linux
/usr/bin/time -l next build  # macOS

8. Publication Velocity and Rollout Strategy

Google's 2025 spam detection system (SpamBrain) monitors how fast pages are published. Dumping thousands of programmatic pages at once is a signal of scaled content abuse.

Rollout strategy for new pSEO pages:

Implementation approaches:

• ISR with gradual seeding: Generate pages on-demand via ISR but submit URLs to Google in batches via sitemap updates
• Feature flag by category: Launch one category at a time, monitor impact before launching the next
• Draft/published status: Mark pages as draft in the data layer, publish in batches by flipping status

Monitor between batches:

• Search Console: indexing status, manual actions, coverage issues
• Organic traffic: are existing pages maintaining rankings?
• Crawl stats: is Googlebot crawling the new pages?
• Core Web Vitals: are new pages performing well?

Do NOT:

• Publish 5,000+ pages in a single deploy
• Submit all URLs to Google Search Console at once via URL inspection
• Create all pages and then remove them quickly if they don't rank (signals low-quality churn)

9. Font Optimization

• Self-host fonts (or use next/font)
• Subset fonts to required character sets
• Use font-display: swap or optional
• Preload the primary font file

Performance Checklist

• All pages can be reached within 3s on a 3G connection
• LCP < 2.5s on mobile
• CLS < 0.1
• INP < 200ms
• Build completes in reasonable time at current page count
• Build peak memory stays within server limits (check with /usr/bin/time)
• No full-dataset loading in memory (two-tier data pattern used)
• Bundle size per page < 200KB JS (compressed)
• Images use next-gen formats (WebP/AVIF)
• Cache-Control headers are set for all static assets
• No unused JavaScript in production bundle
• Publication rollout plan exists for 100+ new pages (not all at once)
• Search Console monitoring is configured between deployment batches

Relationship to Other Skills

• Optimizes: pseo-templates (rendering strategy), pseo-data (fetch performance)
• Independent of: pseo-metadata, pseo-schema, pseo-linking (these are typically lightweight)
• Extended by: pseo-scale (CDN/edge architecture, build strategy at 100K, cache warm-up, crawl budget)
• Validated by: Lighthouse, WebPageTest, or framework-specific performance tools