Knowledge
Breakdance and Core Web Vitals: what slows it down and what helps
A Breakdance site is mostly slowed down by a lot of CSS, externally loaded fonts and the menu script, and you solve that with targeted removal of unused CSS and local fonts. Below are the four bottlenecks and what to do about them. The measured example belongs to one copy of a Breakdance site and is not a promise for yours.
In short
- Breakdance writes a large global-settings.css plus a post-ID.css per post. In our test the page carried about 280 KB of CSS.
- Removing unused CSS only worked well on Breakdance once rules that set variables were allowed to count.
- No font preload without a measurement: a guessed preload cost 0.15 to 0.85 s LCP on the critical path.
- You may only delay the menu script awesome-menu.js after testing the menu.
- Measured: mobile LCP from 2.46 s to 1.54 s, and 1.42 s with delayed Breakdance scripts.
Why is the Breakdance CSS so large?
Breakdance writes a global-settings.css with all global styles, and per post a post-ID.css and a post-ID-defaults.css in uploads/breakdance/css. Nearly every rule sets a CSS variable. Because of that, removing unused CSS first only removed 50 of more than 280 KB in our test: a rule with a variable was treated as indispensable. Since version 0.72.0 such a rule counts like any other, so its selector must be on the page. A rule that contains only variables, such as a set of colour tokens, always stays.
What is the risk when pruning Breakdance CSS?
The menu. An intermediate version required every ancestor class of a selector to be in the HTML. That removed the rule that opens the mobile menu (.breakdance-menu--enabled .breakdance-menu-list), because awesome-menu.js only sets that class after loading. That check is gone and a test now pins the rule. If you use another tool that removes unused CSS, always test the mobile menu.
How do you handle fonts well on a Breakdance site?
Load fonts locally and with font-display swap, so text appears straight away in a fallback font. What does not work is blind preloading: the guess loaded every local latin woff2, italic included, with high priority. In our test that cost 0.3 to 0.85 s LCP, and the upright font alone still 0.15 to 0.5 s. Spark Speed therefore only preloads after a real measurement of the fonts. An honest open point: after warming, three of five pages stayed on fonts.googleapis.com for several cron rounds.
May you delay the Breakdance menu script?
It can be done, but not blindly. On sparkcore.io delaying was safe: menu, submenu and consent banner responded after one tap. Still it is off by default. Spark Speed lets the optimizer test it per site in a canary check, and only then turns it on. If you have no such check, test yourself on phone and desktop: the hamburger menu, submenus and the cookie banner.
What did it deliver in the measurement?
We measured a Docker copy of sparkcore.io with Lighthouse 12.6.1 on mobile: 5 pages, 5 runs per page, median, with warm cache and local fonts. Version 0.71.3 averaged 2.46 s LCP (score 97.0). Version 0.72.0 averaged 1.54 s (score 99.8), and with Breakdance scripts delayed through the optimizer 1.42 s (score 99.6). It is one site in one lab, so read it as a direction and measure your own.
Measure before and after every change with the same pages and several runs, and look at the median, not at a single outlier.
Spark Speed prunes unused CSS without breaking the mobile menu and tests risky options per site.
Frequently asked questions
Google calls an LCP up to 2.5 s good. That is not specific to Breakdance. Our measured example came to 1.54 s.
Not really: Breakdance generates it. You remove what the page does not use with an unused CSS tool and then test the menu.
Not automatically. It is one site, five pages and one lab. Measure your own pages.