agentleFS
Sign inStart free
SnoozleStudioSnoozleStudio/opencode-wp-settings/skills/wp-performance/SKILL.md

wp-performance

Skill4 starsChanged 3 days agoMITView on GitHub

Optimize and audit WordPress plugin/theme performance — server-side (enqueue discipline, options autoload, transients, query caching) and front-end (bundle splitting, dynamic imports, rAF budget, animation cost). Use when improving page speed, web vitals, or when writing any code that runs on every request.

6 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Enqueue discipline: only enqueue what the current page needs (conditional tags: is_front_page(), is_singular(), is_page_template()).

    line 13
  2. Very specific:

    Queries: use pre_get_posts instead of duplicate WP_Query.

    line 19
  3. Distinctive:

    Manifest-driven assets: read Vite manifest once per request (static cache), preload fonts, defer module scripts

    line 22
  4. Distinctive:

    No heavy autoload of plugin classes on the front end — load only what the request needs

    line 24
  5. Very specific:

    rAF budget: all animation through Tempus (single loop).

    line 31

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Performance — WordPress + Front-End

Load docs/performance.md for the full reference. Two halves: what runs on the server every request, and what runs in the browser every frame.

Server-side (PHP)

  • Enqueue discipline: only enqueue what the current page needs (conditional tags: is_front_page(), is_singular(), is_page_template()); never load admin assets on the front end or vice versa; wp_enqueue_* only — no hardcoded <link>/<script>
  • Options: autoload: false for anything large or rarely used (autoloaded options load on EVERY request); Transients for cached computed data (not options); never update_option per request
  • Queries: use pre_get_posts instead of duplicate WP_Query; no_found_rows, 'fields' => 'ids' where applicable; always wp_reset_postdata(); prefer get_posts/API functions (cached) over raw $wpdb
  • Manifest-driven assets: read Vite manifest once per request (static cache), preload fonts, defer module scripts
  • No heavy autoload of plugin classes on the front end — load only what the request needs

Front-end (browser)

  • Bundle discipline: entry JS imports CSS + core; Three.js / QR / heavy libs behind dynamic import() chunks; vendor code-split ≤ ~300KB chunks; chunkSizeWarningLimit tuned in vite config
  • rAF budget: all animation through Tempus (single loop); gate expensive work on state.budget; pause loops when elements leave viewport (IntersectionObserver); skip frames on low-core machines (navigator.hardwareConcurrency)
  • Animation cost: animate only transform/opacity; no layout thrash; no will-change: transform on ancestors of position: fixed; avoid forcing repaints (filter/blur on large layers)
  • Scroll: Lenis on native scroll (no transform-based virtual scroll) — cheap and sticky-safe; data-lenis-prevent for nested scrollables instead of allowNestedScroll
  • Fonts: woff2 with font-display: swap + unicode-range subsets; preload critical font files
  • Async CSS: critical CSS inline/preloaded, rest loaded async with noscript fallback
  • Media: lazy loading images/video; proper srcset/sizes

Audit procedure

  1. Server: trace one request path — what's enqueued, which options autoload, query count (Query Monitor in dev or save_queries)
  2. Front-end: bundle report (vite build --report or analyze dist), dynamic chunks, animation loops
  3. Report: measured findings only (never fabricate Lighthouse/bundle numbers); flag what needs browser profiling

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free