If your Vite or Create React App build flashes raw HTML before styles land, the head order is probably wrong—not your component tree. Default bundler output often places <script type=\"module\"> before the main stylesheet. The browser downloads and executes JavaScript immediately. React hydrates. The CSS file is still in flight. Users see an unstyled flash, Lighthouse marks render-blocking resources, and Largest Contentful Paint slips because the hero paints without layout rules.
This is not a mystery bug in React 19. It is predictable parser behavior. Module scripts are high priority. Stylesheets block rendering when linked correctly—but only if they appear before the script that mounts your app. Put JS first and you have styled hydration racing the network. Put CSS first and the first paint matches your design system.
\n\nI enforce that order on briancrabtree.me in postbuild, not by hand-editing dist/index.html after every deploy. The same rule applies to subpath demos like /highline/ when the deploy script emits head tags. Speed is a build contract, not a one-time audit fix.
My PSI gate for the homepage is explicit: preload the main CSS bundle, keep a blocking rel=\"stylesheet\" link, and place both before the module entry script. Never defer main CSS while module JavaScript runs first—that pattern guarantees unstyled React on the critical path.
scripts/postbuild-html.mjs rewrites Vite output after every production build. It strips the default stylesheet and module script tags, then reinserts them in the right sequence immediately after the inline prerender <style> block: rel=\"preload\" as=\"style\" for early discovery, blocking stylesheet link, then type=\"module\". One pass, every route shell, no drift between deploys.
That is the difference between “we should fix PageSpeed someday” and a reproducible 98+ mobile score on a React marketing site. The audits stop complaining about chaos you introduced in the head, and LCP stops waiting on hydration to discover dimensions that CSS already defined.
\n\n- [ ] blocking stylesheet link appears before type=module script in built index.html\n- [ ] preload as=style for main CSS bundle\n- [ ] inline prerender style covers LCP hero dimensions\n- [ ] font preloads do not outrank LCP image fetch\n- [ ] PSI mobile run saved on production URL before claiming a scoreHead order alone is not enough if the hero depends entirely on a hashed CSS file. I inline a route-specific critical style block in the prerender shell—hero dimensions, background, typography scale—so the first paint is intentional even while the full bundle downloads. Crawlers and lab tools see real content, not a blank root div waiting on JavaScript.
\n\nThat pattern is the same idea behind static prerender shells for SPAs: HTML carries enough structure to score and index before the client app boots. Postbuild merges per-route meta, canonical tags, and the inline shell into dist/ copies for /about/, /journal/, and every journal slug. The React app still hydrates; the shell just refuses to look broken during the gap.
After CSS order is correct, the next silent killer is competing preloads. Dropping rel=\"preload\" on every woff2 file feels responsible until your hero image loses the bandwidth race. On image-led marketing pages, the LCP candidate should win fetch priority—not display fonts for below-fold copy.
I preload only what the above-fold shell needs, and I audit when scores move between runs. Lab variance is normal; chasing a single integer without reading the waterfall is how teams add preloads that hurt more than they help. For the full picture on run-to-run jitter, see why PageSpeed scores change every run.
\n\nLighthouse will still list render-blocking CSS—that is correct. Stylesheets should block if you want styled first paint. The failure mode is blocking in the wrong order relative to JavaScript, or blocking on CSS that arrives too late because JS already mutated the DOM. Fixing head order does not mean async-loading your entire design system and accepting FOUC. It means blocking on the right file at the right time.
\n\nOn a recent luxury real estate handoff I documented in mock-first handoffs before MLS integration, the demo hit 98 mobile PageSpeed with self-hosted WebP heroes and no third-party search scripts on the critical path. Head order and prerender shell were part of that budget—not a post-launch surprise. I save the PSI analysis URL before claiming any number in a proposal.
\n\nRun PageSpeed Insights on the deployed URL with mobile and desktop profiles. Open the built index.html in dist/ and confirm the stylesheet link precedes the module script. Scroll on a phone. If the hero flashes unstyled, the head rewrite did not run or a deploy path skipped postbuild.
For a broader pass before handoff, start with Website Performance Audit Checklist (2026), then performance checks before handoff and website performance audit checklist. CSS-before-JS is one line item—but it is the one that separates fast React sites from fast-looking demos that fail on real networks.
\n\nIf your React site loads unstyled on first paint, or mobile PageSpeed stalls despite a small bundle, send a brief at /contact with your production URL and build tool (Vite, CRA, Next static export). I will tell you whether head reorder and prerender shell are enough—or whether the problem is asset weight, third-party scripts, or something else entirely. See services for how I scope performance work.
","tags":["react","vite","pagespeed","core-web-vitals","performance"],"views":30}