菜单
Use when diagnosing or fixing Bricks site performance: "why is my site slow?", "CSS is huge", "first-load is bad", "LCP is 4 seconds". Covers the `cssLoading` file-vs-inline setting, the loop-marker preservation trap, random-seed TTL, query cache, and the real-world fixes that move numbers.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when writing custom-element controls or debugging control behavior: "what control type for a color?", "conditional control visibility", "dynamic data on a custom control". Covers the ~40 control types, the `required` syntax, CSS-binding via `css` key, dynamic-data support, and default-value gotchas.
Use before writing or editing Bricks element JSON, settings, controls, globals, page settings, or template settings. Gives the runtime lookup order plus bundled full resolved schemas so you can check exact control keys and value shapes instead of guessing.
Use after every write through the Bricks MCP: set-page-elements, update-element, update-element-conditions, update-element-interactions, batch-update-elements, set-template-conditions, set-global-variables, create-theme-style, etc. Defines the verify-after-write loop: read back the change, render the affected post, check for silent failures (empty render, unknown tags, unbalanced braces, query:null). Catches the "tool returned success but the page broke" class of bugs.
Use when the Bricks skills update check reports BRICKS_SKILLS_UPDATE_AVAILABLE, or when the user asks to update the Bricks skills pack.
Use at the start of every Bricks session. Orientation rules: call get-design-context before any design-system write, verify mutations with get-page-elements / list-revisions, and never force same-named globals to duplicate.
Use when creating or updating design tokens: global classes, variables, color palettes, theme styles, components. Enforces uniqueness, scale-generator usage, and conditions on theme styles. Prevents system fragmentation.
| name | bricks-performance |
| description | Use when diagnosing or fixing Bricks site performance: "why is my site slow?", "CSS is huge", "first-load is bad", "LCP is 4 seconds". Covers the `cssLoading` file-vs-inline setting, the loop-marker preservation trap, random-seed TTL, query cache, and the real-world fixes that move numbers. |
Requires: Bricks 2.4+ with the Abilities API enabled
Run first when filesystem tools are available:
_BS_UPDATE_CHECK=""
for _CAND in "$HOME/.bricks/skills/bricks-skills/scripts/bricks-skills-update-check" "$PWD/scripts/bricks-skills-update-check" "$HOME/.claude/skills/bricks-skills/scripts/bricks-skills-update-check" "$HOME/.codex/skills/bricks-skills/scripts/bricks-skills-update-check"; do
[ -f "$_CAND" ] && _BS_UPDATE_CHECK="$_CAND" && break
done
[ -n "$_BS_UPDATE_CHECK" ] && sh "$_BS_UPDATE_CHECK" || true
If it prints BRICKS_SKILLS_UPDATE_AVAILABLE <old> <new> <tag>, load bricks-skills-update before continuing. If it prints BRICKS_SKILLS_JUST_UPDATED <old> <new>, mention the new version and continue.
Bricks is reasonably fast out of the box. When sites get slow, it's almost always one of a handful of causes: CSS loading mode, stripped Bricks loop markers breaking AJAX, missing query cache, image-handling defaults, or too many interactions. Use this diagnostic order for real-world performance issues.
Setting: Bricks > Settings > Performance > CSS loading method. Stored as cssLoading in the Bricks settings registry (includes/abilities/settings.php) and used by the asset loader (includes/assets.php).
| Mode | Value | Tradeoff |
|---|---|---|
| Inline (default) | '' (empty string) | One less HTTP request. CSS ships in <style> blocks inside <head>. Repeated across all pages: not cached by browser. |
| External file | 'file' | Separate .css files per template / global style. Browser-cacheable. Tiny HTTP request but cold-load pays for it. |
Which to pick:
inline. Zero round-trips matters more than byte duplication.file. Cache wins by page 2.file. Cart pages differ from product pages; browser cache across pages is a big win.File-mode regeneration: files are written to wp-content/uploads/bricks/css/ at save time. After a bulk update (site-wide CSS change, theme-style swap, class rename), regenerate all via Bricks > Settings > Performance > Regenerate CSS files. Without this, stale CSS serves until each template is manually saved.
Filter: bricks/generate_css_file: intercept per-file generation.
Bricks query loops rely on loop markers for AJAX pagination, Load More, Infinite Scroll, and Query Filters.
Current source flow: server render adds data-brx-loop-start, then frontend JS converts it to a comment shaped like <!--brx-loop-start-{queryId}-->.
Optimization plugins and cache layers that remove Bricks markers can break AJAX swaps. Configure them to preserve Bricks brx-loop markers.
Diagnostic: inspect both page source and the live DOM on a page with a loop. Page source should contain data-brx-loop-start; the live DOM should contain a brx-loop-start comment. If either disappears after optimization, fix the plugin config and flush cache.
Query loops with orderby: rand need a stable seed across paginated pages, or the same item shows on page 1 and page 3.
Setting: random seed TTL (in minutes). Stored as randomSeedTtl in query vars. Default: 60 min (query.php:2566-2567).
Storage: Bricks sets a transient keyed by bricks_query_loop_random_seed_{element_id} (includes/query.php:2584). The seed is shared by queries for the same element until the transient expires. Bricks also deletes it when the random-seed setting changes.
Setting: Bricks > Settings > Performance > Cache query loops (checkbox cacheQueryLoops at admin/admin-screen-settings.php:1962).
Uses WordPress object cache through wp_cache_get() / wp_cache_set() (includes/query.php). A persistent object cache such as Redis or Memcached makes it useful across requests. Without one, the cache is request-local and the benefit is much smaller.
Caches query results for one minute, keyed by element id, query vars, parent loop object id, and any language-specific cache-key filters. Huge win on:
Invalidation: current source uses a short object-cache TTL (MINUTE_IN_SECONDS) rather than a broad explicit invalidation graph for every content change. If a persistent object cache serves stale loop results, clear the object cache or adjust the query cache key through bricks/query/cache_key for the context you need.
Bricks enqueues Google Fonts automatically when a theme style references them. This is an external request per font file, blocking first paint.
Fixes:
.woff2 into the Bricks custom-fonts panel; reference the custom font in theme styles.bricks/assets/load_webfonts to false + enqueue your own self-hosted fonts via child theme.<head> with <link rel="preload" as="font" crossorigin>.Bricks doesn't lazy-load by default: WP does, since 5.5. Verify loading="lazy" is present on images below the fold.
For LCP:
loading="lazy". Add priority or use <link rel="preload">.srcset on rendered HTML.bricks-interactions skill)Each interaction:
data-interactions.100-card grid x 5 interactions = 500 listeners + 500 JSON payloads in HTML. Big pages inflate fast.
Fixes in order:
frontend.jsThe Bricks frontend source is src/assets/js/frontend.js; the compiled runtime is enqueued as bricks-scripts from assets/js/bricks.min.js (includes/setup.php:445-446). It handles core frontend behavior such as interactions, popups, sliders, accordions, and filter helpers, and it is loaded as the main Bricks frontend script.
Optimization:
defer. If you see it as blocking, a plugin is overriding. Fix the plugin.?ver=X.Y.Z parameter means CDNs cache per-version. No invalidation needed on update.Bricks creates a revision of the _bricks_page_content_2 meta on every save. On a busy site, this blob can double every week.
Fixes:
wp_revisions_to_keep in wp-config.php: limit to 10-30 per post.WP Admin > Tools > Optimize > Old revisions (with a plugin like WP-Optimize).revisions.php + MCP list-revisions / prune-revisions abilities if present).Before optimizing, measure:
wp-content/debug.log with WP_DEBUG_LOG=true: error_log()s from Bricks catches.bricks_assets transient in DB: Bricks' asset cache state.Then optimize the biggest lever. Don't micro-optimize per pixel.
Site is slow: walk this in order, fix what's broken:
file for 3+ page journeys.<head>? Defer them.If after this you're still slow, the bottleneck is app-specific: profile with DevTools Performance.
brx-loop markers.wp-admin, preview URLs. Stale cart = lost sale.custom-code: CSS cascade order, where custom CSS lives.interactions: interaction cost details.query-loops: loop-specific performance (include/exclude, include-query).site-audit: full-site scan includes performance signals.