كيف تجعل موقعك أسرع: قائمة عملية

لجعل موقع أسرع، قِسه أولا باستخدام PageSpeed Insights، ثم أصلح أكبر سبب يشير إليه، وغالبا ما يكون صورا كبيرة الحجم أو JavaScript زائدا أو خطوطا ثقيلة أو سكربتات خارجية. استهدف أهداف Core Web Vitals «الجيدة» من Google: ظهور المحتوى الرئيسي خلال 2.5 ثانية، والرد على النقرات خلال 200 ملي ثانية، وشبه انعدام القفز في التخطيط. ومعظم المواقع تصل إلى ذلك بعدد قليل من التغييرات، لا بإعادة كتابة كاملة.

قِس قبل أن تغيّر أي شيء

التخمين يضيّع الوقت. تغطي أداتان مجانيتان معظم الحالات:

• PageSpeed Insights (pagespeed.web.dev) — ألصق رابطا حيا. يعرض البيانات الميدانية من مستخدمي Chrome الحقيقيين (إذا كان لموقعك حركة كافية)، والبيانات المخبرية من تحميل محاكى، إضافة إلى قائمة بمشكلات محددة.
• Lighthouse في أدوات مطور Chrome — الاختبار المخبري نفسه، ويعمل على أي صفحة يمكنك فتحها، بما في ذلك المعاينة. اختبر في الوضع المحمول؛ فالهواتف على شبكات أبطأ هي المكان الذي تظهر فيه المشكلات.

الأرقام المهمة هي Core Web Vitals من Google. واعتبارا من سبتمبر 2026، تعطي وثائق Google على web.dev عتبات «جيدة» التالية، مقاسة عند الشريحة 75 من تحميلات الصفحة:

حل INP محل مقياس First Input Delay القديم في 2024. فإذا ما زالت أداة تعرض FID فهي قديمة.

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

أين يذهب الوقت: الخيارات والمقايضات

لكل سبب شائع حل، ولكل حل كلفة. ابدأ بالأسباب الموجودة في الأعلى، فهي الأرخص والأكثر شيوعا.

الصور

الصور هي المشكلة الأكثر شيوعا وأسهلها في الإصلاح. صورة بعرض 4,000 بكسل تُعرض بعرض 800 بكسل تجبر كل زائر على تنزيل خمسة أضعاف ما يراه.

• قدّم الصور بالحجم الذي تُعرض به، مع أحجام srcset متجاوبة للهواتف والحاسوب.
• استخدم صيغا حديثة (WebP أو AVIF) وضغطا معقولا.
• ضع width وheight لكل صورة حتى يحجز المتصفح المساحة. وهذا وحده يحل معظم انزياح التخطيط.
• حمّل الصور الواقعة تحت الخط المرئي الأول بالتحميل الكسول باستخدام loading="lazy".
• لا تحمّل صورة البطل الرئيسية في أعلى الصفحة بشكل كسول. إرشادات Google لـ LCP واضحة في هذا: التحميل الكسول لصورة LCP يؤخرها دائما. أعطها fetchpriority="high" بدلا من ذلك.

JavaScript

كثير من المواقع المبنية بالذكاء الاصطناعي تطبيقات صفحة واحدة (SPA): يحمّل المتصفح حزمة JavaScript ثم يرسم الصفحة. وكلما كبرت الحزمة طال الشاشة البيضاء. والإصلاحات، مرتبة حسب الجهد:

1. أزل ما لا تستخدمه. اطلب قائمة بالتبعيات، واحذف المكتبات التي أُضيفت مرة ونُسيت — مكتبة تاريخ لتاريخ واحد، أو حزمة أيقونات كاملة لخمس أيقونات.
2. قسّمها حسب المسار. حمّل كود لوحة الإدارة فقط عندما يفتحها أحد، لا في الصفحة الرئيسية.
3. جهّز الصفحات العامة مسبقا. صفحة تسويقية تُقدَّم كـHTML حقيقي تظهر قبل تشغيل أي JavaScript. وهذا يساعد محركات البحث أيضا؛ راجع تحسين محركات البحث للمواقع المبنية بالذكاء الاصطناعي.

بطء INP يعني عادة مهمة طويلة واحدة تعطل الصفحة، كتصفية قائمة ضخمة مع كل ضغطة مفتاح، أو إعادة رسم جدول كامل عند تغيير خلية واحدة. ولوحة Performance في أدوات مطور Chrome تُظهر أيّ منهما.

الخطوط

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

السكربتات الخارجية

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

استجابة الخادم

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

أوامر تعمل جيدا

كن محددا: اذكر الصفحة والمقياس والقيد. وألصق نتائج PageSpeed Insights إن توفرت.

يُظهر PageSpeed Insights أن LCP للصفحة الرئيسية على الهاتف 4.8 ثانية، وعنصر LCP هو صورة البطل. صغّر صورة البطل وحوّلها إلى WebP، وقدّم أحجاما متجاوبة، واضبط width وheight، وأعطها fetchpriority="high" وتأكد أنها ليست محملة بشكل كسول. حمّل كل الصور الواقعة تحت الخط المرئي الأول بشكل كسول. لا تغيّر التصميم.

دقق تبعيات هذا التطبيق. اذكر كل حزمة، وما الذي يستخدمها، وكم تضيف تقريبا إلى الحزمة. أزل غير المستخدم، وقسّم مساري /admin و/settings إلى أجزاء منفصلة لا تُحمَّل إلا عند زيارتها.

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

خطوة بخطوة

1. اختبر الصفحة الحية في PageSpeed Insights على الهاتف. دوّن LCP وINP وCLS وأهم ثلاث مشكلات مذكورة.
2. أصلح الصور أولا: الأحجام والصيغ والأبعاد والتحميل الكسول تحت الخط المرئي الأول، وأولوية لصورة البطل.
3. قلّل السكربتات الخارجية التي لا تستخدمها، وأجّل الباقي.
4. قلّص الخطوط إلى ما يحتاجه التصميم.
5. صغّر JavaScript: أزل الحزم غير المستخدمة، وقسّم حسب المسار.
6. جهّز الصفحات العامة مسبقا إذا كانت ما زالت تُعرض من جانب العميل وLCP ما زال بطيئا.
7. تحقق من الخادم: التخزين المؤقت، وفهارس قاعدة البيانات، والاستضافة الثابتة للمحتوى الذي يتغير نادرا.
8. انشر من جديد وأعد الاختبار. تتحدث البيانات الميدانية في PageSpeed Insights خلال الأسابيع التالية مع تدفق الزيارات الحقيقية، لذا احكم على النتائج المبكرة بالبيانات المخبرية.

أخطاء شائعة

• الاختبار على حاسوب محمول سريع فقط. زوارك على هواتف متوسطة وبيانات جوال متقطعة. اختبر في الوضع المحمول.
• مطاردة درجة 100 كاملة. النتيجة المخبرية دليل إرشادي. عندما تصل Core Web Vitals إلى النطاق الجيد، يصبح المحتوى وسهولة الاستخدام أهم من النقاط الأخيرة.
• التحميل الكسول لكل شيء، بما في ذلك صورة البطل. وهذا يُسيء إلى LCP.
• إضافة أداة تسريع أو مكتبة فوق الموجود. إزالة الوزن تتفوق دائما على إضافة كود لإدارته.
• تحسين المعاينة لا الموقع الحي. تعمل المعاينات التطويرية ببناءات غير محسّنة. قِس الرابط المنشور.
• إصلاح السرعة مرة واحدة. كل أداة جديدة وصورة وميزة تضيف وزنا. أعد الاختبار بعد التغييرات الكبيرة.

قائمة السرعة

• LCP ≤ 2.5 ثانية، وINP ≤ 200 ملي ثانية، وCLS ≤ 0.1 على الهاتف
• الصور مصغرة ومضغوطة بصيغة حديثة، مع width وheight
• صورة البطل غير محملة بشكل كسول؛ والصور تحت الخط المرئي الأول محملة بشكل كسول
• لا توجد مكتبات JavaScript غير مستخدمة؛ والمسارات الثقيلة مفصولة
• عائلتا خطوط أو أقل، والخط الرئيسي محمّل مسبقا
• السكربتات الخارجية التي تستخدمها فقط، ومحمّلة متأخرا
• الصفحات العامة مجهزة مسبقا أو ثابتة حيثما أمكن
• أُعيد الاختبار على الرابط الحي بعد النشر

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

السرعة في Mythex

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

الأسئلة