How to Actually Make Your Website Fast

• لماذا انتقلنا من Laravel إلى Next.js
• كان أول تدقيق لنا باستخدام Lighthouse على Next.js متواضعاً
• كيف قمنا بتقليل حجم حزمة JavaScript من خلال إدارة أفضل للسكربتات
• تحسين الصور في Next.js: WebP، CDN، وخصائص الأولوية
• استراتيجية العرض في 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 > أو يمكن تأجيله. تم التحقق من كل استيراد كبير مقابل الاستخدام الفعلي.

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

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

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

تحسين الصور في Next.js: WebP، CDN، وخصائص الأولوية

تحسين الصور في Next.js — بما في ذلك تحويل الصيغ، تسليم CDN، وخصائص الأولوية، كان العنصر الأكثر تكلفة في أي صفحة، وقد أخطأنا فيه أكثر من مرة. الجميع يوافق على تحسين الصور ثم يعودون إلى تحميل 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. يقوم الإطار بتحميل الصور بشكل كسول افتراضيًا، وهو السلوك الصحيح للصور أسفل الطية. لكن عنصر Largest Contentful Paint (تقريبًا دائمًا صورة البطل) لا ينبغي أبدًا تحميله بشكل كسول. إضافة priority تخبر Next.js بتحميل تلك الصورة مسبقًا والتوقف عن معاملتها كمحتوى اختياري. إنها خاصية واحدة. التحسين في LCP فوري وقابل للقياس.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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