We found 4 things wrong with our own website and fixed all of them.
A tracking script loading too early, a spinner collapsing the page, a cookie banner appearing after load, and a nav that shifted for logged-in visitors. All found with Google's own tools. All fixed in 7.3 hours.
What was wrong, what was fixed
What was wrong
Google Analytics was loading before the page painted
What was fixed
Moved GA to load after paint, only for users who accepted tracking
PSI's bootup-time audit showed the GA script consuming 226ms of main thread time on every page load. The standard install puts it in the page head -- correct for tracking, wrong for performance. GA now fires via idle callback after the page is visible. Pages that declined tracking never fetch it at all.
What was wrong
A loading spinner was collapsing the page height during load
What was fixed
Removed the spinner from the main content area on 7 pages
The homepage and six other pages used a loading spinner while below-fold content loaded. While it showed, the page shrank to half height -- and the footer jumped into the visible area. When the real content loaded, the footer jumped back. That jump registered as a layout shift score of 0.428 on 11 pages. Removing the spinner removed the collapse.
What was wrong
The cookie consent banner appeared after the page loaded
What was fixed
Banner is now present from the start, slides in via CSS transform
The banner was rendered as nothing on first load, then inserted into the DOM after React finished. Every anonymous visitor -- including Google's testing tool, which always runs as a first-time visitor -- triggered this shift on every scan. CSS transform animations are not counted as layout shifts by the browser. The banner now slides in visually without moving anything else.
What was wrong
The nav shifted when logged-in visitors arrived
What was fixed
Auth-only nav items moved to the end of the nav bar
History and Pipeline links were inserted mid-nav when login state resolved after hydration. Every item to their right shifted. Moving them to the end of the nav means stable items always occupy the same positions -- auth items only ever append.
Before and after
Before
After
How we found them
The scores came from Google PageSpeed Insights -- the same tool Google uses to evaluate sites for search ranking. Running it across all our marketing pages at once showed the same layout shift score (0.428) repeating identically across 11 pages. That pattern made the cause obvious: something shared across all those pages was responsible, not anything page-specific.
Identifying what was shared required a different tool. PageSpeed Insights tells you the score. Chrome DevTools' Lighthouse diagnostic tells you the element. One run, one output:
The footer. Not fonts, not animations, not a third-party script. The footer was jumping because a loading spinner was collapsing the page height during load. Thirty seconds to name the cause. Two lines of CSS to fix it.
The GA issue and the cookie banner were found the same way -- PageSpeed Insights flags the symptom, the specific audit tells you the source. None of these required guesswork. They required using the right tool for the right question.
Why this took 7 hours, not 3 days
With the right diagnostic tools
Each issue was identified on the first targeted measurement. The footer jump took 30 seconds to name once we used the element-level diagnostic. The GA issue was in the bootup-time audit. Total: 7.3 hours including all investigation, fixes, and verification.
Estimated cost: $1,118
Without targeted diagnostics
The same investigation without element-level tooling means guessing at causes -- fonts, animations, scripts -- and redeploying to test each theory. The CLS investigation alone would likely take 1-2 days before landing on the footer. Total: 3-5 days.
Estimated cost: $3,600 -- $6,000
These problems are common. They don't announce themselves.
Visitors who left in 3 seconds aren't in your analytics
They bounced before the page finished loading. You can't see them. The only way to know they're leaving is to measure load time with the same tools Google uses.
The standard GA install is wrong for performance
Every guide says put it in the page head. That's the right place for tracking coverage and the worst place for load time. Moving it back costs nothing in data.
Content that jumps on load costs you real clicks
Cookie banners, login states, lazy-loaded sections -- any of these inserted post-load can move a button before a visitor touches it. Google penalizes each one.
Measurement is not the same as diagnosis
A score tells you something is wrong. An element-level diagnostic tells you exactly what. The gap between those two tools is usually the gap between days of guessing and minutes of fixing.
See what's affecting your site
Stackra audits your site with the same Google tools and flags issues like these with plain-English explanations. Free, no credit card required.
Free to sign up · Results in ~5 minutes