كيف تسرّع موقع الويب الخاص بك حقًا

• لماذا انتقلنا من Laravel إلى Next.js؟
• أول تدقيق Lighthouse في Next.js كان درسًا لنا
• كيف قللنا حجم حزمة JavaScript بإدارة أفضل للسكربتات؟
• تحسين الصور في Next.js: WebP، CDN وميزة Priority
• استراتيجية العرض في Next.js: الإنتاج الثابت، ISR والعرض الديناميكي
• البيانات المهيكلة لـ SEO، hreflang وOpenGraph في Next.js
• النتائج: درجة Lighthouse فوق 90، LCP تحت 2.5 ثانية، TTFB تحت 100 مللي ثانية

الجميع يريد موقع ويب سريع، لكن لكل موقع رحلة مختلفة. هذه تجربتنا، منطقنا، رحلتنا ونتائجنا. هنا ما فعلناه لتسريع موقعنا في عام 2026.

إذا كنت ترغب في الحصول على نصائح أكثر تخصيصًا لموقع الويب الخاص بك، انضم إلى مجتمعنا.

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

ما حدث فعليًا هو أننا استلمنا قاعدة كود متنامية، وأجرينا أول تدقيق Lighthouse منذ فترة طويلة، ورأينا درجة 34 على الهاتف المحمول، وأجرينا محادثة طويلة ومزعجة حول كيفية وصولنا إلى هناك.

لماذا انتقلنا من Laravel إلى Next.js؟

لم يكن الانتقال من Laravel إلى Next.js هو غريزتنا الأولى، لكنه أصبح الخيار الأكثر وضوحًا بمرور الوقت. بدأ موقعنا التسويقي كتطبيق Laravel. قوالب Blade، HTML منشأ من جانب الخادم، وبعض jQuery. كان ذلك معقولًا تمامًا لمقياسنا في ذلك الوقت. ولكن مع نمو المنتج؛ وظهور احتياجات مثل دعم لغات متعددة، صفحات تسعير تجلب بيانات حية، مدونة تتلقى حركة مرور حقيقية، وتدفقات مصادقة معقدة، تحول الحل الذي كان "معقولًا تمامًا" إلى "بنية مكلفة بصمت".

لم تكن المشكلة في الأداء. كانت المشكلة في السرعة. كل تغيير في الواجهة الأمامية كان يتطلب لمس PHP. حتى تعديل النص كان يتطلب نشرًا في الخلفية. إضافة قسم جديد للصفحة كان يعني تدفق البيانات من خلال المتحكمات، مؤلفي العرض، وصولاً إلى ملفات Blade. الأشخاص الذين يجب أن يمتلكوا الواجهة الأمامية (المصممون، المسوقون، فريق الإنتاج) لم يتمكنوا من لمسها دون تدخل المهندس.

انتقلنا إلى Next.js 15 مع App Router. ليس لأنه كان الطريق الأسهل، ولكن لأنه قدم لنا كل شيء تحت سقف واحد مثل العرض من جانب الخادم، الإنتاج الثابت، إعادة التحقق التدريجي ونموذج المكونات السلس. كان القرار صحيحًا. لكن التطبيق لا يزال به بعض العيوب التي نحاول إصلاحها.

أول تدقيق Lighthouse في Next.js كان درسًا لنا

أول تدقيق Lighthouse أجريناه على موقعنا الجديد في Next.js لم يجلب التحسن المتوقع. عندما أطلقنا الموقع الجديد لأول مرة، كنا نتوقع تحسنًا مقارنة بـ Laravel. لم يحدث ذلك على الفور، على الأقل ليس فورًا.

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

أدركنا أن أول شيء يبطئ موقعنا هو الموارد التي تعيق العرض. لم تكن JavaScript، كنا حذرين بشأن ذلك. كانت المشكلة أكثر دقة: لم يكن هناك تلميح للمتصفح على النطاقات الخارجية التي كنا نجلب منها البيانات. كانت صورنا تعيش على "$static.plusclouds.com$". كان API الخاص بنا هو "$apiv4.plusclouds.com$". لم يكن لأي منهما تلميح preconnect في رأس الوثيقة. لذا مع كل تحميل صفحة، كان المتصفح يحلل HTML، يرى طلبًا إلى نطاق خارجي، ثم يبدأ في حل DNS ومصافحة TCP من الصفر.

إضافة سطرين إلى التخطيط الجذري أصلح ذلك:

<link rel="preconnect" href="https://static.plusclouds.com" />
<link rel="preconnect" href="https://apiv4.plusclouds.com" />

يبدو الأمر بسيطًا للغاية. لكن تلميحات preconnect هي من تلك الأشياء التي تتزايد تكلفة عدم وجودها مع كل تحميل صفحة، لكل زائر. الآن يبدأ المتصفح في إنشاء هذه الاتصالات قبل أن يطلب أول صورة أو API استدعاء. لذا، إذا كنت ترغب في تسريع موقعك، فإن تلميحات preconnect هي شيء يجب الانتباه إليه.

كيف قللنا حجم حزمة JavaScript بإدارة أفضل للسكربتات

تقليل حجم حزمة JavaScript بإدارة أفضل للسكربتات كان من المكاسب الصامتة ولكن الأكثر فعالية في انتقالنا. في فترة Laravel، تراكمت السكربتات بشكل عضوي. هنا أداة تحليل، هناك ويدجت دردشة، بكسل طرف ثالث تمت إضافته خلال حملة تسويقية ولم يتم إزالته أبدًا. تم إضافة كل منها كعلامة سكربت متزامنة أو مؤجلة، وكان ترتيب إضافتها يعكس ترتيب إطلاق الميزات؛ لم يتم التفكير كثيرًا في ما تحتاجه الصفحة بالفعل.

عندما انتقلنا إلى Next.js، حملنا بعض هذه العادات مع إدارة أفضل للسكربتات. مكون يستخدم أيقونتين كان يستورد مكتبة الأيقونات بالكامل. كانت الوظائف المساعدة التي تحتاجها فقط فرع معين مستوردة في أعلى الملف. كان لدينا مكونات عميل تم وضع علامة عليها بـ 'use client' فقط لأن شخصًا ما لم يكن متأكدًا.

كل منها عناصر صغيرة. لكن في المجموع، يشكلون حزمة JavaScript أكبر بشكل ملحوظ. قمنا بمراجعة قاعدة الكود بشكل منهجي: تم تقييم كل سكربت طرف ثالث لمعرفة ما إذا كان يجب أن يكون في < head > أو يمكن تأجيله. تم فحص كل استيراد كبير بناءً على استخدامه الفعلي.

تم تحويل المكونات التي لا تحتاج إلى API المتصفح مرة أخرى إلى مكونات الخادم. انخفض حجم الحزمة ومعه، قل وقت تفاعل الصفحة.

القاعدة التي اعتمدناها لحزمة السكربت لجعل الموقع أسرع هي: لا يتم استيراد أي شيء حتى يتم الحاجة إليه، لا يعمل أي شيء يمكن تشغيله على الخادم في المتصفح، ولا يتم تحميل أي شيء في < head > ما لم يكن يعيق العرض المرئي.

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

تحسين الصور في Next.js: WebP، CDN وميزة Priority

تحسين الصور في Next.js — بما في ذلك تحويل الصيغ، التسليم عبر CDN وميزة priority — كان العنصر الأكثر تكلفة في أي صفحة، وقد فعلنا ذلك بشكل خاطئ عدة مرات. الجميع يهز رأسه لتحسين الصور ولكن بعد ذلك يذهب لتحميل JPEG بحجم 3.7 ميجابايت مباشرة من Figma. فعلنا ذلك بالضبط. بل عدة مرات.

التحميل الخاص الذي أنشأناه يوجه كل حركة الإنتاج عبر imgproxy في CDN الخاص بنا. يتم تغيير حجم كل صورة إلى الأبعاد المطلوبة حقًا، ويتم تقديمها بالتنسيق المناسب للمتصفح الطالب، ويتم تخزينها مؤقتًا عند الحافة. لم يعد الزائر الذي لديه شاشة 390 بكسل يقوم بتنزيل إصدار 1600 بكسل من نفس الصورة. يتعامل المحمل مع كل ذلك بشفافية؛ يكتب المطور علامة < Image > عادية وCDN يتولى الباقي.

لكن تحويل الصيغ مشكلة منفصلة عن التسليم. JPEG الذي يتم تقديمه من CDN سريع لا يزال JPEG. تحويل خلفيات الأبطال والصور التسويقية الكبيرة إلى WebP يقلل من أحجام الملفات بنسبة 60% إلى 80%. كان لدينا PNG بحجم 1.3 ميجابايت في بطل الصفحة الرئيسية ولم نلاحظه حتى أشار إليه Lighthouse في أربعة تدقيقات متتالية. كان يجب أن تكون تلك الصورة حوالي 200 كيلوبايت في WebP. لا يمكن لـ CDN إصلاح ذلك؛ فقط تحويل ملف المصدر يمكنه تحقيق ذلك.

شيء آخر فعلناه بشكل خاطئ لفترة طويلة: ميزة priority في صور Next.js. يقوم الإطار بتحميل الصور بشكل افتراضي بشكل متأخر؛ هذا هو السلوك الصحيح للصور الموجودة أسفل الصفحة. لكن أكبر طلاء محتوى (عادةً صورة البطل) لا يجب أن يتم تحميله بشكل متأخر أبدًا. إضافة priority تخبر Next.js بتحميل تلك الصورة مسبقًا وعدم التعامل معها كمحتوى اختياري. مجرد ميزة واحدة. التحسن في LCP فوري وقابل للقياس.

استراتيجية العرض في Next.js: الإنتاج الثابت، ISR والعرض الديناميكي

اختيار استراتيجية العرض الصحيحة في Next.js (الإنتاج الثابت، ISR أو العرض الديناميكي) هو أحد أهم القرارات المعمارية في الإطار وله نتائج أداء حقيقية.

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

صفحات منتجاتنا (ميزات الخادم، مستويات التسعير، توثيق الميزات) لا تتغير كل دقيقة. نحن الآن نستخدم generateStaticParams مع ISR ونافذة إعادة التحقق لمدة ساعة. يتم عرضها مسبقًا كـ HTML ثابت لكل مجموعة لغات في وقت البناء. عندما يدخل مستخدم إلى صفحة منتج، يتم تقديم ملف مخزن مؤقتًا من الحافة في أقل من 100 مللي ثانية. لا يوجد خادم، لا يوجد استعلام قاعدة بيانات، لا يستيقظ عملية Node.js.

الصفحات التي تتطلب بيانات حديثة (الصفحة الرئيسية للمدونة، التسعير الحي، أي شيء مخصص للمستخدم) تستخدم العرض الديناميكي مع نوافذ إعادة تحقق قصيرة أو تخزين مؤقت على مستوى المكونات. النتيجة هي أن الغالبية العظمى من حركتنا يتم تقديمها من HTML ثابت والخادم يقوم بالعمل الحقيقي فقط عندما يتغير المحتوى بالفعل.

في معظم الصفحات، TTFB الآن أقل من 100 مللي ثانية بشكل ثابت. في إعداد Laravel القديم، نادرًا ما كان ينخفض عن 400 مللي ثانية. هذا ليس سحرًا من الإطار؛ إنه نتيجة لاتخاذ قرارات واعية حول استراتيجية العرض التي منطقية لكل صفحة.

البيانات المهيكلة لـ SEO، علامات hreflang وبيانات OpenGraph الوصفية غير مرئية للمستخدمين ولكنها مهمة لكل شيء وكانت شبه معدومة عندما انتقلنا. تحسين ميزات الذكاء الاصطناعي التوليدية من Google يتطلب محتوى جيد التنظيم وقابل للفهرسة مع علامات شيماء مناسبة.

أضفنا JSON-LD لصفحات FAQPage إلى صفحات المنتجات والميزات. استخدمنا شيماء SoftwareApplication لأدواتنا. أضفنا BreadcrumbList للتسلسل الهرمي للتنقل. يحتوي ملف التخطيط الرئيسي على شيماء Organization. هذه تُقرأ بواسطة محركات البحث والأنظمة الذكية التي تقرر ما إذا كانت ستعرض المحتوى الخاص بك في الملخصات المولدة وصناديق الإجابات.

كان وضع hreflang أكثر تعقيدًا. نحن ندعم أربع لغات محلية وكانت الروابط البديلة لدينا غير متسقة في أفضل الأحوال، وغير موجودة في أسوأ الأحوال. أنشأنا دالة مشتركة buildAlternates() التي تولد العلامات hreflang الصحيحة من وسيطة مسار واحدة وتعمل على كل صفحة. هذا هو نوع الشيء الذي يبدو وكأنه عمل منزلي حتى تدرك أن العلامات hreflang الخاطئة أو المفقودة تضر بأداء البحث الدولي الخاص بك بنشاط.

كانت بيانات OpenGraph الوصفية مشابهة، كانت موجودة في بعض الصفحات وغير موجودة في أخرى، وكانت أبعاد الصور غير متسقة. مركزية ذلك عبر API generateMetadata في Next.js وإضافة metadataBase إلى التخطيط الجذري سمح لنا بالتوقف عن التفكير على مستوى الصفحة والقيام بذلك بشكل صحيح افتراضيًا في كل مكان.

النتائج: درجة Lighthouse فوق 90، LCP تحت 2.5 ثانية، TTFB تحت 100 مللي ثانية

بعد الانتقال، درجة Lighthouse على الهاتف المحمول لدينا باستمرار فوق 90. CLS أقل من 0.05. LCP أقل من 2.5 ثانية في معظم الصفحات. TTFB للمحتوى الذي يتم تقديمه بشكل ثابت أقل من 100 مللي ثانية.

لم ينته الأمر بعد. لا تزال هناك صور يجب أن تكون WebP ولكنها ليست كذلك، صفحات يتم عرضها ديناميكيًا بينما يمكن إنتاجها بشكل ثابت، وبيانات مهيكلة يمكن أن تكون أكثر تحديدًا. القائمة أقصر مما كانت عليه، لكنها لا تصل أبدًا إلى الصفر.

الدرس الصادق المستخلص من كل هذا هو: الأداء ليس مشروعًا تنتهي منه، بل هو مجموعة من الافتراضات التي تبنيها. كل صورة بطل في PR قبل الدمج تحتوي على priority. كل نطاق خارجي جديد يضاف في اليوم الذي يتم فيه إضافة preconnect. يتم كتابة البيانات المهيكلة مع محتوى الصفحة، وليس إضافتها لاحقًا. يتم فحص الاستيرادات قبل أن تصبح عبء الحزمة.

عندما تصبح هذه عادات، تتوقف عن قضاء السبرينتات في تصحيح القرارات المتراكمة وتبدأ في الإرسال بسرعة افتراضيًا.

إذا كنت ترغب في الحصول على نصائح أكثر تخصيصًا لموقع الويب الخاص بك، انضم إلى مجتمعنا.

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

::cta:altyapı::