Statiske nettsider: Når de vinner, når de taper
A static site is a collection of pre-built HTML files served directly from a CDN. No server-side processing. No database queries. No PHP, no Node.js, no runtime. The CDN receives a request, looks up the file, and sends it. The entire interaction takes 20-50 milliseconds.
Compare that to a dynamic site: the server receives a request, boots a runtime, queries a database, processes template logic, generates HTML, and sends it. Even optimized, this takes 200-2,000ms. With caching, maybe 50-150ms — but you're caching to approximate what static sites do by default.
The static approach isn't new, but the tooling around it has matured dramatically. Static site generators in 2026 produce sites with interactive components, form handling, API integrations, and rich media — all without a server. The question isn't whether static can build a real website. It's whether your specific requirements fit the static model.
The Static Site Renaissance
Static site generators existed in 2010 (Jekyll, Hugo), but they were tools for developers building developer documentation. The output was rigid HTML — no interactivity, no components, no developer experience to speak of.
The 2026 landscape is fundamentally different. Three shifts drove the renaissance:
Edge hosting became free. Vercel, Netlify, Cloudflare Pages, and GitHub Pages deploy static sites to global CDNs at zero cost. A static site on Cloudflare Pages serves from 200+ edge locations with 99.99% uptime. The hosting cost comparison is absurd: $0/month for performance that beats $100/month managed hosting.
Modern SSGs produce interactive sites. Astro, Next.js (in static export mode), and SvelteKit generate HTML at build time but support interactive JavaScript components where needed. You get the performance of static delivery with the interactivity of a web app. Astro's "islands architecture" only ships JavaScript for interactive components — the rest is pure HTML.
Build tooling got fast. Hugo builds 10,000 pages in under 10 seconds. Astro builds a 100-page marketing site in 15-20 seconds. Next.js with Turbopack rebuilds in milliseconds during development. The "build time" objection that kept teams on dynamic platforms has largely dissolved for sites under 10,000 pages.
The Jamstack (JavaScript, APIs, Markup) ecosystem has consolidated into a simpler pattern: generate static HTML, enhance with JavaScript where needed, connect to APIs for dynamic features. It's no longer a niche approach — it's the default for marketing sites, documentation, blogs, and landing pages.
Where Static Sites Win
For these use cases, static is objectively superior to dynamic in every measurable dimension:
Marketing websites. Your homepage, services pages, about page, and contact page change infrequently. There's zero reason to generate them dynamically on every request. Pre-build them, serve from a CDN, and achieve sub-second load times worldwide. This is what Empirium builds for most clients — a static-first architecture that delivers 95+ Lighthouse scores.
Blogs and content hubs. Blog posts are written once and rarely updated. A static site generator converts markdown or MDX files into HTML pages at build time. No database needed. No CMS backend to secure. Adding a new post means committing a file and triggering a build — 30 seconds from push to production.
Documentation sites. Technical documentation benefits from the simplicity and speed of static generation. Docusaurus, Starlight (Astro), and VitePress are purpose-built for this. Version-specific documentation is handled through build-time path generation, not runtime logic.
Landing pages. Campaign-specific pages that need to load fast, convert visitors, and not break. Static landing pages on a CDN are the most reliable, fastest deployment option. No server to go down during your product launch.
The performance numbers are unambiguous:
| Metric | Static Site (CDN) | Dynamic Site (WordPress) |
|---|---|---|
| TTFB | 20-50ms | 200-2,000ms |
| LCP | 0.5-1.2s | 2.0-5.0s |
| Lighthouse Score | 90-100 | 30-75 |
| Hosting Cost | $0-20/month | $5-100/month |
| Downtime Risk | Near zero (CDN) | Server-dependent |
| Security Surface | Minimal (no server) | Large (PHP, DB, plugins) |
The security advantage deserves emphasis. A static site has no server-side code to exploit, no database to inject into, and no admin panel to brute-force. The attack surface is essentially zero. Dynamic sites, especially WordPress, require constant security patching.
Where Static Sites Lose
Static sites cannot handle requirements that depend on the specific user or the current moment:
User authentication. "Show this dashboard only to logged-in users" requires server-side session validation. You can't pre-build a page that's different for each user. Solutions exist (client-side auth with JWTs, authentication at the edge), but they add significant complexity and break the static model.
Real-time data. Stock prices, live inventory counts, sports scores — anything that changes minute-to-minute can't be pre-built. By the time the static page reaches the visitor, the data is stale. Real-time features require either server-side rendering or client-side data fetching.
E-commerce carts and checkout. A shopping cart is inherently dynamic — it depends on the user's selections, inventory availability, and pricing rules. While product catalog pages can be static, the cart and checkout flow require dynamic server-side processing. Platforms like Shopify and Medusa handle this; building it from scratch on a static platform is impractical.
Personalized content. "Recommended for you" sections, geographically targeted content, A/B test variants, and user-specific pricing all require knowing something about the visitor before rendering. Pure static sites serve the same page to everyone.
Content that changes frequently with high page counts. A news site publishing 50 articles per day with 100,000 archived articles faces build time and deployment challenges with pure static generation. Each new article triggers a rebuild that touches potentially thousands of pages (category pages, tag pages, related articles).
The Hybrid Approach
The modern answer isn't "static or dynamic" — it's "static by default, dynamic where needed." Frameworks like Next.js and Astro make this explicit:
Static pages with client-side dynamic sections. The page structure, navigation, and primary content are statically generated. A small JavaScript component fetches dynamic data (like a live chat widget, real-time notification count, or personalized recommendation) after the static content is visible. The visitor sees the page instantly; dynamic elements appear a moment later.
ISR (Incremental Static Regeneration). Pages are statically generated but automatically regenerate in the background when content changes. Visitors always get a cached static page (fast), while stale pages are silently rebuilt. This eliminates the build-time bottleneck for large sites while maintaining near-static performance.
API routes for dynamic operations. Form submissions, payment processing, and data mutations go to serverless API routes — not the page rendering pipeline. The page itself is static. The interactive operations use dedicated endpoints.
Edge middleware for personalization. Lightweight logic at the CDN edge can modify static pages per visitor — inserting geographically relevant content, A/B test variants, or authentication checks — without a full server-side rendering pipeline.
The hybrid approach looks like this in practice:
/ → Static (ISR, 5min revalidation)
/services/* → Static (SSG, rebuilds on deploy)
/blog/* → Static (ISR, on-demand revalidation)
/api/contact → Serverless function
/api/chat → Serverless function
/dashboard/* → Server-side rendered (auth required)
90% of the site is static. The 10% that needs dynamic behavior gets it. The result: CDN-speed performance for the pages that drive traffic and conversions, server-side rendering only for the pages that require it.
FAQ
Do static sites rank better on Google? Static sites don't inherently rank better — Google doesn't care how your HTML was generated. But static sites consistently have better Core Web Vitals (a ranking signal), faster LCP (which affects bounce rate), and higher Lighthouse scores. The performance advantage translates into an SEO advantage indirectly but measurably.
What about build times for large sites? Astro builds 1,000 pages in under 30 seconds. Next.js with ISR only builds requested pages — pages that haven't been visited yet are generated on first request. Hugo builds 10,000 pages in 10 seconds. For sites under 5,000 pages, build time isn't a practical concern. Above that, ISR or on-demand generation handles scale gracefully.
How do content teams preview changes on a static site? Most headless CMS platforms support preview mode — a special URL that renders draft content without publishing. Next.js Draft Mode, Astro's preview integration, and CMS-specific preview features let editors see their changes in context before triggering a build. The workflow is slightly different from WordPress's instant WYSIWYG preview, but modern tooling has closed most of the gap.
Can I use a static site for a multi-language site? Yes. Generate one set of pages per language at build time. A 50-page site in 10 languages produces 500 HTML files — still trivial for modern build tools. Use hreflang tags and locale-based routing. This is exactly how we build multi-region, multi-language sites at Empirium.
What's the cheapest way to host a static site? Cloudflare Pages: completely free for unlimited sites, unlimited bandwidth, unlimited builds. GitHub Pages: free for public repositories. Vercel and Netlify: free tier covers most small-to-medium sites. The cost floor for static hosting is literally $0/month with enterprise-grade performance.