Docs/Advanced Topics/Performance
Performance
Most of what matters is already handled by WordPress core. This page covers the few places where your own template code determines how many queries actually run.
Option values are already cheap
All option panel fields store as theme_mods, which WordPress core loads once per request as a single autoloaded option (theme_mods_{stylesheet}). Calling tpmeta_get_option() or get_theme_mod() many times across a template doesn't cost extra database queries — the array is already in memory after the first call.
Repeaters and galleries do more work per row
tpmeta_get_repeater_rows() decodes and merges defaults on every call. If you loop over the same repeater more than once on a page, call it once into a local variable and reuse that, rather than calling it again inside a second loop.
// Good: fetch once, reuse.
$team = tpmeta_get_repeater_rows( 'team_members' );
// ...use $team in the hero, then again in a summary block, etc.Image and gallery helpers (tpmeta_image, tpmeta_gallery_field) resolve attachment IDs to URLs, which touches the attachment's post row and metadata per image. For a gallery with many images repeated across several archive cards, resolving once per unique ID (rather than once per card) avoids redundant lookups — standard WordPress attachment-caching guidance applies here, since these helpers ultimately call core media functions.
Output CSS runs once per request
Fields configured with an output rule and a panel with output_css => true print their CSS into <head> automatically — this replaces hand-written template code entirely for those values, so there's nothing to optimize on your side.
Large export/import runs
Export/Import processes up to 500 items per data type per run. For a very large site, run it in batches by data type rather than exporting everything in one pass — see Move Data Between Sites.