A client asked for a sticky header last year, then asked six weeks later why the anchor links on the pricing page kept landing a few centimetres too low. Both requests were reasonable. Nobody had connected them.
The tax nobody itemises
A header that never leaves is a decision to remove that many pixels from every single page, forever. At 72px on mobile, that is roughly a full line of body copy pushed below the fold on every screen a visitor will ever see. Nobody writes “72px, forever” into the brief, because next to “make the nav always visible” it reads like a rounding error.
Where it actually breaks things
- Anchor links land under the header instead of at the top of the section, unless every target carries its own scroll offset
- A hero built to fill the viewport now overflows it by exactly the header’s height
- A full-bleed section above the header needs its own stacking context, or the header stops looking sticky and starts looking broken
- A dropdown or mobile menu has to know the header’s exact height to size itself, which means that height is now a value two components share, not one
What we do instead
We treat the header’s height as a single value, defined once, that every scroll offset, section padding and menu height reads from. When the header’s own design changes at a later breakpoint, that one number changes and the rest of the page follows it, instead of someone finding a fresh anchor-link bug two months after launch.
The honest question
Before making a header “always visible,” ask what it is actually protecting. A nav with three links rarely needs to survive a four-thousand-pixel scroll. A cart icon or a phone number sometimes does. Answer that first, and the header earns the space it is about to take from everything under it.
A header that never leaves is a decision to remove that many pixels from every single page, forever.
