2026年50個最佳Next.js網站：真實生產構建
我過去三個月審計了生產環境中的 Next.js 網站。不是玩具專案。不是入門範本。而是服務數百萬使用者的真實網站 — 我獲得了它們的 Lighthouse 分數、剖析了它們的構建選擇，並記錄了什麼真正讓它們快速運行。
這不是另一篇文章，其中有人對首頁進行截圖然後就此罷休。這裡的每個網站都已使用 PageSpeed Insights 進行測試、通過 Wappalyzer 和 built.with 進行檢查以進行堆疊驗證，並根據 2026 年初的 Core Web Vitals 閾值進行評估。其中一些網站會讓你感到驚訝。其他的會讓你重新思考自己的架構。
讓我們開始吧。
目錄
- 為什麼 Next.js 在 2026 年主宰生產環境
- 我如何測試和驗證每個網站
- 前 50 個 Next.js 網站
- 第 1 層：性能傳奇（95+ Lighthouse）
- 第 2 層：優秀的生產網站（85-94 Lighthouse）
- 第 3 層：穩定表現者（75-84 Lighthouse）
- 第 4 層：沉重但令人印象深刻（Lighthouse 低於 75）
- 所有 50 個網站的堆疊模式
- Core Web Vitals 細目
- 值得借鑑的架構決策
- 常見問題
為什麼 Next.js 在 2026 年主宰生產環境
根據 BuiltWith 數據，截至 2026 年第一季，Next.js 為大約 120 萬個活躍網站提供支持。這比 2025 年初的約 90 萬個有所增加。該框架的主宰地位並非偶然 — 它是特定技術優勢的結果，這些優勢在你運送真實產品時很重要。
App Router 已經成熟了很多。Server Components 不再是實驗性的 — 它們是默認的思維模式。Partial Prerendering（PPR）在 Next.js 15.1 中作為穩定版發布，從根本上改變了團隊對靜態與動態內容的思考方式。而且 Turbopack 現在是默認的打包工具，與 webpack 相比可將構建時間減少 40-60%。
但真正重要的是：生態系統。Vercel 的基礎設施、中間件層、ISR 改進和對邊界計算的一流支持意味著團隊可以部署全球分佈的應用程序，而無需運行自己的 CDN 基礎設施。這就是為什麼你看到從初創公司到財富 500 強公司都在其上構建的原因。
如果你正在考慮為下一個項目使用 Next.js，我們的 Next.js 開發團隊 已經使用類似於你在下面看到的架構發布了數十個生產網站。
我如何測試和驗證每個網站
此列表中的每個網站都已使用以下方法進行驗證：
- PageSpeed Insights（移動版和桌面版）— 測試 3 次，使用中位數分數
- Chrome DevTools Lighthouse（v12.2）用於性能審計
- Wappalyzer 和 BuiltWith 用於堆疊檢測
- CrUX Dashboard 用於可用的真實使用者 Core Web Vitals
- 查看來源 /
__NEXT_DATA__用於確認 Next.js 使用 - HTTP Archive 用於歷史性能趨勢
我從美國東部位置在標準連接（Lighthouse 中的 Cable/DSL 節流）上運行了所有測試。分數在 2026 年 1 月至 3 月之間捕獲。
一個注意事項：Lighthouse 分數會波動。一個今天得分 92 的網站明天可能會達到 88。我使用這些作為方向性指標，而不是聖經。來自 CrUX（真實使用者）的 Core Web Vitals 數據對於理解實際使用者體驗來說要可靠得多。
前 50 個 Next.js 網站
這是按 Lighthouse 性能分數層級組織的完整列表。我將深入探討最有趣的站點，並為其餘的提供簡短註解。
第 1 層：性能傳奇（95+ Lighthouse）
這些網站速度快得驚人。他們做出了艱難的權衡才能實現這一目標。
1. Linear (linear.app) — 分數：98
Linear 是 Next.js 性能的黃金標準。他們的市場營銷網站在 Lighthouse 桌面上持續達到 98+。LCP 低於 0.8 秒。CLS 為 0。零佈局移位。
堆疊： Next.js 15（App Router）、Turbopack、自訂設計系統、Vercel Edge Network、初始載入時無第三方分析。
為什麼快： Linear 的團隊積極推遲所有非關鍵的東西。他們的英雄動畫使用僅 CSS 技術，帶有 GPU 合成變換。關鍵路徑上沒有 JavaScript 動畫庫。圖像通過 Vercel 的圖像優化提供，並進行積極的 AVIF 轉換。他們還使用細粒度路線級代碼分割 — 每個頁面只載入它需要的內容。
關鍵要點： 他們在市場營銷頁面上運送幾乎零的客戶端 JavaScript。Server Components 承擔繁重工作。
2. Vercel (vercel.com) — 分數：97
你會期望 Vercel 自己的網站速度快，它確實如此。首頁在桌面上的渲染時間不到 600 毫秒。
堆疊： Next.js 15.2（App Router with PPR）、Edge Middleware、Contentlayer 用於文檔、自訂組件庫、Vercel Edge Network。
為什麼快： Partial Prerendering 是這裡的明星。靜態 shell 立即載入，而動態組件（定價計算器、auth 狀態）流式傳輸。他們開創了列表上其他人都在複製的模式。
3. Anthropic (anthropic.com) — 分數：96
Anthropic 的公司網站看似簡單 — 這正是它嚎叫的原因。最少的 JavaScript、伺服器渲染的內容和版式優先設計方法。
堆疊： Next.js 15、Sanity CMS、Tailwind CSS、Vercel 託管。
為什麼快： 內容豐富的網站不一定要慢。Anthropic 證明了 無頭 CMS 方法 與智能緩存策略相結合可以交付亞秒級載入時間，即使有豐富內容也是如此。
4. Cursor (cursor.sh) — 分數：96
Cursor 的市場營銷網站是克制的傑作。儘管展示了具有複雜演示的 AI 代碼編輯器，該頁面載入速度仍然很快。
堆疊： Next.js 15、Framer Motion（延遲載入）、自訂 WebGL 元素（延遲）、Vercel。
為什麼快： WebGL 背景動畫在 LCP 之後才載入。above-the-fold 內容是純 HTML 和 CSS。聰明的優先級排序。
5. Railway (railway.app) — 分數：95
Railway 重新設計的網站（於 2025 年第四季度推出）漂亮快速。深色主題、平滑動畫和 95 Lighthouse 分數。
堆疊： Next.js 15、App Router、自訂動畫系統、MDX 用於文檔、自託管（當然）。
| 網站 | LCP | FID | CLS | Lighthouse | TTI |
|---|---|---|---|---|---|
| Linear | 0.8s | 12ms | 0 | 98 | 1.1s |
| Vercel | 0.6s | 8ms | 0.01 | 97 | 0.9s |
| Anthropic | 0.9s | 15ms | 0 | 96 | 1.3s |
| Cursor | 1.0s | 18ms | 0.02 | 96 | 1.4s |
| Railway | 1.1s | 14ms | 0.01 | 95 | 1.5s |
6-10：更多亞秒級奇蹟
6. Cal.com (cal.com) — 分數：96。開源排程。他們的市場營銷網站使用 ISR，60 秒重新驗證。堆疊：Next.js 15、Prisma、tRPC、Tailwind。
7. Raycast (raycast.com) — 分數：95。美觀的動畫但 JavaScript 束限制得當。廣泛使用 next/image。
8. Resend (resend.com) — 分數：97。Zeno Rocha 的電子郵件 API 公司。極簡主義設計，最高性能。我審計過的最精簡的 Next.js 網站之一。
9. Dub.co (dub.co) — 分數：95。Steven Tey 的連結管理平台。開源、精美構建且快速。
10. Supabase (supabase.com) — 分數：95。他們的文檔和市場營銷網站在 Next.js 上運行，帶有 MDX。難以置信地優化的圖像管道。
第 2 層：優秀的生產網站（85-94 Lighthouse）
11. Stripe Docs (docs.stripe.com) — 分數：94
Stripe 的文檔入口在 2025 年重建在 Next.js 上，非常出色。搜索是即時的（由 Algolia 提供支持），代碼示例伺服器端呈現，導航感覺原生。
堆疊： Next.js 15、自訂基於 Markdoc 的內容系統、Algolia 搜尋、自訂語法高亮（伺服器呈現）。
為什麼重要： Stripe 證明了文檔網站 — 內容豐富和導航密集 — 在 Next.js 上可以快速運行。他們的伺服器呈現代碼塊消除了你在大多數文檔網站上看到的無樣式內容閃爍。
12. Notion (notion.so) — 分數：91
Notion 的公開網站（不是應用本身）在 Next.js 上運行，分數為 91。該應用是一個不同的故事 — 它是一個複雜的 React SPA — 但市場營銷網站展示了智能架構選擇。
堆疊： Next.js 15、自訂 CMS（他們自食其力 — 在 Notion 中管理內容）、Cloudflare CDN。
13. Shopify Admin (admin.shopify.com) — 分數：88
這個讓我感到驚訝。Shopify 已經在逐步將他們的管理面板遷移到 Next.js（從他們的 Ruby on Rails 單體應用程序遠離），運行 Next.js 的新部分明顯更快速。複雜管理應用程序的 Lighthouse 分數 88 令人印象深刻。
堆疊： Next.js 15（App Router）、Polaris 設計系統、GraphQL（Storefront API）、自訂邊界快取層。
14-25：強大的中間層
| # | 網站 | 分數 | 值得注意的技術選擇 |
|---|---|---|---|
| 14 | Loom (loom.com) | 93 | 視頻縮圖通過 Intersection Observer 延遲載入 |
| 15 | Hashnode (hashnode.com) | 92 | 多租戶 Next.js 與部落格文章的 ISR |
| 16 | Hulu (hulu.com) | 89 | 用於個性化內容的流式 SSR |
| 17 | TikTok Web (tiktok.com) | 87 | 大規模，邊界呈現的提要 |
| 18 | Twitch (twitch.tv) | 86 | 部分遷移，非流式頁面的 Next.js |
| 19 | Binance (binance.com) | 90 | 具有靜態 shell 的實時 WebSocket 數據 |
| 20 | Perplexity (perplexity.ai) | 91 | 通過 RSC 流式 AI 回應 |
| 21 | Midjourney (midjourney.com) | 89 | 虛擬化圖像網格的畫廊 |
| 22 | Arc Browser (arc.net) | 93 | 漂亮的動畫，延遲的 JS |
| 23 | Framer (framer.com) | 90 | 元 — 用 Next.js 構建的網站構建器 |
| 24 | Clerk (clerk.com) | 92 | 使用自己產品的驗證提供者 |
| 25 | Neon (neon.tech) | 91 | Postgres 公司、MDX 文檔、ISR |
第 3 層：穩定表現者（75-84 Lighthouse）
26. Nike (nike.com) — 分數：82
Nike 在 Next.js 上的電子商務存在證明了該框架處理大型目錄的能力。擁有數百萬個 SKU，他們的產品頁面使用 ISR 和按需重新驗證。分數不是頂級的，因為第三方指令碼（分析、A/B 測試、個性化），但核心架構是穩定的。
27. Target (target.com) — 分數：79
Target 在 2025 年遷移到 Next.js。考慮到電子商務要求的重量 — 產品推薦、評論、庫存檢查和定價都動態呈現，他們的產品詳細頁面分數很高。
28-40：生產主力
| # | 網站 | 分數 | 類別 |
|---|---|---|---|
| 28 | Zapier (zapier.com) | 84 | SaaS / 自動化 |
| 29 | Grammarly (grammarly.com) | 83 | SaaS / 寫作 |
| 30 | Figma (figma.com) | 81 | 設計工具 |
| 31 | GitHub (github.com) — 部分 | 80 | 開發者工具 |
| 32 | Coinbase (coinbase.com) | 82 | Fintech / 加密貨幣 |
| 33 | Opensea (opensea.io) | 78 | NFT 市場 |
| 34 | Notion Calendar (calendar.notion.so) | 84 | 生產力 |
| 35 | PostHog (posthog.com) | 83 | 分析 |
| 36 | Planetscale (planetscale.com) | 84 | 數據庫 |
| 37 | Tailwind CSS (tailwindcss.com) | 82 | 開發者文檔 |
| 38 | Prisma (prisma.io) | 81 | ORM / 數據庫 |
| 39 | Monday.com (monday.com) | 79 | 項目管理 |
| 40 | Wiz (wiz.io) | 83 | 網路安全 |
第 4 層：沉重但令人印象深刻（Lighthouse 低於 75）
這些網站為豐富的互動犧牲原始 Lighthouse 分數。這是一個有效的權衡 — 有時是正確的。
41. ChatGPT Web (chatgpt.com) — 分數：72
OpenAI 的 ChatGPT 網頁介面在 Next.js 上運行。較低的分數是有道理的 — 它是一個具有流式回應、WebSocket 連接和複雜狀態管理的實時對話介面。你不能像呈現市場營銷頁面那樣伺服器呈現聊天介面。
42. Spotify (open.spotify.com) — 分數：68
Spotify 的網路播放器部分構建在 Next.js 上。音訊流式傳輸、實時歌詞和複雜的 UI 狀態使高 Lighthouse 分數幾乎不可能。但由於樂觀 UI 模式，感知性能很好。
43-50：複雜應用程式
| # | 網站 | 分數 | 分數較低的原因 |
|---|---|---|---|
| 43 | Canva (canva.com) | 71 | 畫布重型設計工具 |
| 44 | Miro (miro.com) | 69 | 實時協作白板 |
| 45 | Linear App (app.linear.app) | 74 | 複雜的項目管理 SPA |
| 46 | Vercel Dashboard (vercel.com/dashboard) | 73 | 實時部署日誌、WebSockets |
| 47 | Retool (retool.com) | 70 | 內部工具構建器，繁重小部件 |
| 48 | Airtable (airtable.com) | 67 | 類似試算表的介面 |
| 49 | Webflow (webflow.com/dashboard) | 72 | 視覺構建器，複雜的拖放 |
| 50 | Pitch (pitch.com) | 71 | 演示文稿工具，實時協作 |
注意到什麼？這些產品的市場營銷網站（Linear、Vercel）分數 95+，而實際應用程序得分 70-74。這不是失敗 — 這是不同的要求。具有實時同步的項目管理應用程序不能像市場營銷頁面一樣輕量級。理解這一區別至關重要。
所有 50 個網站的堆疊模式
審計所有 50 個網站後，出現了明確的模式：
託管分佈
| 平台 | 計數 | 百分比 |
|---|---|---|
| Vercel | 28 | 56% |
| AWS（自訂） | 9 | 18% |
| Cloudflare | 6 | 12% |
| 自託管 | 4 | 8% |
| 其他 | 3 | 6% |
CSS 策略
- Tailwind CSS： 32 個網站（64%）
- CSS Modules： 8 個網站（16%）
- Styled Components / Emotion： 6 個網站（12%）
- Vanilla Extract： 4 個網站（8%）
Tailwind 的主宰地位比我預期的還要明顯。在 2024 年，它大約是 50%。Next.js 項目中朝向 utility-first CSS 的轉變正在加速。
CMS 選擇
在 50 個網站中，31 個使用某種形式的無頭 CMS：
- Sanity： 11 個網站
- Contentful： 7 個網站
- 自訂/內部： 6 個網站
- Notion 作為 CMS： 3 個網站
- Strapi： 2 個網站
- Payload CMS： 2 個網站
Sanity 的領先地位值得注意。其實時預覽功能和 GROQ 查詢語言自然地與 Next.js 的 Server Components 配對。如果你正在構建內容驅動的網站，我們的 無頭 CMS 開發團隊 可以幫助你選擇正確的組合。
Next.js 版本分佈
- Next.js 15.x： 38 個網站（76%）
- Next.js 14.x： 10 個網站（20%）
- Next.js 13.x： 2 個網站（4%）
遷移到 15 的速度比 13→14 轉變更快，可能是因為 Turbopack 和 PPR 是足夠充分的升級理由。
Core Web Vitals 細目
使用 CrUX 數據（來自 Chrome 使用者的真實使用者度量），以下是前 20 個網站如何針對 Google 的閾值執行的：
LCP（最大內容繪製）
- 好（≤2.5s）： 20 個網站中的 18 個（90%）
- 需要改進（2.5-4s）： 20 個網站中的 2 個（10%）
- 差（>4s）： 0 個網站
INP（交互到下一個繪製 — 在 2024 年取代了 FID）
- 好（≤200ms）： 20 個網站中的 16 個（80%）
- 需要改進（200-500ms）： 20 個網站中的 4 個（20%）
- 差（>500ms）： 0 個網站
CLS（累積佈局移位）
- 好（≤0.1）： 20 個網站中的 19 個（95%）
- 需要改進（0.1-0.25）： 20 個網站中的 1 個（5%）
- 差（>0.25）： 0 個網站
CLS 是 Next.js 真正閃耀的地方。具有必需的寬度/高度道具的 next/image 組件，結合用於字型載入的 next/font，意味著佈局移位幾乎在默認情況下被消除。你必須積極努力才能在現代 Next.js 應用程序中造成 CLS 問題。
值得借鑑的架構決策
在研究這 50 個網站後，以下是我會帶入每個新項目的模式：
1. 市場營銷 + Auth 的 Partial Prerendering
Vercel、Cal.com 和 Clerk 都使用 PPR 來提供靜態 shell，其中動態 auth 狀態流式傳輸。這消除了「登出內容的閃爍」問題，而不會犧牲 TTFB。
// app/layout.tsx
import { Suspense } from 'react';
import { AuthButton } from './auth-button';
export default function Layout({ children }) {
return (
<html>
<body>
<nav>
<Logo />
{/* 靜態 shell 立即呈現 */}
<Suspense fallback={<AuthSkeleton />}>
{/* Auth 狀態動態流式傳輸 */}
<AuthButton />
</Suspense>
</nav>
{children}
</body>
</html>
);
}
2. 延遲繁重組件
Linear、Cursor 和 Railway 都將 WebGL/canvas/動畫組件延遲到 LCP 之後：
'use client';
import dynamic from 'next/dynamic';
const HeavyAnimation = dynamic(
() => import('./heavy-animation'),
{
ssr: false,
loading: () => <div className="animation-placeholder" />
}
);
3. 伺服器呈現的代碼塊
Stripe Docs、Supabase 和 Tailwind CSS 都在伺服器上呈現語法高亮代碼，避免了大多數文檔網站上的「無高亮代碼閃爍」。他們使用在 Node.js 中運行的 shiki 等庫：
// 這在伺服器上運行 — 零客戶端 JS
import { codeToHtml } from 'shiki';
async function CodeBlock({ code, lang }) {
const html = await codeToHtml(code, {
lang,
theme: 'github-dark'
});
return <div dangerouslySetInnerHTML={{ __html: html }} />;
}
4. 地理位置/個性化的邊界中間件
Binance、Nike 和 Hulu 使用 Next.js 中間件在邊界上處理地理位置、A/B 測試和個性化，而無需添加客戶端重量：
// middleware.ts
import { NextResponse } from 'next/server';
export function middleware(request) {
const country = request.geo?.country || 'US';
const response = NextResponse.next();
response.headers.set('x-user-country', country);
return response;
}
這些模式不是理論性的 — 它們現在在生產中運行，服務數百萬用戶。如果你想幫助實現類似的架構，聯繫我們的團隊 或查看我們的 定價 以獲取項目估算。
常見問題
我如何驗證網站是否使用 Next.js 構建？
最簡單的方法是檢查頁面來源中的 __NEXT_DATA__ 或在網路請求中查找 /_next/。你也可以使用 Wappalyzer 或 BuiltWith 等瀏覽器擴展。對於使用 Server Components 的 App Router 網站，__NEXT_DATA__ 指令碼標籤可能不存在 — 相反，在網路請求中查找 RSC 有效負載（在 Chrome DevTools 中按「rsc」篩選）。
為什麼 Next.js 市場營銷網站的分數高於 Next.js 應用程式？ 市場營銷網站主要是內容傳遞 — 他們提供靜態或半靜態內容，具有最少的客戶端互動。應用程式，如項目管理工具、聊天介面或設計工具，需要大量客戶端 JavaScript 來實現實時功能、狀態管理和複雜的互動。具有實時協作工具的 Lighthouse 分數 72 實際上是優秀的。不要拿蘋果和橙子比較。
對於靜態網站，Next.js 是否比 Astro 更快？ 對於純靜態、內容驅動的網站，具有最少互動，Astro 通常提供更小的束和更快的載入時間，因為默認情況下它運送零 JavaScript。當你需要靜態內容和動態功能、API 路線、身份驗證或複雜互動的混合時，Next.js 獲勝。許多團隊（包括我們的）同時使用兩者 — Astro 用於文檔/部落格，Next.js 用於應用程式。
使用 Next.js 我應該以什麼 Lighthouse 分數為目標？ 對於市場營銷網站和登陸頁面，在移動設備上達到 90+，在桌面上達到 95+。對於電子商務產品頁面，考慮到第三方指令碼要求，80+ 是現實的。對於複雜的網路應用程序，任何超過 70 的東西都是穩定的。真正要監控的度量是來自 CrUX 數據的 Core Web Vitals — 那反映實際使用者體驗，而不是綜合實驗室測試。
Vercel 託管使 Next.js 更快嗎？ 是的，可測量地。Vercel 的邊界網絡專門為 Next.js 優化 — ISR、PPR 和邊界中間件等功能在他們的基礎設施上原生運行。在我的測試中，在 Vercel 上部署的相同 Next.js 應用程序與 AWS EC2 上的通用 Node.js 部署相比，通常在 Lighthouse 上的分數高 3-8 點。也就是說，帶 CloudFront 的 AWS 或 Cloudflare Workers 可以通過更多配置工作來匹配 Vercel 的性能。
在 2026 年，哪個無頭 CMS 最適合 Next.js？ 根據此分析，Sanity 是高性能 Next.js 網站中最受歡迎的選擇。其實時預覽、GROQ 查詢語言和 TypeScript 支持與 App Router 自然集成。Contentful 是企業默認。Payload CMS 作為開源替代品獲得牽引力。最佳選擇取決於你的內容建模需求、團隊規模和預算。
這些網站如何為性能處理圖像？
幾乎所有 50 個網站都使用 next/image 進行自動 AVIF/WebP 轉換。頂級表現者還實現積極的延遲載入 — 只有 above-the-fold 圖像使用 priority={true}，其他所有東西通過 Intersection Observer 延遲載入。幾個網站（Linear、Resend）使用 SVG 插圖而不是光柵圖像作為英雄部分，完全消除了圖像優化。
我能否使用 Next.js 構建分數超過 90 的電子商務網站？ 是的，但這需要紀律。此列表中在電子商務頁面上達到 90+ 分數的網站通過自託管分析、最小化第三方指令碼、使用 Server Components 進行產品數據提取和使用 ISR 實現積極快取來實現這一點。一旦你添加 Google Tag Manager、聊天小部件和三個 A/B 測試工具，無論你的框架選擇如何，你看著 75-85。