Kennis
Breakdance en Core Web Vitals: wat vertraagt en wat helpt
Een Breakdance-site wordt vooral vertraagd door veel CSS, extern geladen fonts en het menuscript, en dat los je op met gerichte opruiming van ongebruikte CSS en lokale fonts. Hieronder staan de vier knelpunten en wat je ermee doet. Het gemeten voorbeeld hoort bij één kopie van een Breakdance-site en is geen belofte voor jouw site.
In het kort
- Breakdance schrijft een grote global-settings.css plus per post een post-ID.css. In onze test zat er ongeveer 280 KB CSS op de pagina.
- Ongebruikte CSS verwijderen werkte op Breakdance pas goed toen regels met variabelen mochten meetellen.
- Zonder meting geen fontpreload: een gegokte preload kostte op de kritieke route 0,15 tot 0,85 s LCP.
- Het menuscript awesome-menu.js mag je alleen uitstellen na een test van het menu.
- Gemeten: LCP op mobiel van 2,46 s naar 1,54 s, en 1,42 s met uitgestelde Breakdance-scripts.
Waarom is de CSS van Breakdance zo groot?
Breakdance schrijft een global-settings.css met alle globale stijlen en daarnaast per post een post-ID.css en een post-ID-defaults.css in uploads/breakdance/css. Bijna elke regel zet daarbij een CSS-variabele. Daardoor haalde het verwijderen van ongebruikte CSS in onze test eerst maar 50 van ruim 280 KB weg: een regel met een variabele werd als onmisbaar gezien. Sinds versie 0.72.0 telt zo'n regel mee zoals elke andere regel, dus moet de selector op de pagina staan. Een regel die alleen variabelen bevat, zoals een set kleurtokens, blijft altijd staan.
Wat is het risico bij het opschonen van Breakdance-CSS?
Het menu. Een tussenversie eiste dat elke voorouderklasse van een selector in de HTML stond. Daardoor verdween de regel die het mobiele menu opent (.breakdance-menu--enabled .breakdance-menu-list), omdat awesome-menu.js die klasse pas na het laden zet. Die controle is verwijderd en een test houdt de regel nu vast. Gebruik je een ander hulpmiddel dat ongebruikte CSS verwijdert, test dan altijd het mobiele menu.
Hoe gaan fonts goed op een Breakdance-site?
Laad fonts lokaal en met font-display swap, zodat tekst meteen in een reservefont verschijnt. Wat niet werkt is blind preloaden: de gok laadde elke lokale latin-woff2, ook de cursieve, met hoge prioriteit. Dat kostte in onze test 0,3 tot 0,85 s LCP, en alleen het rechtopstaande font nog 0,15 tot 0,5 s. Spark Speed preloadt daarom pas na een echte meting van de fonts. Eerlijk open punt: na het opwarmen bleven drie van vijf pagina's meerdere cronrondes bij fonts.googleapis.com.
Mag je het Breakdance-menuscript uitstellen?
Het kan, maar niet blind. Op sparkcore.io werkte uitstellen veilig: menu, submenu en toestemmingsbanner reageerden na één tik. Toch staat het standaard uit. Spark Speed laat de optimizer het per site testen in een canary-controle, en zet het pas daarna aan. Heb je geen zo'n controle, test dan zelf op telefoon en desktop: het hamburgermenu, submenu's en de cookiebanner.
Wat leverde het op in de meting?
We maten een Docker-kopie van sparkcore.io met Lighthouse 12.6.1 op mobiel: 5 pagina's, 5 runs per pagina, mediaan, met warme cache en lokale fonts. Versie 0.71.3 haalde gemiddeld 2,46 s LCP (score 97,0). Versie 0.72.0 haalde 1,54 s (score 99,8), en met uitgestelde Breakdance-scripts via de optimizer 1,42 s (score 99,6). Het is één site in één lab, dus lees het als richting en meet zelf.
Meet voor en na elke wijziging met dezelfde pagina's en meerdere runs, en kijk naar de mediaan, niet naar één uitschieter.
Spark Speed ruimt ongebruikte CSS op zonder het mobiele menu te slopen en test risicovolle opties per site.
Veelgestelde vragen
Google noemt een LCP tot 2,5 s goed. Dat is niet specifiek voor Breakdance. Ons gemeten voorbeeld kwam op 1,54 s.
Dat kan niet echt: Breakdance genereert het. Je haalt wat op de pagina niet gebruikt wordt weg met een tool voor ongebruikte CSS en test daarna het menu.
Niet automatisch. Het is één site, vijf pagina's en één lab. Meet jouw eigen pagina's.