App Shell Architecture

Also Known As

TL;DR

Explanation

The App Shell model separates the application shell (header, navigation, skeleton layout) from the content. The shell is cached by the service worker on first visit — subsequent visits render the shell instantly from cache (< 100ms) while content fetches from the network. Benefits: reliable fast first paint, works offline for the shell, and progressively enhances with content. Implemented with Service Worker precaching. Works well for: SPAs, PWAs, and any app with a consistent chrome around changing content. Not suited for: content-first sites where every page has a unique layout.

Common Misconception

Why It Matters

Common Mistakes

• Including dynamic content in the app shell — the shell should only contain stable UI chrome.
• No fallback for content fetch failure — offline shell with no content is a bad experience without a fallback page.
• Shell too large — cache only the critical rendering path, not the entire application.
• Not versioning the shell cache — stale shells serve outdated UI after deploys.

Code Examples

// No shell caching — full page re-download on every visit:
// index.html: 45KB (header + nav + content + footer all mixed)
// On 3G: 4 second first paint, every visit
// Offline: nothing works

// Service worker precaches the shell:
const SHELL = [
    '/shell.html',    // Minimal HTML skeleton
    '/app.css',       // Critical styles
    '/app.js',        // Core JS
    '/icons/logo.svg',
];

self.addEventListener('install', e => {
    e.waitUntil(caches.open('shell-v2').then(c => c.addAll(SHELL)));
});

self.addEventListener('fetch', e => {
    // Serve shell instantly from cache:
    if (SHELL.includes(new URL(e.request.url).pathname)) {
        e.respondWith(caches.match(e.request));
    }
    // Content: network first, cache fallback
});

References

• ↗ https://web.dev/articles/app-shell

Tags

Related Terms