Kort svar: Bekræft først på staging, at layoutet bliver korrekt, når Remove Unused CSS alene deaktiveres. Find derefter den ødelagte komponenttilstand og sammenlign dens nødvendige CSS-selectors med den genererede inline CSS. FlyingPress' safelist bruger selectors, ikke stylesheet-filnavne. Tilføj det mindst mulige selector-mønster, regenerér den berørte URL, og test mobilmenu, hover, fokus, modal, formularfejl og andre skjulte tilstande.
Remove Unused CSS kan reducere renderblokerende CSS ved at udlede de regler, siden bruger, placere den nødvendige CSS inline og udskyde resten. Problemet opstår, når en regel kun bliver relevant efter en handling eller under en tilstand, som optimizerens rendering ikke aktiverer: mobilmenuen åbnes, en valideringsfejl vises, eller en modal får en dynamisk klasse.
Løsningen er ikke automatisk at undtage hele temaets stylesheet. Først skal du bevise, at RUCSS er årsagen, derefter finde den mindste selector, der mangler.
Praktisk grundlag: Trinene er gennemgået den 28. august 2026 mod WordPress 7.1, PHP 8.4.23, FlyingPress 5.6.5 og Chrome 151. Et ødelagt layout skal reproduceres på staging, så den konkrete CSS-undtagelse kan afprøves uden at ramme besøgende. Gem før/efter, genereret CSS, selector, køstatus og testede komponenttilstande som dokumentation for din egen sag.
På denne side
Gem:
Tag en stagingbackup og sørg for, at andre plugins ikke samtidig kombinerer, fjerner eller udskyder CSS. To CSS-optimeringer gør det svært at vide, hvilken generator der har fjernet reglen.
| Signal i samme komponenttilstand | Sandsynlig årsag | Næste sikre kontrol |
|---|---|---|
| Layoutet er korrekt med RUCSS fra og forkert med RUCSS til | RUCSS er en dokumenteret del af årsagen | Regenerér samme staging-URL i begge tilstande og sammenlign den konkrete selector, ikke hele siden |
| DOM-klassen er korrekt, men den nødvendige regel mangler i computed styles | Den dynamiske selector blev ikke bevaret i den genererede CSS | Find reglen i den uoptimerede kilde og søg efter samme stabile selector i flying-press-css |
| Selectoren findes, men er overstreget | Cascade, rækkefølge eller specificitet overskriver den | Identificér den vindende regel og dens kilde; tilføj ikke en bredere safelist som første svar |
Den forventede klasse eller aria-tilstand kommer aldrig på elementet | JavaScript initialiseres ikke eller bliver forsinket | Kontrollér første konsolfejl og eventhandler, og test Delay JavaScript alene på staging |
| Layoutet er korrekt straks efter purge, men bryder igen efter optimering | Du ser kortvarigt den uoptimerede version, før ny CSS er klar | Vent på færdig kø, åbn en ny privat session og verificér den genererede kilde |
| Kun hover, åben, fejl- eller mobiltilstanden mangler styling | Optimeringsrenderingen så ikke den dynamiske tilstand eller breakpointet | Find én stabil komponentselector, der dækker den manglende state, og safelist kun den |
| Indlogget visning virker, mens anonym visning bryder | HTML, cache eller optimeret output er forskelligt mellem sessionerne | Sammenlign View Source og cachetilstand for begge; ret den anonyme variant, som brugerne faktisk får |
På staging deaktiverer du kun Remove Unused CSS, rydder/regenererer den berørte URL og tester samme session, viewport og handling igen.
Aktivér RUCSS igen efter kontrol, så næste trin arbejder på det rigtige scenarie. Lav ikke en fuld site-purge, hvis én test-URL kan isoleres.
Beskriv fejlen konkret:
display, position og baggrund efter klik.”is-open-tilstand mangler højde/ikonrotation.”Test komponenten systematisk:
Det gør det muligt at safeliste én komponentfamilie i stedet for et helt stylesheet.
Antag, at hamburgerknappen ændrer aria-expanded til true, og panelklassen kommer på som forventet. I den uoptimerede stagingvisning giver reglen .site-menu.is-open panelet position, baggrund og synlighed. I den optimerede kilde mangler den stabile selector. Det er en egnet kandidat til en smal safelist.
Hvis aria-expanded derimod aldrig ændres, skal du stoppe CSS-sporet. Her er problemet sandsynligvis eventinitialisering eller JavaScript-rækkefølge. En safelist kan få panelet til at se anderledes ud, men den kan ikke genskabe en manglende klikhandler. Dette lille beslutningspunkt forhindrer mange brede undtagelser.
Efter ændringen tester du både lukket og åben menu lige under og over det mobile breakpoint. Før/efter-beviset skal vise, at den samme selector nu er med, at køen er færdig, og at tastaturfokus samt Escape stadig virker.
Brug DevTools på en korrekt uoptimeret stagingvisning:
En selector kan være dynamisk, fx .menu.is-open, [aria-expanded="true"] + .panel eller en genereret klasse. Safelist en stabil del, som tilhører komponenten. En tilfældig hash-klasse, der ændres ved hver build, er en dårlig langsigtet nøgle.
FlyingPress placerer den anvendte CSS i et inline style-element med id flying-press-css, mens resterende CSS kan være udskudt. Åbn View Source – ikke kun den levende DOM efter JavaScript – og søg efter style-elementet og den manglende selector.
Kontrollér tre muligheder:
Kun den første peger direkte på safelist. Den tredje hører til JavaScript-fejlfinding og kan skyldes Delay JavaScript.
FlyingPress' safelist accepterer CSS-selectors. Et filnavn som menu.css er ikke den dokumenterede inputtype.
Vælg den smalleste stabile selector, der dækker komponentens nødvendige tilstande. Eksempelprincippet er:
.active, som kan matche hele sitet;Tilføj ét mønster, gem og regenerér. Hvis du tilføjer fem på én gang, kan du ikke vide, hvilken der var nødvendig.
En safelistændring kræver, at den genererede CSS bliver behandlet igen. Efter gemning:
flying-press-css i kildekoden;Et midlertidigt korrekt layout umiddelbart efter purge kan være den uoptimerede side. Vent på den færdige optimerede version, ellers godkender du en falsk succes.
Hvis køen ikke bevæger sig, så brug preload-fejlfindingsguiden frem for at gentage purges.
Test mere end det screenshot, der oprindeligt brød:
Kontrollér samtidig CLS. En genoprettet style kan ændre dimensioner og skabe et nyt layoutskift.
Hvis klassen er tilfældig for hver sidevisning, eller JavaScript afhænger af hele stylesheetets tilstedeværelse, skal komponentens ejer undersøges. Mulighederne er:
Ydelse er ikke vigtigere end korrekt funktion. En målbar, mindre gevinst kan være den rigtige løsning, hvis den aggressive indstilling kræver en ubærlig safelist.
Rettelsen er dokumenteret, når:
Mål ikke kun, om skærmbilledet ligner før. Sammenlign også mængden af genereret CSS, LCP-elementets rendering og eventuelle layoutskift. Hvis en meget bred selector gør layoutet korrekt, men trækker en stor komponentfamilie ind på alle sider, skal den indsnævres. En robust løsning kan forklares med én komponent, én manglende state og én stabil selector.
Hvis safelisten ikke hjælper, fjern præcis den nye selector, regenerér URL'en og bekræft starttilstanden. Hvis live er påvirket, er den sikreste midlertidige rollback at deaktivere RUCSS eller den berørte optimering og regenerere cache – ikke at tilføje stadig bredere selectors uden test.
Kontakt komponent-/builderudvikleren med original CSS-regel, state-ændring og en minimal stagingreproduktion. Kontakt FlyingPress-support med version, URL, genereret style-id, selector og køstatus. Hostious WordPress-support kan hjælpe med en afgrænset safelist og fuld eftertest.
flying-press-css i View Source med den manglende eller tilføjede selector.Gem før/efter-HTML, genereret CSS-hash eller uddrag, selector, beregnede styles, køtidspunkt, screenshots og performance trace. Et syntetisk stagingeksempel er ikke CrUX-, Lighthouse- eller produktionsbevis. Del ikke licensnøgle, cookies eller private stier.
Fordi deres CSS først bruges ved interaktion – generatoren ser den aldrig ‘i brug’ og fjerner den. Tilstande som .open, .active og hover er klassikerne, der skal på safelisten.
Minimalt: tilføj de konkrete selectors eller filstier for den ødelagte komponent – ikke hele stylesheets. Regenerér derefter CSS’en og purge, så testen kører mod de nye filer.
Ja – brug ‘load unused CSS on user interaction’ som mellemvej: al CSS indlæses ved første interaktion. Det koster lidt af gevinsten, men fjerner næsten alle layoutbrud.