Inicio - Documentación - POM Theme - 11 Developers - Performance requirements for POM extensions

Performance requirements for POM extensions

A POM integration should add work only where its output is used. Avoid turning a component-level feature into a site-wide query, asset bundle, or regeneration task.

Query discipline

Use a bounded WP_Query, request only the fields you need, and paginate large result sets. Avoid querying inside card or term loops. Prime or reuse WordPress caches for repeated object, term, and metadata access.

On multisite, scope cache keys to the blog and restore the original blog after switch_to_blog(). Do not build network-wide catalogs during a normal frontend request.

Asset discipline

Request POM conditional assets from the component that needs them. Use pom_require_front_asset_feature(), a documented handle helper, or a specialized enqueue helper such as the Maps or Flickity helper.

Do not enqueue every POM script and stylesheet to avoid discovery work. Do not call pom_generate_custom_assets() during frontend rendering.

Use the complete conditional asset delivery guide to distinguish structural styles from safe preload candidates, declare features that dynamic pages may insert, and preserve cache and no-JavaScript behavior.

Rendering and caching

Keep cache keys sensitive to every value that changes output: site, language, user state where appropriate, content ID, query arguments, template identifier, and relevant data version.

Never cache private or account-specific markup in a public key. Cart, checkout, account, permission-controlled, and personalized form output need their normal dynamic boundaries.

Measure the real path

Compare an uncached and warm request for the exact archive, form, shortcode, or template being extended. Record query count, response time, transferred assets, and browser work before and after the integration.

Release checklist

  • No unbounded queries or repeated queries inside loops.
  • No global asset enqueue for a local feature.
  • No full asset regeneration on ordinary requests.
  • Cache keys include site and output context.
  • Cache invalidation follows the supported content or settings write.
  • Signed-out, signed-in, multilingual, and multisite paths remain correct.