لديك لوحة تحكم WordPress مفتوحة تحتوي على 228 منشور مدونة، وعلامة Lighthouse للجوال تبلغ 35، ورسم بياني للزيارات ينحدر لمدة ثلاثة أشهر. كانت SleepDr.com — وهي موقع محتوى متخصص في صحة النوم — تراقب انخفاض الزيارات العضوية بنسبة 41% بعد أن أدخلت تحديث Core الأساسي لشهر مارس 2026 من Google نظام تسجيل Core Web Vitals على مستوى الموقع. أصبح كل منشور بطيء الآن مسؤولية، مما يسحب الصفحات التي حملت بشكل جيد بمفردها. احتاج العميل إلى السرعة في جميع أنحاء المجال، وليس فقط الصفحة الرئيسية. لقد قمنا بترحيل مكتبة المحتوى الكاملة إلى Next.js 15 و Payload CMS 3 و Vercel — ورفعنا علامة Lighthouse للجوال إلى 94 في ستة أسابيع. إليك المكدس الذي اخترناه، والاختناقات الثلاثة في الأداء التي قضينا عليها، والمقياس الذي كان مهماً حقاً.

قمنا بترحيلهم إلى Next.js 15 + Payload CMS 3 + Supabase + Vercel. النتيجة: Lighthouse للجوال 94، سطح المكتب 99. تعافت حركة المرور العضوية خلال 6 أسابيع. هذه هي القصة الكاملة لكيفية وصولنا إلى هناك — كل تحسين، كل مقياس، كل قرار — حتى تتمكن من تطبيق نفس الفكر على مشاريعك الخاصة.

جدول المحتويات

دراسة حالة SleepDr: ترحيل WordPress إلى Next.js (Lighthouse 35→94)

الوضع السابق: لماذا كان WordPress يدمر SleepDr

كانت إعدادات SleepDr الخاصة بـ WordPress مثالاً نصياً للديون التقنية المتراكمة. خلال ثلاث سنوات، قاموا بتثبيت 34 إضافة. كانت السمة تحمل jQuery بالإضافة إلى مكتبتي JavaScript إضافيتين. كل طلب صفحة ضرب قاعدة بيانات MySQL، وتم إنشاء HTML على الذاي، وتقديم الصور غير المحسّنة من خلال خطة استضافة مشتركة كانت تكافح بالفعل تحت الحمل.

إليك ما بدا عليه تدقيق Lighthouse الأولي على الجوال:

  • الدرجة الإجمالية: 35 (أحمر، فاشل)
  • FCP: 4.2 ثانية
  • LCP: 6.8 ثوان — تقريباً ثلاث مرات من حد "جيد"
  • CLS: 0.28 — كان التخطيط يقفز في كل مكان من الإعلانات والصور بدون أبعاد وتحميل خط الويب
  • TBT: 1200ms — كان الخيط الرئيسي مقفلاً لأكثر من ثانية
  • TTFB: 2.1 ثانية — كان الخادم نفسه بطيئاً قبل أي شيء حتى في البداية

لم يكن الموقع مجرد بطيء. كان معادياً بنشاط لمستخدمي الأجهزة المحمولة. وبما أن محاكاة Lighthouse الجوال من Google تحاكي هاتفاً من الفئة المتوسطة على اتصال 4G مقيد، فإن الدرجات عكست ما يختبره المستخدمون الفعليون في ظل ظروف أقل من المثالية.

بعد أن قدمت Google تحديث Core الأساسي في مارس 2026 وقدمت نظام تسجيل CWV الشامل — حيث تجمع الأداء عبر المجال بأكمله بدلاً من كل صفحة — كانت 228 منشور مدونة بطيء على SleepDr تسمم تصنيفاتهم على مستوى الموقع. أظهرت البيانات المبكرة من الطرح انخفاضات في حركة المرور بنسبة 20-35% للمواقع المتأثرة. شهدت SleepDr انخفاضاً تقريباً بنسبة 30%.

كان يجب أن يتغير شيء ما.

مكدس الترحيل: لماذا اخترنا ما اخترناه

لم نختر هذا المكدس لأنه عصري. اخترناه لأن كل جزء يحل مشكلة محددة كانت لدى SleepDr.

  • Next.js 15 (App Router): العرض الهجين. الإنشاء الثابت لمنشورات المدونة، العرض من جانب الخادم حسب الحاجة. مكونات خادم React لتقليل JavaScript على جانب العميل. هذا هو خبزنا وزبدتنا — لقد بنينا عشرات المشاريع عليه من خلال ممارسة تطوير Next.js.
  • Payload CMS 3: نظام إدارة محتوى headless مستضاف ذاتياً أعطى فريق المحتوى في SleepDr نفس تجربة التحرير التي اعتادوا عليها مع WordPress، ناقصاً التضخيم. نحن نتعامل مع الكثير من تطبيقات headless CMS وأصبح Payload 3 خيارنا الأول للمواقع الثقيلة من حيث المحتوى.
  • Supabase: قاعدة بيانات PostgreSQL مع قدرات في الوقت الفعلي. تعاملت مع طلبات نموذج الاتصال وأحداث التحليلات وأي بيانات ديناميكية.
  • Vercel: نشر على الحافة. يخدم الموقع من العقدة الأقرب للمستخدم. تصبح TTFB غير مهمة تقريباً.

استغرق الترحيل الكلي 7 أسابيع. استغرق ترحيل المحتوى — جميع 228 منشور مع صورهم وبيانات وصفية وهياكل URL — حوالي أسبوعين من ذلك. كتبنا نصاً مخصصاً لسحب المحتوى من WordPress REST API، وتحويله، وإدراجه في Payload CMS.

قبل وبعد: الأرقام

إليك الانهيار الكامل. هذه درجات Lighthouse للجوال، وهذا هو المكان الذي تكمن فيه القصة الحقيقية.

المقياس قبل (WordPress) بعد (Next.js 15) التحسن
First Contentful Paint (FCP) 4.2s 1.1s -3.1s (أسرع بنسبة 74%)
Largest Contentful Paint (LCP) 6.8s 1.8s -5.0s (أسرع بنسبة 74%)
Cumulative Layout Shift (CLS) 0.28 0.01 -0.27 (انخفاض بنسبة 96%)
Total Blocking Time (TBT) 1,200ms 50ms -1,150ms (انخفاض بنسبة 96%)
Time to First Byte (TTFB) 2.1s 0.3s -1.8s (أسرع بنسبة 85%)
إجمالي درجة الجوال 35 94 +59 نقطة
إجمالي درجة سطح المكتب 61 99 +38 نقطة

أريد أن أكون واضحاً: هذه ليست أرقاماً مختارة بعناية من صفحة واحدة. قمنا بتشغيل Lighthouse على 20 صفحة تمثيلية وحساب المتوسط. تراوحت درجة الجوال من 91 إلى 97 عبر جميع الصفحات المختبرة. كان سطح المكتب من 97 إلى 100.

الآن دعني أرشدك عبر بالضبط كيفية حققنا كل واحدة من هذه التحسينات.

دراسة حالة SleepDr: ترحيل WordPress إلى Next.js (Lighthouse 35→94) - الهندسة المعمارية

التحسين 1: تحسين الصور (LCP -3s)

كانت الصور هي قاتل الأداء الأكبر على الموقع القديم. كانت منشورات مدونة SleepDr ثقيلة على التصوير الفوتوغرافي للمنتجات والرسوم البيانية — غالباً ما تم تحميلها بدقة كاملة PNG مباشرة من آلة المصمم. كانت بعض الصور بحجم 3-4 ميجابايت لكل منها.

ما فعلناه

استخدام next/image لكل صورة واحدة. يقوم هذا المكون بالكثير من الرفع الثقيل:

import Image from 'next/image';

export function HeroImage({ src, alt }) {
  return (
    <Image
      src={src}
      alt={alt}
      width={1200}
      height={630}
      priority // فوق الطي hero: قم بتحميله مسبقاً
      sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
      quality={80}
    />
  );
}

إليك ما يتعامل معه next/image تلقائياً:

  • تحويل الصيغة: يخدم WebP (أو AVIF حيث يتم دعمه) بدلاً من PNG/JPEG. وحده هذا قلل أحجام الصور بنسبة 60-80%.
  • srcset سريع الاستجابة: ينشئ أحجام متعددة حتى لا يحمل مستخدمو الجوال صور بحجم سطح المكتب.
  • التحميل الكسول بشكل افتراضي: الصور أسفل الطي لا تحمل حتى يقترب المستخدم من التمرير.
  • الأبعاد الصريحة: تحتفظ دعائم width وheight بالمساحة في التخطيط، والتي تصحح CLS مباشرة.

الرؤية الأساسية: تحميل الأولويات لعناصر LCP

كان دعم priority على صورة البطل حرجاً. بدونها، يقوم Next.js بتحميل الصورة بكسل. لكن إذا كانت صورة البطل هي عنصر LCP — والذي كان كذلك على معظم صفحات SleepDr — فإن تحميلها بكسل يضر فعلاً بدرجة LCP الخاصة بك. تريد أن تبدأ التنزيل على الفور.

قمنا بتدقيق كل قالب صفحة، وحددنا عنصر LCP، وميزناه بـ priority. استخدمت صفحات منشور المدونة الصورة المميزة. استخدمت الصفحة الرئيسية لافتة البطل. بسيط، لكنه أحدث فرقاً بمدة 3 ثوان على LCP.

صورة CDN

تعمل تحسينات الصور المدمجة في Vercel كـ CDN. يتم معالجة الصور وتخزينها مؤقتاً على الحافة عند الطلب الأول. يحصل الزوار اللاحقون على نسخة مخزنة مؤقتاً محسّنة في أجزاء من الثانية. لا توجد حاجة لاشتراك في Cloudinary. لا توجد مكونة إضافية في WordPress تحاول القيام بنفس الشيء ولكن بشكل أسوأ.

صافي التأثير: انخفض LCP من 6.8s إلى حوالي 3.8s من تحسين الصور وحده. جاءت مكاسب LCP المتبقية من تحسينات TTFB وتحميل الخط.

التحسين 2: تحسين الخطوط (FCP -1.5s)

حملت سمة SleepDr الخاصة بـ WordPress ثلاث Google Fonts عبر روابط ورقة أنماط خارجية. كان كل واحد طلب render-blocking إلى fonts.googleapis.com، متبوعاً بطلب آخر إلى fonts.gstatic.com للملفات الفعلية للخط. هذا ستة جولات شبكة قبل أن يتمكن المتصفح من رسم النص.

ما فعلناه

الخطوط المستضافة ذاتياً باستخدام next/font:

import { Inter, Merriweather } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
});

const merriweather = Merriweather({
  weight: ['400', '700'],
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-merriweather',
});

ما يفعله next/font بشكل مختلف:

  • استضافة ملفات الخط: لا توجد طلبات شبكة خارجية. يتم تجميع الخطوط مع الإنشاء وتقديمها من نفس CDN.
  • Subsetting تلقائي: يتضمن فقط مجموعات الأحرف التي تحتاجها فعلاً. مجموعة اللاتينية من Inter حوالي 20KB بدلاً من ملف 100KB+ كامل.
  • display: 'swap': يعرض النص على الفور بخط بديل، ثم يتبادل إلى خط الويب عند تحميله. لا نص غير مرئي. لا وميض من المحتوى غير منسق يحجب FCP.
  • حقن متغير CSS: يتم تطبيق الخط عبر خصائص CSS المخصصة، مما يعني عدم وجود تحول تخطيط عند تبادل الخط لأننا طابقنا بعناية مقاييس خط الفقدان.

كما أسقطنا الخط الثالث تماماً. استخدم الموقع القديم خط زينة للعناوين أضافت ضوضاء بصرية دون تحسين القابلية للقراءة. خطان. هذا كل شيء.

صافي التأثير: تم تحسين FCP بحوالي 1.5 ثانية من القضاء على طلبات الخط render-blocking.

التحسين 3: تقليل JavaScript (TBT 1200ms → 50ms)

كان هذا أكثر تحسن واحد درامي. TBT بمقدار 1200ms يعني أن خيط المتصفح الرئيسي كان محجوباً لأكثر من ثانية واملة — لا يمكن للمستخدم النقر أو الحركة أو التفاعل مع أي شيء خلال هذا الوقت.

أين جاء كل هذا JavaScript؟

حمل موقع WordPress:

  • jQuery (87KB مصغر) — تستخدمه السمة ومعظم المكونات الإضافية
  • 34 نصاً للمكونات الإضافية — نموذج الاتصال، والتحليلات، ومشاركة وسائل التواصل الاجتماعي، وموافقة ملفات تعريف الارتباط، ومكتبتا منزلقات مختلفة، وصندوق الضوء، وأكثر من ذلك
  • theme JavaScript — 150KB إضافية من تبديلات القائمة ومكتبات الحركة
  • نصوص مضمنة — مقاطع عشوائية من المكونات الإضافية المختلفة المحقونة في <head>

إجمالي JavaScript في تحميل الصفحة: تقريباً 1.8MB. على اتصال جوال مقيد، يستغرق تحليل وتنفيذ ذلك أكثر من ثانية.

ما فعلناه

jQuery صفر. يستخدم Next.js React. لا نحتاج jQuery.

المكونات الإضافية صفر. تم إعادة بناء كل ميزة كمكون مخصص الغرض:

  • نموذج الاتصال: مكون React 4KB + إجراء خادم Supabase
  • موافقة ملفات تعريف الارتباط: مكون 2KB مع استراتيجية next/script
  • مشاركة وسائل التواصل الاجتماعي: Native Web Share API مع روابط fallback — لا توجد مكتبة مطلوبة
  • التحليلات: نص Plausible خفيف الوزن (< 1KB)

الواردات الديناميكية لأي شيء أسفل الطي:

import dynamic from 'next/dynamic';

const NewsletterSignup = dynamic(
  () => import('@/components/NewsletterSignup'),
  { ssr: false } // يحمل فقط على العميل، فقط عند الحاجة
);

const RelatedPosts = dynamic(
  () => import('@/components/RelatedPosts')
);

مكونات React Server معالجة معظم العرض. محتوى منشور المدونة والرؤوس والتذييلات والملاح — كل شيء معروض من جانب الخادم مع عدم وجود JavaScript على جانب العميل. فقط العناصر التفاعلية (تبديل القائمة المحمول، نموذج الاتصال، اشتراك النشرة الإخبارية) يرسل JS إلى المتصفح.

إجمالي JavaScript في تحميل الصفحة بعد الترحيل: تقريباً 85KB. هذا انخفاض بنسبة 95%.

صافي التأثير: انخفض TBT من 1200ms إلى 50ms. الخيط الرئيسي في الأساس مجاني.

التحسين 4: العرض من جانب الخادم والنشر على الحافة (TTFB -85%)

تقيس TTFB مقدار الوقت المستغرق لبدء الخادم في إرسال البايت الأول من الاستجابة. كان موقع SleepDr الخاص بـ WordPress بـ TTFB بمدة 2.1 ثانية على الجوال. هذا يعني أنه قبل حدوث أي شيء — قبل تحميل الصور، وقبل تنزيل الخطوط، وقبل تنفيذ JavaScript — كان المستخدم ينظر إلى شاشة فارغة لمدة أكثر من ثانيتين في انتظار استجابة الخادم.

لماذا كان WordPress بطيئاً جداً

كل طلب صفحة على WordPress:

  1. ضرب خادم الاستضافة المشترك (بطيء بالفعل)
  2. PHP محمل
  3. تنفيذ WordPress core
  4. ركض من خلال 34 hook المكونات الإضافية
  5. استفسر MySQL عدة مرات
  6. HTML المولدة ديناميكياً
  7. أرسل الاستجابة

حتى مع تثبيت WP Super Cache، كان معدل الإصابة في الذاكرة المؤقتة غير متسق والخادم نفسه كان ضعيفاً.

ما فعلناه

الإنشاء الثابت لجميع 228 منشور مدونة. في وقت الإنشاء، يعيد Next.js تقديم كل منشور مدونة إلى HTML ثابت. النتيجة مجموعة من ملفات .html الجالسة على Vercel's Edge Network — موزعة عبر 80+ موقع عالمي.

عندما يطلب المستخدم منشور مدونة، يتم تقديم ملف HTML مُعاد البناء من عقدة الحافة الأقرب. لا استعلام قاعدة بيانات. لا معالجة من جانب الخادم. فقط قراءة ملف من CDN.

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await payload.find({
    collection: 'posts',
    limit: 300,
  });

  return posts.docs.map((post) => ({
    slug: post.slug,
  }));
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug } },
    limit: 1,
  });

  return <ArticleLayout post={post.docs[0]} />;
}

بالنسبة لصفحة نموذج الاتصال، استخدمنا العرض من جانب الخادم لأنها تحتاج إلى سلوك ديناميكي. لكن حتى SSR على Edge Functions Vercel يعمل في أقل من 100ms لأن الحساب يحدث على الحافة، وليس في مركز بيانات مركزي.

صافي التأثير: انخفضت TTFB من 2.1s إلى 0.3s — تحسن بنسبة 85%. على الزيارات المتكررة مع التخزين المؤقت، إنها أقرب إلى 50ms.

التحسين 5: إدارة نصوص الجهات الخارجية

نصوص الجهات الخارجية هي الأشياء التي تقتل الأداء بصمت. حمل موقع SleepDr الخاص بـ WordPress Google Analytics (GA4)، ومدير علامات Google، وبكسل Facebook، ونص تسجيل Hotjar، ومدير موافقة ملفات تعريف الارتباط — جميع render-blocking في <head>.

ما فعلناه

يوفر Next.js مكون next/script مع استراتيجيات التحميل. استخدمناها بقصد:

import Script from 'next/script';

{/* التحليلات: تحميل بعد أن تصبح الصفحة تفاعلية */}
<Script
  src="https://plausible.io/js/script.js"
  strategy="afterInteractive"
  data-domain="sleepdr.com"
/>

{/* موافقة ملفات تعريف الارتباط: تحميل عند خمول المتصفح */}
<Script
  src="/scripts/cookie-consent.js"
  strategy="lazyOnload"
/>

تقوم استراتيجية afterInteractive بتحميل النص بعد اكتمال رطوبة Next.js. يمكن للمستخدم بالفعل رؤية والتفاعل مع الصفحة. تنتظر استراتيجية lazyOnload حتى يصبح المتصفح خاملاً تماماً — رائع للنصوص غير الحرجة.

كما استبدلنا Google Analytics بـ Plausible (< 1KB، والخصوصية أولاً، لا تحتاج إلى موافقة ملفات تعريف الارتباط في معظم الاختصاصات القضائية). أزال Hotjar تماماً — لم تكن SleepDr تراجع التسجيلات فعلاً. أزال بكسل Facebook لأنهم توقفوا عن تشغيل إعلانات Facebook قبل ستة أشهر.

قتل نصوص الجهات الخارجية غير الضرورية هي أسهل فوز أداء في تطوير الويب. أستمر في قول هذا. تحمل معظم المواقع نصوصاً لخدمات لا يستخدمها أي شخص في الفريق بنشاط.

التحسين 6: تحسين CSS (800KB → 35KB)

حملت سمة SleepDr الخاصة بـ WordPress تقريباً 800KB من CSS. كان يتضمن ورقة نمط السمة، وأوراق نمط المكونات الإضافية، ونظام شبكة Bootstrap كامل (غير مستخدم)، وـ Font Awesome (لحوالي 12 أيقونة).

ما فعلناه

Tailwind CSS مع التطهير التلقائي. يقوم Tailwind بفحص ملفات القالب الخاصة بك في وقت الإنشاء ويولد CSS فقط للفئات المساعدة التي تستخدمها فعلاً. حزمة CSS الإنتاج الخاصة بنا: 35KB (gzipped: ~8KB).

// tailwind.config.ts
export default {
  content: [
    './app/**/*.{ts,tsx}',
    './components/**/*.{ts,tsx}',
  ],
  theme: {
    extend: {
      fontFamily: {
        sans: ['var(--font-inter)'],
        serif: ['var(--font-merriweather)'],
      },
    },
  },
};

بالنسبة إلى 12 أيقونة، استخدمنا SVGs مضمنة. لا توجد مكتبة أيقونات. كل SVG حوالي 500 بايت. وزن الرموز الإجمالي: ~6KB مقابل 70KB+ من Font Awesome.

النتيجة هي عدم وجود طلبات CSS render-blocking. يتم تضمين إخراج Tailwind في حمولة HTML الأولية بواسطة Next.js، حتى يتمكن المتصفح من بدء العرض على الفور.

صافي التأثير: انخفض CSS بنسبة 96%، مما يساهم في تحسينات FCP و TBT.

قائمة التحقق خطوة بخطوة

إذا كنت تواجه مشاكل أداء مماثلة، فإليك الترتيب الدقيق الذي أتعامل معه. هذا يتم تحديد أولوياته حسب نسبة التأثير إلى الجهد.

المرحلة 1: الانتصارات السريعة (الأسبوع 1)

  • قم بتشغيل Lighthouse على أعلى 10 صفحات لحركة المرور الخاصة بك (وضع الجوال)
  • حدد عناصر LCP في كل قالب صفحة
  • أضف width وheight صريحة لجميع الصور و iframes
  • أضف loading="lazy" للصور أسفل الطي
  • أضف fetchpriority="high" للصور LCP
  • تدقيق نصوص الجهات الخارجية — أزل أي شيء غير مستخدم
  • انقل نصوص الجهات الخارجية المتبقية إلى async أو defer

المرحلة 2: الخطوط و CSS (الأسبوع 2)

  • استضافة ذاتية لخطوط الويب (القضاء على طلبات الخط الخارجية)
  • أضف font-display: swap إلى جميع إعلانات @font-face
  • مجموعة فرعية من الخطوط إلى مجموعات الأحرف المطلوبة فقط
  • تدقيق CSS — أزل أوراق الأنماط غير المستخدمة
  • استبدل خطوط الرموز بـ SVGs مضمنة

المرحلة 3: JavaScript (الأسبوع 3)

  • تحليل الحزمة لتحديد أكبر تبعيات JS
  • أزل jQuery إن أمكن
  • الاستيراد الديناميكي للمكونات غير الحرجة
  • تأجيل JavaScript غير الضروري
  • تنفيذ تقسيم الكود لكل مسار

المرحلة 4: البنية الأساسية (الأسبوع 4+)

  • قيّم خيارات CDN / نشر Edge
  • تنفيذ الإنشاء الثابت لصفحات المحتوى
  • قم بإعداد رؤوس ذاكرة التخزين المؤقت بشكل صحيح
  • فكر في الترحيل الكامل إلى إطار عمل حديث إذا كان WordPress هو الاختناق

إذا كنت تفكر في هذه النقطة الأخيرة — الترحيل الكامل — اتصل بنا. لقد فعلنا هذا النوع من المشروع عدة مرات. تحتوي صفحة التسعير على تفاصيل حول ما تتكلفه الترحيل headless عادة.

ماذا يعني Core Web Vitals 2026 لموقعك

غيّر تحديث Core الأساسي في مارس 2026 من Google اللعبة. لا تُقيّم CWV على كل صفحة — يتم تجميعها عبر مجالك بالكامل، مرجحة حسب حركة المرور. هذا يعني:

  • صفحة واحدة بطيئة من قالب يستخدم 200 منشور مدونة ستغرق درجات موقعك بالكامل
  • تحمل صفحات حركة المرور العالية وزناً أكبر في درجة التجميع
  • لا يمكنك فقط تحسين الصفحة الرئيسية والتوقف عند ذلك

تظهر البيانات المبكرة من الطرح أن المواقع ذات CWV الضعيفة شهدت انخفاضات في حركة المرور العضوية بنسبة 20-35%. شهد البعض خسائر تزيد عن 50%. كانت المواقع التي تعافت بأسرع الطريقة هي التي عالجت الأداء على مستوى البنية الأساسية — ليس بتعديل الصفحات الفردية، بل بإصلاح نظام التسليم الأساسي.

هذا بالضبط السبب في أن ترحيل SleepDr كان فعالاً جداً. لم نقم بتحسين 228 صفحة WordPress فردية. أعدنا بناء نظام التسليم بالكامل حتى تكون كل صفحة سريعة بشكل افتراضي.

بالنسبة للمواقع التي لم تكن جاهزة للترحيل الكامل، توفر أطر عمل مثل Astro مسار مقنع آخر — خاصة بالنسبة للمواقع الثقيلة من حيث المحتوى حيث تريد جافا سكريبت قريبة من الصفر بشكل افتراضي.

النهج التكلفة النموذجية الجدول الزمني مكسب Lighthouse المتوقع
تحسين مكون إضافي WordPress (WP Rocket, ShortPixel) $100-500/سنة أسبوع إلى أسبوعين +10-20 نقطة
استبدال سمة WordPress $2,000-5,000 أسبوعان إلى 4 أسابيع +15-25 نقطة
ترحيل headless CMS (Next.js/Astro) $15,000-50,000 4-10 أسابيع +30-60 نقطة
إعادة بناء منصة كاملة $30,000-100,000+ 8-20 أسبوع +40-65 نقطة

سقط مشروع SleepDr في نطاق $20,000-25,000 للترحيل الكامل، بما في ذلك نقل المحتوى من جميع 228 منشور، وإعداد CMS، والمكونات المخصصة، وتحسين الأداء. يتم تشغيل استضافة Vercel بسعر $20/شهر في خطة Pro. هذا تقريباً $740/سنة في الاستضافة مقابل $300/سنة التي كانوا يدفعونها مقابل الاستضافة المشتركة التي لم تتمكن من الاحتفاظ بـ TTFB تحت ثانيتين.

عائد الاستثمار؟ تعافت حركة المرور العضوية الخاصة بهم خلال 6 أسابيع وتجاوزت مستويات ما قبل الانخفاض بنسبة 10 أسابيع. بالنسبة للشركة التي تعتمد على البحث العضوي، فقد سدد الترحيل نفسه خلال الربع الأول.

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

كم من الوقت يستغرق تأثير تحسينات Core Web Vitals على تصنيفات Google؟ بناءً على تجربتنا مع SleepDr والمشاريع المماثلة، يبدأ Search Console في عرض بيانات CWV المحدثة خلال 28 يوماً من النشر. تتبع تحسينات التصنيف عادة بعد شهرين إلى ثلاثة أشهر. يحتاج Google إلى إعادة الزحف إلى صفحاتك، وجمع بيانات ميدانية جديدة من مستخدمي Chrome الفعليين (بيانات CrUX)، وتطبيق ذلك في خوارزميات التصنيف الخاصة به. لا تتوقع نتائج بين عشية وضحاها — لكن توقع تحسناً ملموساً خلال ربع سنة.

هل درجة Lighthouse البالغة 94 قابلة للتحقق فعلاً لموقع إنتاج حقيقي؟ نعم، لكنه يتطلب اختيارات معمارية مقصودة من البداية. درجات المختبر فوق 90 على الجوال قابلة للتحقق مع أطر عمل حديثة مثل Next.js أو Astro عندما تتحكم في نصوصك من الجهات الخارجية، وتحسن الصور بشكل صحيح، وتنشر على شبكة حافة. المفتاح هو أن كل مكون يجب أن يكون على دراية بالأداء. يمكن لـ embed واحد سيء أو عنصر واجهة مستخدم من جهة خارجية غير محسّن أن يرميك مرة أخرى إلى الـ 70s.

هل أحتاج إلى الهجرة بعيداً عن WordPress للحصول على درجات Core Web Vitals جيدة؟ ليس بالضرورة. يمكن بالفعل لمواقع WordPress أن تحقق درجات جيدة مع السمة الصحيحة، والتخزين المؤقت القوي (WP Rocket + Cloudflare)، والاستضافة المحسّنة (Kinsta, WP Engine)، والحد الأدنى من المكونات الإضافية. من الناحية الواقعية، معظم مواقع WordPress التي نقوم بتدقيقها تحقق درجات ما بين 30-60 على الجوال بسبب تراكم تضخيم المكونات الإضافية وعلى رأس السمة. إذا كنت أقل من 50، فمن المحتمل ألا يحصل تحسين المكون الإضافي وحده على أكثر من 75. نهج headless — حيث يعمل WordPress كواجهة برمجية للمحتوى بينما إطار عمل واجهة أمامية يتعامل مع العرض — غالباً ما يكون الحل الوسيط يستحق الاستكشاف.

ما الفرق بين درجات Lighthouse وبيانات Core Web Vitals الحقيقية؟ Lighthouse أداة اختبار — تحاكي هاتفاً من الفئة المتوسطة على اتصال 4G مقيد وتعطيك درجات اصطناعية. Core Web Vitals في Search Console هي بيانات ميدانية — قياسات فعلية من مستخدمي Chrome الفعليين الذين يزورون موقعك على مدى نافذة 28 يوماً متدحرجة. تستخدم Google بيانات الحقل للإشارات الترتيبية، وليس درجات المختبر. Lighthouse مفيد لتشخيص المشاكل واختبار الإصلاحات، لكن هدفك هو حالة CWV خضراء في Search Console بنسبة 75% المئوية.

ما الفرق بين الدقة العالية للمكون الإضافي WordPress والبيانات الميدانية الحقيقية؟ Lighthouse أداة معملية — فإنه يحاكي هاتفاً من الفئة المتوسطة على خنق 4G ويعطيك درجات اصطناعية. Core Web Vitals في Search Console هي بيانات ميدانية — قياسات فعلية من مستخدمي Chrome الفعليين الذين يزورون موقعك في نافذة دوارة 28 يوماً. تستخدم Google بيانات الحقل للإشارات الترتيبية، وليس درجات المختبر. Lighthouse مفيد لتشخيص المشاكل واختبار الإصلاحات، لكن هدفك هو حالة CWV خضراء في Search Console في المئوية 75.

ما أكثر تحسين واحد فعال لـ LCP؟ تحسين الصور. في حوالي 60% من المواقع التي نقوم بتدقيقها، عنصر LCP هو صورة. تحجيمها بشكل صحيح، وتقديمها بصيغة WebP/AVIF، وإضافة fetchpriority="high"، والتأكد من عدم تحميلها بكسل عادة ما يقلل LCP بمقدار 2-4 ثوان. على SleepDr، حساب تحسين الصور لوحده حوالي 3 ثوان من تحسين LCP.

كيف يعمل نظام تسجيل CWV الشامل لـ Google 2026؟ منذ تحديث Core الأساسي في مارس 2026، تجمع Google بيانات Core Web Vitals عبر مجالك بالكامل بدلاً من تقييم الصفحات بشكل فردي. تحمل صفحات حركة المرور العالية وزناً أكبر في الحساب. هذا يعني أن قالب أرشيف مدونة بطيء يُستخدم على مئات الصفحات سيسحب تصنيفات صفحتك الرئيسية أيضاً. الإصلاح هو معماري — تحتاج كل قالب صفحة إلى تمرير حدود CWV، وليس فقط صفحات الهبوط الرئيسية.

كم تكلف ترحيل WordPress إلى Next.js عادة؟ بالنسبة لموقع محتوى مشابه لـ SleepDr (200+ صفحة، تخطيط مدونة قياسي، نماذج اتصال، بدون تجارة إلكترونية)، توقع $15,000-30,000 من وكالة ذات خبرة. ترحيل التجارة الإلكترونية يعمل أعلى — $30,000-75,000+ حسب التعقيد. استضافة الاستمرار على Vercel Pro هي $20/شهر. عائد الاستثمار يعتمد على مقدار ما تستحقه حركة المرور العضوية لعملك، لكن بالنسبة للمواقع التي واجهت انخفاضات في الزيارات من ضعف CWV، عادة ما يسدد الترحيل نفسه خلال 3-6 أشهر.

هل يجب أن أركز على درجات Lighthouse للجوال أو سطح المكتب؟ الجوال. دائما الجوال أولاً. يستخدم Google الفهرسة التي تركز على الجوال أولاً، وتسجيل Lighthouse الجوال أكثر صرامة من سطح المكتب لأنه يحاكي جهاز مقيد وشبكة. إذا كانت درجة الجوال الخاصة بك 94، فمن المؤكد تقريباً أن درجة سطح المكتب الخاصة بك ستكون 95+. تطلبت درجة سطح المكتب من SleepDr البالغة 99 صفر عمل إضافي بعيداً عن تحسينات الجوال فقط.