كيفية جعل موقع الويب الخاص بك سريعًا بالفعل

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

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

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

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

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

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