Vercel vs Cloudflare (Workers + Pages) مقارنة

مصدر Next.js — قدّم أحدث الميزات دون تأخير وبتهيئة صفرية

VS
Cloudflare (Workers + Pages)

شبكة V8-isolate عالمية — بدون egress، والآن مع طبقة Next.js الخاصة بها vinext

15 دقائق للقراءةDevOps

الحكم السريع

القرار يعتمد على وضعك. إذا كنت تريد أحدث ميزات Next.js دون أي تأخير، اختر Vercel — مخاطرة التكافؤ فيها صفر. إذا كان مشروعك عالميًا وثقيل النطاق الترددي وتُعطي الأولوية لإمكانية التنبؤ بالتكلفة، فـ Cloudflare هو الرهان الصحيح؛ إلى جانب OpenNext يوجد الآن vinext الذي لا يزال في مرحلة beta لكنه يتطور بسرعة. ابدأ بـ OpenNext في العمل الحرج، وجرّب vinext في المشروع الجديد.

VercelCloudflare (Workers + Pages)
اقرأ الخلاصة كاملة

مقارنة الدرجات

جارٍ تحميل الرسم البياني...

التقييم التفصيلي

التقييم التفصيلي: Vercel و Cloudflare (Workers + Pages) — درجات كل فئة من 10
الفئةVercelCloudflare (Workers + Pages)
الأداء
8/10
9/10
سهولة التعلّم
9/10
6/10
النظام البيئي
9/10
7/10
المجتمع
9/10
8/10
سوق العمل
8/10
7/10
الاستدامة المستقبلية
8/10
8/10

الإيجابيات والسلبيات

Vercel

الإيجابيات

  • بما أنها الشركة المطوّرة لـ Next.js، تنضج الميزات الجديدة (PPR وTurbopack وApp Router) هنا أولًا
  • نشر بتهيئة صفرية — يكفي git push، ويتم ضبط build/ISR/edge middleware تلقائيًا
  • شبكة CDN بـ 126 PoP في 51 دولة + 20 منطقة قادرة على compute لتقديم SSR بزمن استجابة منخفض
  • فوترة Active CPU مع Fluid Compute — تتوقف الفوترة أثناء انتظار I/O
  • عمليات نشر preview تلقائية لكل PR، تندمج بشكل طبيعي في سير عمل الفريق
  • دعم مباشر لواجهات برمجة تطبيقات Next.js Cache الرسمية (revalidateTag، revalidatePath)

السلبيات

  • Fast Data Transfer بسعر $0.15/GB (أول 1TB مشمول في Pro) — تتضاعف التكلفة بسرعة في المواقع ثقيلة النطاق الترددي
  • لا توجد قاعدة بيانات علائقية/متجهية أصلية؛ باستثناء Blob Storage، تعتمد البيانات على مزوّدين خارجيين (Marketplace)
  • SAML SSO إضافة منفصلة في خطة Pro ($300/شهر)؛ Directory Sync (SCIM) متاح فقط في خطة Enterprise
  • عدد نقاط Edge PoP (126) أكثر محدودية مقارنة بالبصمة العالمية لـ Cloudflare
  • نموذج التسعير القائم على الدوال قد يبقى أغلى من Workers في المواقع ذات الطلبات الكثيرة/CPU المنخفض

الأنسب لـ

الفرق التي تريد استخدام ميزات Next.js الجديدة (PPR، Turbopack، Cache APIs) دون تأخيرالشركات الناشئة والوكالات التي تقوم بتكرار سريع بدون DevOpsفرق المنتج التي تريد سير عمل قائم على preview deploymentتطبيقات SSR الثقيلة على CPU لكن ذات حركة مرور متوسطة

Cloudflare (Workers + Pages)

الإيجابيات

  • لا توجد رسوم egress/bandwidth — تُفوتر فقط الطلبات ($0.30/مليون إضافي) وCPU-time ($0.02/مليون CPU-ms إضافي)
  • %95 من الشبكة على بُعد 50ms من سكان الإنترنت — تغطية جغرافية واسعة جدًا
  • معمارية V8 isolate توفر بدءًا باردًا أخف بنيويًا مقارنة بالدوال القائمة على الحاويات
  • مع vinext، أصبح ~%94 من سطح واجهة برمجة تطبيقات Next.js 16 مدعومًا بعد إعادة تطبيقه
  • يمكن الاحتفاظ بالبيانات في نفس شبكة edge عبر KV وR2 وD1 وHyperdrive وDurable Objects
  • مع Access for Workers (أغسطس 2026) تُربط سياسة الهوية مباشرة بـ Worker، بغضّ النظر عن route أو رابط preview

السلبيات

  • vinext في مرحلة beta — يُنصح بتشغيل `npx vinext check` قبل اعتماده؛ يذكر مستودع GitHub أنه لم يصبح بعد بديلًا كاملًا لكل حِمل عمل production
  • backend الخاص بـ R2 cache لـ ISR+PPR في محول OpenNext يحمل خطر تقادم بعد ~24 ساعة (Issue #662؛ أُبلغ عنه مع الإصدار v1.0.2 من المحول، ولا يزال مفتوحًا)
  • تحسين next/image مدعوم جزئيًا فقط — تتطلب بعض السيناريوهات تهيئة إضافية
  • بما أنها ليست مصدر Next.js، تصل ميزات الإطار الجديدة متأخرة مقارنة بـ Vercel
  • نموذج $5/شهر كرسم أساسي + الطلبات/CPU-time يقلّل من إمكانية التنبؤ في التطبيقات منخفضة الحركة لكن الثقيلة على CPU
  • طبقة OpenNext/vinext تجلب عبئًا تشغيليًا إضافيًا (تحديثات المحول، اختيار backend الخاص بـ cache)

الأنسب لـ

المواقع ثقيلة النطاق الترددي (كثيفة الصور/الفيديو/API) — التكلفة قابلة للتنبؤ بفضل egress المجانيالتطبيقات ذات قاعدة مستخدمين عالمية ومتعددة المناطقالفرق التي تفضّل طبقة بيانات ضمن نظام بيئي واحد مثل KV/D1/R2/Hyperdriveالتطبيقات الداخلية متعددة المسارات (route) التي تحتاج سياسة هوية/وصول مركزية (Access)

مقارنة الكود

Vercel
// Vercel — Next.js 16 App Router، مكوّنات Cache (PPR افتراضي) + purge عند الطلب
// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  cacheComponents: true,
};

export default nextConfig;

// app/blog/[slug]/page.tsx — بيانات مخزَّنة مؤقتًا عبر 'use cache' + cacheTag
import { cacheTag } from "next/cache";

async function getPost(slug: string) {
  "use cache";
  cacheTag(`post-${slug}`);
  const res = await fetch(`https://api.example.com/posts/${slug}`);
  return res.json();
}

export default async function BlogPost({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const post = await getPost(slug);

  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.html }} />
    </article>
  );
}

// app/api/revalidate/route.ts — purge عند الطلب (Vercel Data Cache)
// "max" = stale-while-revalidate؛ للإسقاط الفوري في webhook استخدم { expire: 0 }
import { revalidateTag } from "next/cache";
import { NextRequest, NextResponse } from "next/server";

export async function POST(req: NextRequest) {
  const { slug } = await req.json();
  revalidateTag(`post-${slug}`, "max");
  return NextResponse.json({ revalidated: true });
}

// vercel.json — تفضيل المنطقة ومدة الدالة
{
  "regions": ["fra1"],
  "functions": {
    "app/api/revalidate/route.ts": { "maxDuration": 10 }
  }
}

// نشر (Deploy)
// $ vercel --prod
Cloudflare (Workers + Pages)
// Cloudflare — نشر Next.js 16 على Workers (vinext، الطريق الرسمي الافتراضي)
// 1) قِس التوافق أولًا، ثم أضفه للمشروع (vinext init يُنشئ إعداد Vite)
// $ npx vinext check
// $ npx vinext init

// vite.config.ts — Workers Cache لـ ISR على مستوى route، وKV لتخزين البيانات المؤقت
import { cloudflare } from "@cloudflare/vite-plugin";
import { cdnAdapter } from "@vinext/cloudflare/cache/cdn-adapter";
import { kvDataAdapter } from "@vinext/cloudflare/cache/kv-data-adapter";
import { defineConfig } from "vite";
import vinext from "vinext";

export default defineConfig({
  plugins: [
    vinext({
      // يعمل cdnAdapter فقط عندما يكون "cache": { "enabled": true } في wrangler.jsonc
      cache: { cdn: cdnAdapter(), data: kvDataAdapter() },
    }),
    cloudflare({
      viteEnvironment: { name: "rsc", childEnvironments: ["ssr"] },
    }),
  ],
});

// نشر — يُنشئ تهيئة Worker بنفسه
// $ npx @vinext/cloudflare deploy

// بديل: محول OpenNext — open-next.config.ts
import { defineCloudflareConfig } from "@opennextjs/cloudflare";
import r2IncrementalCache from "@opennextjs/cloudflare/overrides/incremental-cache/r2-incremental-cache";

export default defineCloudflareConfig({ incrementalCache: r2IncrementalCache });
// $ opennextjs-cloudflare build && opennextjs-cloudflare deploy

// Access for Workers — ربط Worker بتطبيق Access
// POST /accounts/{account_id}/access/apps
// "destinations": [{ "type": "worker", "worker_id": "<worker-id>" }]

الخلاصة

القرار يعتمد على وضعك. إذا كنت تريد أحدث ميزات Next.js دون أي تأخير، اختر Vercel — مخاطرة التكافؤ فيها صفر. إذا كان مشروعك عالميًا وثقيل النطاق الترددي وتُعطي الأولوية لإمكانية التنبؤ بالتكلفة، فـ Cloudflare هو الرهان الصحيح؛ إلى جانب OpenNext يوجد الآن vinext الذي لا يزال في مرحلة beta لكنه يتطور بسرعة. ابدأ بـ OpenNext في العمل الحرج، وجرّب vinext في المشروع الجديد.

احصل على استشارة مجانية
الأسئلة الشائعة

الأسئلة الشائعة

ليس بشكل كامل لكنه قريب جدًا: طبقة vinext الجديدة من Cloudflare تدعم حوالي %94 من سطح واجهة برمجة تطبيقات Next.js 16 (App Router وServer Actions وISR وmiddleware) وهي الطريق الرسمي الافتراضي — لكنها لا تزال في مرحلة beta؛ يقول التوثيق إنه يجب تشغيل `npx vinext check` قبل اعتمادها في تطبيق production قائم. أما محول `@opennextjs/cloudflare` الأكثر نضجًا فيحمل مشكلة تقادم (bayatlama) في backend الخاص بـ R2 cache لـ ISR+Partial Prerendering (مشكلة مفتوحة على GitHub).

مقالات مدونة ذات صلة

عرض جميع المقالات

مشاريع ذات صلة

عرض جميع المشاريع
جميع المقارنات