Performance Considerations

warning

Performance problems are usually cumulative: heavy blocks + unoptimized images + third-party scripts + uncached pages. Test as a full stack, not in isolation.

Performance Considerations Explained

Area	Risk	Mitigation
CSS size	Render-blocking and style recalculation	Keep presets minimal, avoid huge custom CSS
JS size	INP regressions	Avoid unnecessary scripts
Images	LCP and CLS	Compress, set dimensions, use responsive images
Caching	Stale output vs speed	Purge LSCache after layout changes

Why It Matters

• GenerateBlocks is lightweight, but layouts can still get heavy.
• Performance is a product feature; treat it as part of design.
• OLS + LSCache can hide changes until cache is purged.

How It Works

Front-end performance is driven by what the browser downloads (CSS/JS/images) and what it has to render (DOM depth). GenerateBlocks affects both.

flowchart LR
  CSS[CSS] --> R[Render]
  JS[JS] --> R
  IMG[Images] --> R
  DOM[DOM depth] --> R
  R --> UX[User experience]

Practical Walkthrough

Step 1: Audit Build Asset Sizes

audit-generateblocks-build-assets.sh

cd /var/www/html
ls -lh wp-content/plugins/generateblocks/build 2>/dev/null | head -n 80 || true

Step 2: Locate Key Build Files (Source Hints)

locate-key-build-files.sh

cd /var/www/html
ls -lh wp-content/plugins/generateblocks/build/style-index.css 2>/dev/null || true
ls -lh wp-content/plugins/generateblocks/build/frontend.js 2>/dev/null || true

Step 3: Check for Cache Headers (Optional)

check-lscache-headers.sh

URL="$(wp option get siteurl 2>/dev/null)/"
curl -I "$URL" 2>/dev/null | grep -i litespeed || true

Step 4: Find Large Images in Uploads (Optional)

find-large-uploads.sh

cd /var/www/html
du -ah wp-content/uploads 2>/dev/null | sort -hr | head -n 20 || true

Practical Examples

Example 1: Reduce DOM Depth

Rules of thumb:

• Avoid containers inside containers inside containers.
• Use one wrapper per section.
• Prefer CSS grid/flex over extra wrapper blocks.

Example 2: Image Hygiene for Heroes

Checklist:

• Use WebP/AVIF where possible
• Set width/height
• Avoid huge background images

Example 3: Third-Party Script Containment

If a block section requires a third-party script:

• Load it only on pages that need it
• Prefer async/defer
• Document it in a runbook

Example 4: A Simple Page Budget Table

Budget	Target
Total hero image bytes	< 250KB
Third-party scripts	as few as possible
Custom CSS per page	near zero

Best Practices

Practice	Why
Keep blocks reusable and minimal	Less DOM, fewer regressions
Set performance budgets per section	Prevents slow creep
Warm cache before testing	Avoids false negatives
Purge cache after deployments	Ensures you see real output
Test logged-out	Logged-in views can bypass caching
Avoid heavy animations	JS-heavy effects often regress INP

Troubleshooting

Symptom	Cause	Fix
Page feels slow	Large images or JS	Audit hero images and third-party scripts
Layout shifts	Late-loaded fonts/images	Set dimensions and reduce font variants
Changes not visible	Cache	Purge LSCache and re-test
INP regressed	Too much JS	Remove effects, reduce scripts, and simplify block nesting
No cache headers	Cache not configured	Verify LSCache setup and test a public URL logged-out

Hands-On

1. List build asset sizes and note the largest files.
2. Pick one hero section and optimize its image to a smaller size.
3. Re-test the page logged-out with cache warmed.
4. Capture response headers before and after a cache purge and document the difference.

Quick Reference

performance-cheatsheet.sh

cd /var/www/html
ls -lh wp-content/plugins/generateblocks/build 2>/dev/null | head
curl -I "$(wp option get siteurl 2>/dev/null)/" 2>/dev/null | grep -i litespeed || true

What's Next

• Next module: Site Library & Templates
• Next lesson: Site Library Overview