SleepDr: من WordPress إلى Next.js — كيف حققنا 94 من أصل 100 في Lighthouse

في الربع الماضي، تولينا مشروعاً يوضح بشكل مثالي لماذا WordPress ليس دائماً الأداة المناسبة للعمل. SleepDr.com — موقع محتوى صحة النوم يضم 228 منشور مدونة، نموذج اتصال، وسجل Lighthouse للهاتف المحمول بقيمة 35 — جاء إلينا يطلب المساعدة بشدة للحصول على السرعة. كان حركة المرور العضوية الخاصة بهم تنخفض لعدة أشهر. تحديث Google Core الأساسي في مارس 2026، الذي قدم تقييم Core Web Vitals الشامل على مستوى الموقع، ضربهم بقوة. كان كل منشور مدونة بطيء يسحب الموقع بأكمله للأسفل.

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

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

SleepDr Case Study: WordPress to Next.js Migration (Lighthouse 35→94)

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

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

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

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

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

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

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

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

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

  • Next.js 15 (App Router): عرض هجين. الإنشاء الثابت لمنشورات المدونة، والعرض من جانب الخادم عند الحاجة. React Server Components لتقليل JavaScript من جانب العميل. هذا هو خبزنا وزبدتنا — لقد بنينا العشرات من المشاريع عليها من خلال ممارسة تطوير Next.js.
  • Payload CMS 3: نظام إدارة محتوى بدون رأس ذاتي الاستضافة أعطى فريق محتوى SleepDr نفس تجربة التحرير التي اعتادوا عليها مع WordPress، بدون الكثير من الأشياء الزائدة. نتعامل مع الكثير من تطبيقات 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 Case Study: WordPress to Next.js Migration (Lighthouse 35→94) - architecture

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

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

ماذا فعلنا

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

import Image from 'next/image';

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

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

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

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

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

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

صورة CDN

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

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

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

قام موضوع WordPress في SleepDr بتحميل ثلاث خطوط Google عبر روابط ورقة أنماط خارجية. كل واحد كان طلب حظر العرض إلى 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 بشكل مختلف:

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

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

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

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

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

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

قام الموقع WordPress بتحميل:

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

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

ماذا فعلنا

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

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

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

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

import dynamic from 'next/dynamic';

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

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

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

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

التأثير الصافي: انخفض TBT من 1,200ms إلى 50ms. الخيط الرئيسي حر بشكل أساسي.

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

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

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

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

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

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

ماذا فعلنا

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

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

// 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 على Vercel's Edge Functions يعمل في أقل من 100ms لأن الحساب يحدث على الحافة، وليس في مركز بيانات مركزي.

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

التحسين 5: إدارة السكريبتات من جهات خارجية

السكريبتات من جهات خارجية هي القاتلون الصامتون لأداء الويب. قام موقع SleepDr في WordPress بتحميل Google Analytics (GA4)، وGoogle Tag Manager، وبكسل Facebook، وسكريبت تسجيل Hotjar، ومدير الموافقة على الملفات الشخصية — كلها حظر العرض في <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 (مضغوطة gzip: ~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 حظر العرض. يتم الجمع بين مخرجات 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 deployment
  • تطبيق الإنشاء الثابت لصفحات المحتوى
  • إعداد رؤوس الذاكرة المؤقتة المناسبة
  • فكر في ترحيل كامل إلى إطار عمل حديث إذا كان WordPress هو الاختناق

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

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

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

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

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

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

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

الأسلوب التكلفة النموذجية الجدول الزمني كسب Lighthouse المتوقع
تحسين مكون WordPress الإضافي (WP Rocket, ShortPixel) $100-500/yr 1-2 أسابيع +10-20 نقطة
استبدال موضوع WordPress $2,000-5,000 2-4 أسابيع +15-25 نقطة
ترحيل 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 عندما تتحكم في السكريبتات من جهات خارجية، وتحسّن الصور بشكل صحيح، والنشر على شبكة حافة. المفتاح هو أن كل مكون يجب أن يكون على دراية بالأداء. يمكن لتضمين سيء واحد أو سكريبت من جهة خارجية غير محسّن أن يضربك مرة أخرى إلى 70.

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

ما الفرق بين درجات Lighthouse وبيانات Core Web Vitals الحقيقية؟ 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.

كيف يعمل تقييم Core Web Vitals الشامل لـ Google في 2026؟ منذ تحديث Google 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+. لم تتطلب درجة سطح المكتب 99 لـ SleepDr أي عمل إضافي تجاوز ما فعلناه لتحسين الهاتف المحمول.