Sticky Header Section: Behaviour, Height and Mobile Trade-offs

Pinning a header is two clicks; everything difficult about it follows from taking the section out of the page flow.

What a sticky header section costs, and when it is worth paying

Making a header stick to the top of the viewport is a two-click change in every page builder, which is exactly why it gets applied without a decision. The mechanics are simple: the section is taken out of the normal document flow and pinned to the viewport, so it stays put while everything else scrolls under it. Everything difficult about a sticky header follows from that one sentence.

A pinned section is permanently occupying screen space and permanently overlapping whatever scrolls beneath it. On a wide desktop screen that is a small price for a navigation bar that is always reachable. On a phone held in one hand, the same header can be eating a meaningful share of everything the visitor can see, on every page, forever.

Decide what the header is for before you pin it

A sticky header earns its space when something inside it is genuinely needed at any scroll position. That is a short list:

• A primary action. A call button, a booking link, a cart — something a visitor may decide to use at any moment, including halfway down a long page.
• Navigation on a long page. Where the page is long enough that returning to the top is a real cost.
• Orientation in a multi-step flow. Where the visitor needs to see where they are.

A logo is not on that list. Neither is a menu on a short landing page whose only job is one conversion, where the sticky header mostly offers an escape route from the page you paid to send someone to. If the page has one action, a header that competes with it is working against you.

The problems a pinned section creates

The last row is the one that shows up in a performance report rather than in someone’s complaint. A header that changes height or switches to a pinned state after the page has painted moves everything below it, and that movement is measured. If a client’s page speed score dropped after a redesign, a header that resizes on scroll is a reasonable first suspect.

Mobile is the case that decides the design

Desktop hides the cost of a sticky header. Phones do not. Before shipping one, look at the actual page on a phone and count what is left: how much of the visible screen belongs to the header, and what the visitor can read without scrolling.

Three approaches, in rising order of complexity:

• Unpin below a breakpoint. The header scrolls away on phones and sticks on desktop. Simple, predictable, and often correct.
• Shrink on scroll. A tall header with a logo and menu becomes a slim bar once the visitor moves down. Costs some complexity, and needs the height reserved so the transition does not shift the page.
• Hide on scroll down, show on scroll up. Gives back the space while reading and returns the header the moment the visitor looks for it. The most screen-efficient option and the fiddliest to get right, particularly around the top of the page and on short pages.

Whichever you choose, the mobile header should carry fewer items than the desktop one. Reordering a header’s contents for a phone is the same discipline as the rest of the layout, and worth reading alongside how a phone stacks columns, because a header built as a multi-column row will stack into something tall and unusable if nobody decides otherwise.

Stacking order: fix it once, deliberately

A pinned element sits above the page, and every other floating thing on the site wants to sit above it: dropdown menus, modals, cookie notices, chat widgets, sticky footers, embedded frames. The usual failure pattern is that each conflict gets solved by raising one element a little higher than the last, until the order is an accident nobody can reason about.

Decide the order once, write it down, and apply it: base content lowest, then the sticky header, then menus opened from it, then modal overlays, then anything that must sit above everything. An embedded form in a frame is a common casualty — if a frame is being clipped or overlapped rather than mis-sized, the stacking order is the place to look before the frame height settings.

Accessibility and keyboard behaviour

Two issues turn up consistently and both are easy to miss on a mouse-driven desktop test.

Focus scrolled under the header

Tabbing through a page scrolls the focused element into view. A browser scrolls it just inside the viewport, which for a page with a pinned header means just under the header. The person tabbing cannot see the element that has focus. Reserving scroll padding equal to the header height fixes it for every focus move, not only for anchor links.

The header should be reachable, not inescapable

Keyboard users should be able to move past the header into the content without tabbing through every menu item on every page. A skip link handles that, and it costs nothing to include.

Where sticky headers break after launch

• The height changed and the offsets did not. Someone adds a notice bar or a taller logo, and every anchor link on the site is now slightly wrong. Derive spacing from the header’s real height rather than typing a number.
• It came with a template. A copied page or template can carry its own header behaviour, which then coexists with the site’s. Worth checking whenever you have just gone through a template import.
• It is applied to pages that should not have it. Checkout, thank-you and single-action landing pages usually want less chrome, not more, and that is the same per-page decision as showing a footer only where it belongs.
• It was tested only at the top of the page. The pinning transition, the shrink, and the behaviour at the very bottom of a short page are where the visual defects live.

A short test pass before you call it done

• Load the page and check nothing is hidden behind the header at scroll position zero.
• Scroll slowly through the pinning transition and watch for a jump.
• Click every anchor link and confirm each target heading is fully visible.
• Open every dropdown, modal and widget and confirm each appears above what it should.
• Tab through the page and confirm the focused element is never under the header.
• Repeat all of it on a phone, in both orientations, on a short page as well as a long one.

See also: Tablet View Page Builder Settings and What They Inherit

Frequently Asked Questions

Should every page have a sticky header?

No. A pinned header earns its space only when something in it is needed at any scroll position, such as a primary action or navigation on a long page. On a single-action landing page it mostly offers an escape route from the conversion you paid to send someone to, and on checkout or thank-you pages less chrome is usually better. Decide it per page rather than sitewide.

Why do my anchor links land underneath the sticky header?

Because a pinned header is removed from the document flow and overlays the page, while the browser scrolls the anchor target to the very top of the viewport, which is now behind the header. The fix is a scroll offset or scroll padding equal to the header’s height. Derive it from the real height rather than typing a number, or it will be wrong the next time somebody adds a notice bar.

Does a sticky header hurt page speed scores?

The pinning itself is cheap, but a header that changes height or switches to a pinned state after the page has painted moves everything below it, and that movement is measured as layout instability. Reserve the header’s height from the start so nothing reflows when it pins. If a score dropped after a redesign, a header that resizes on scroll is a reasonable first place to look.

Should the mobile header be the same as the desktop one?

Rarely. A phone screen makes the cost of a pinned header visible in a way a desktop monitor hides, so the mobile version should carry fewer items, usually just the one element that has to persist. The three common approaches are to unpin below a breakpoint, shrink the header on scroll, or hide it on scroll down and bring it back on scroll up, in rising order of complexity.

Why does my dropdown menu open behind the header?

Because the stacking order was decided one conflict at a time rather than once. A pinned header sits above the page, and every other floating element wants to sit above it, so raising one element to fix one bug pushes the next bug somewhere else. Set a deliberate order sitewide: content, then the sticky header, then menus opened from it, then modals, then anything that must sit above everything.

What does a sticky header do to keyboard navigation?

Tabbing scrolls the focused element just inside the viewport, which on a page with a pinned header means just underneath it, so keyboard users lose sight of what has focus. Scroll padding equal to the header height fixes it for every focus move, not only for anchor links. Add a skip link as well, so keyboard users can move past the header into the content.

How should I test a sticky header before launch?

Check the top of the page for content hidden behind the header, scroll slowly through the pinning transition to look for a jump, click every anchor link, open every dropdown and modal to confirm the stacking order, and tab through the page watching where focus lands. Then repeat all of it on a phone in both orientations, and on a short page as well as a long one.

We build your GoHighLevel account for you

CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.

• Setup (one-time)$850
• Ongoing (per month)$38.80

Get my free setup quote

No obligation quote · reply within 1 business day

This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.