Viewport Units and Dynamic Viewport
Viewport units size elements relative to the viewport, and the dynamic viewport units handle the mobile browser chrome that appears and disappears, so the layout does not jump when the URL bar.
Definition
Viewport units (vw, vh) size elements relative to the viewport dimensions, and the small, large, and dynamic viewport units (svh, lvh, dvh) handle the mobile browser chrome — the URL bar that appears on scroll — so that an element sized to the full viewport does not resize when the chrome appears and disappears, eliminating a class of mobile layout jumps.
Context and scope
Applied in full-viewport sections, sticky footers, and any mobile layout where the browser chrome toggle causes a resize.
Common misconceptions
- vh is the same as dvh — vh is the large viewport on most browsers; dvh tracks the current viewport, which is what most layouts want
- Viewport units work everywhere — the small/large/dynamic variants are recent; older browsers fall back to vh, which is acceptable
Anti-patterns
- Using 100vh on mobile and having the footer hidden behind the URL bar, or jumping when the bar toggles
- Using dvh for a print stylesheet, where there is no dynamic chrome and the unit is meaningless
Related concepts
Authoritative source
https://developer.mozilla.org/en-US/docs/Web/CSS/viewport_percentage
What it is
Viewport units (vw, vh) size elements relative to the viewport dimensions, and the small, large, and dynamic viewport units (svh, lvh, dvh) handle the mobile browser chrome — the URL bar that appears on scroll — so that an element sized to the full viewport does not resize when the chrome appears and disappears, eliminating a class of mobile layout jumps. Applied in full-viewport sections, sticky footers, and any mobile layout where the browser chrome toggle causes a resize. The browser is a hostile, shared, single-threaded (for JS) environment where every millisecond of main-thread work is a millisecond the user cannot interact.
How it works
The rendering pipeline — style, layout, paint, composite — is incremental and can be invalidated by any DOM change. Performance work targets avoiding the expensive phases (layout, paint) and scheduling the rest in idle callbacks or off the main thread. Loading work orders resources by their impact on the critical path: render-blocking scripts are deferred, images get fetch priority, and the server pushes what the client will need next.
When to apply and pitfalls
Apply when user interaction latency or load performance has a measured business impact. The pitfall is micro-optimizing a function while the page ships a megabyte of render-blocking JavaScript — the dominant cost is structural, not algorithmic. Another is measuring in the ideal lab profile and missing the long-tail devices and networks where most users actually live.