07 يوليو 2025·5 دقيقة
سرعة الموقع للمبتدئين: ما الذي يحسّن فعلاً زمن التحميل؟
دليل مبسط للمبتدئين يشرح ما يحسّن فعلاً زمن تحميل الموقع: الصور، التخزين المؤقت، الاستضافة، الكود، وCore Web Vitals—مع نصائح سريعة للبدء.
دليل مبسط للمبتدئين يشرح ما يحسّن فعلاً زمن تحميل الموقع: الصور، التخزين المؤقت، الاستضافة، الكود، وCore Web Vitals—مع نصائح سريعة للبدء.
عندما يقول الناس "موقعي بطيء"، فعادةً يقصدون أحد أمرين:
"زمن التحميل" ليس رقماً واحداً على ساعة توقيت. الصفحة تُحمّل على مراحل: المتصفح يطلب ملفات (HTML، صور، خطوط، سكربتات)، ينزلها، ثم يحولها إلى صفحة قابلة للاستخدام. يمكنك تخيلها كفتح متجر: فتح القفل، تشغيل الأنوار، ترتيب الرفوف، ثم الاستعداد لخدمة العملاء.
السرعة تؤثر على:
لا تحتاج إلى 50 تحسينًا صغيرًا. لمعظم المواقع المبتدئة، أكبر التحسينات تأتي من قائمة قصيرة: الصور، جافاسكربت/CSS الزائدان، الودجتات من طرف ثالث، وزمن استجابة الخادم/الاستضافة.
يركز هذا الدليل على خطوات عملية ومنخفضة المخاطر التي تحسّن زمن تحميل الصفحة في العالم الحقيقي، خصوصًا على الجوال. لن نتعمق في مواضيع متقدمة مثل إعادة كتابة معمارية التطبيق، بناء طبقات تخزين مؤقت مخصصة، أو وضع ميزانية للأداء لفرق هندسية كبيرة. الهدف: مساعدتك على إجراء تغييرات يمكنك إتمامها والتحقق منها دون كسر الموقع.
عندما يقول الناس "موقعي بطيء"، فعادةً يقصدون أحد ثلاثة أشياء: المحتوى الرئيسي يظهر متأخرًا، الصفحة تشعر بالخمول عند التفاعل، أو التخطيط يستمر في القفز. تقيس Core Web Vitals هذه الشكاوى بدقة.
LCP (Largest Contentful Paint): المدة الزمنية حتى يظهر أكبر عنصر "رئيسي" (غالبًا صورة البطل أو كتلة العنوان). إذا كان LCP مرتفعًا، ينظر المستخدم إلى صفحة فارغة طويلاً.
INP (Interaction to Next Paint): مدى سرعة استجابة الصفحة بعد تفاعل المستخدم (لمس، نقرة، كتابة). إذا كان INP مرتفعًا، يشعر الموقع بالثقل—الأزرار تتأخر، القوائم تفتح بتأخير.
CLS (Cumulative Layout Shift): مدى قفز الصفحة أثناء التحميل. إذا تغيرت مواضع النصوص وضغطت زرًا بالخطأ، هذا CLS.
TTFB (Time to First Byte) هو المدة حتى يبدأ الخادم (وكل ما بينه وبين المستخدم) بإرسال أي شيء. TTFB البطيء يؤخر كل شيء آخر: الصور لا تبدأ بالتنزيل، الخطوط لا تُحمّل، وLCP يتأثر عادةً. مشكلات TTFB غالبًا ما تشير إلى الاستضافة، عمل باك-إند ثقيل، أو تخطي التخزين المؤقت.
اختبارات المختبر (مثل Lighthouse) تحاكي تحميل الصفحة في ظروف محددة. مفيدة جدًا للتشخيص والمقارنات قبل/بعد.
بيانات المستخدم الحقيقية (المعروفة أحيانًا ببيانات الحقل، مثل CrUX في PageSpeed Insights) تعكس ما يختبره الزوار فعلًا عبر أجهزة وشبكات مختلفة. هذه هي الأهم عندما تسأل: "هل يشعر الناس أنها سريعة في الواقع؟"
إذا بدأت في "التحسين" بدون خط أساس، فمن السهل إضاعة الوقت—أو جعل الموقع أبطأ عن طريق الخطأ. خُذ 20 دقيقة للقياس أولًا، ثم ستعرف ما الذي ساعد.
استخدم PageSpeed Insights لمحة سريعة. يعرض بيانات الحقل (تجربة المستخدم الحقيقية، عندما تتوفر) وبيانات المختبر. انتبه لـ:
لاختبارات مختبرية أعمق، شغّل Lighthouse في Chrome:
عندما تحتاج أن ترى ما الذي يؤخر الصفحة، يعد WebPageTest من أوضح الأدوات. عرض الواترفول يظهر كل ملف يُحمّل بالترتيب—HTML، صور، خطوط، سكربتات، وعلامات الطرف الثالث—ومتى ينتظر المتصفح.
ابدأ بصفحة رئيسية أو صفحة هبوط رئيسية واختبر:
دوّن لكل اختبار:
اصنع سجلًا صغيرًا (ورقة عمل تكفي): التاريخ، الأداة، الـ URL، النتائج، وما تغيّر. غيّر شيئًا أو شيئين فقط في كل مرة، ثم أعد الاختبار بنفس الشروط.
إذا كنت تعمل على تطبيق وليس مجرد موقع ثابت، فوجود طريقة آمنة للنشر والتراجع عن تجارب الأداء يساعد. منصات مثل Koder.ai (التي يمكنها توليد واستضافة تطبيقات React/Go من سير عمل دردشة) مفيدة لأنها تتيح أخذ لقطات، اختبار التغييرات، والتراجع بسرعة إذا كسر "تحسين السرعة" تجربة المستخدم.
الصفحات البطيئة عادةً لا ترجع إلى مشكلة غامضة واحدة. هي نتيجة تراكم بعض مشاكل "الوزن والتأخير"—خاصة على الجوال.
الصور غالبًا تكون أثقل جزء في الصفحة. صورة بطل واحدة مُصدّرة بالحجم الخاطئ (أو بصيغة قديمة) يمكن أن تضيف ميغابايت وثوانٍ.
المذنبون الشائعون:
جافاسكربت يمكن أن تؤخر مدى سرعة الصفحة لتصبح قابلة للاستخدام. حتى إن ظهرت الصفحة "محملة" فقد تشعر بالخمول بينما تُحمّل السكربتات وتُنفّذ.
سكريبتات الطرف الثالث غالبًا ما تكون المخطئة: ويدجتات الدردشة، النوافذ المنبثقة، خرائط الحرارة، أدوات الاختبار A/B، علامات الإعلانات، وتضمينات الشبكات الاجتماعية. كلٌ منها يضيف طلبات شبكة ويمكن أن يؤخر العمل الحيوي للمتصفح.
أحيانًا المتصفح ينتظر الخادم قبل أن يبدأ بتحميل الصفحة. يُشعر بهذا كاستجابة أولية بطيئة (TTFB). الأسباب: استضافة ضعيفة، قواعد بيانات مشغولة، سمات/ملحقات غير مُحسّنة، أو صفحات تُبنى ديناميكيًا عند كل زيارة.
إذا يجبر موقعك كل زيارة على البدء من الصفر، فإن الزوار المتكررين يعاقَبون. بدون تخزين مؤقت، يُعاد بناء الصفحات ويتنزل المتصفح ملفات تتغير نادرًا.
أيضًا، الكثير من الملفات الصغيرة (خطوط، سكربتات، أنماط، متتبعات) يُنشئ "تكلفة طلب". حتى إن كانت كل ملف صغير، التراكم يجعل الوقت الإجمالي كبيرًا.
الخبر الجيد: هذه الأسباب قابلة للإصلاح—وعادةً تحصل على أكبر المكاسب بمعالجتها بهذا الترتيب.
إذا طبّقت تحسين واحد فقط، فاجعله على الصور. في كثيرٍ من المواقع المبتدئة، تمثل الصور معظم "وزن" الصفحة—خصوصًا على الجوال. والخبر الأفضل: إصلاحات الصور عادةً آمنة وسريعة ولا تتطلب تغيير التصميم.
خطأ شائع رفع صورة ضخمة (مثلاً 4000px عرض) وعرضها عند 800px. المتصفح لا يزال ينزل الملف الكبير.
صدّر الصور قرب الحد الأقصى لحجم العرض الذي ستظهر به فعليًا. إن كانت مساحة المحتوى 800px، لا ترفع صورًا 3000–4000px "للاحتياط".
JPEG وPNG ما زالا يعملان، لكن الصيغ الحديثة غالبًا تقدم نفس الجودة البصرية بحجم ملف أصغر.
إن كان نظام إدارة المحتوى أو ملحق الصور يمكنه تقديم WebP/AVIF مع بدائل، فهذا مثالي.
الضغط هو مصدر معظم مكاسب زمن التحميل الفورية. صورة "متطابقة بصريًا" يمكن تقليلها 30–70% في الحجم.
احذف أيضًا البيانات الوصفية غير الضرورية (معلومات الكاميرا، الموقع). لا يغير ذلك من شكل الصورة لكنه يضيف بايتات لا حاجة لها.
قاعدة عملية: اضغط حتى ترى تدهورًا واضحًا في الجودة، ثم ارجع خطوة.
srcset) للجوال والكمبيوترزوار الجوال لا ينبغي أن ينزلوا صور سطح المكتب. تتيح الصور المستجيبة للمتصفح اختيار الحجم المناسب بناءً على عرض الشاشة.
إذا كانت منصتك تولد أحجامًا متعددة تلقائيًا، تأكد أن القالب يستخدمها بشكل صحيح. ما تبحث عنه في HTML هو شيء مثل srcset بدلًا من ملف عملاق واحد.
قبل الانتقال إلى ضبط متقدم (مثل تصغير الكود)، راجع الصور الرئيسية:
قم بهذه الأمور الأربع بانتظام، وسرعة موقعك وزمن التحميل سيتحسنان فورًا—غالبًا بما يكفي لتحريك Core Web Vitals في الاتجاه الصحيح.
التحميل الكسول يعني تأخير تنزيل بعض الصور (وأحيانًا iframes) حتى تقترب من الظهور على الشاشة. هذا يقلل زمن التحميل الأولي لأن المتصفح لا يطلب كل شيء دفعة واحدة—مفيد بشكل خاص في الصفحات الطويلة التي تحتوي على صور كثيرة تحت الطي.
التحميل الكسول مفيد عندما تكون لديك:
استُخدم بشكل صحيح، يقلل العمل المبدئي ويجعل الصفحة تبدو أسرع.
أكبر صورة فوق الطي غالبًا هي صورة البطل. إن حمّلتها كسولًا، قد يتأخر طلبها مما يضر Largest Contentful Paint (LCP).
قاعدة عامة: لا تُطبّق التحميل الكسول على صورة البطل أو أي عنصر حاسم في الشاشة الأولى (صورة العنوان، صورة المنتج الأساسية، الشعار العلوي).
يمكن أن يسبب التحميل الكسول "قفزًا" عند ظهور الصور. لمنع Cumulative Layout Shift (CLS)، احجز المساحة:
width وheight على الصور، أوبهذه الطريقة يبقى التخطيط ثابتًا بينما تُحمّل الصور.
إذا كانت صورة أو خط فوق الطي ضرورية للانطباع الأول، فكّر في preload لها حتى يلتقطها المتصفح مبكرًا. استخدم هذا بحذر—التحميل المسبق المفرط قد يسبب تنافسًا على النطاق الترددي ويضر الأداء.
إذا رغبت بنهج قائمة مرجعية، اقترن هذا بخطوة القياس في /blog/how-to-measure-site-speed-before-you-change-anything.
التخزين المؤقت هو طريقة المتصفح للقول: "لقد نزلت هذا من قبل—هل يمكنني إعادة استخدامه؟" بدلًا من إعادة تنزيل الشعار أو ملف CSS في كل زيارة، يحتفظ المتصفح بنسخة محلية لبعض الوقت. هذا يجعل الزيارات المتكررة أسرع ويقلل استهلاك البيانات—خاصة على الجوال.
عندما يرسل موقعك ملفًا (مثل styles.css أو app.js)، يمكنه أيضًا أن يرسل تعليمات عن مدة صلاحية إعادة الاستخدام. إن سمح المتصفح بالاحتفاظ به، فإن الزيارة القادمة لن تضطر لتنزيل هذه الملفات من الخادم.
هذا لا يسرع الزيارة الأولى، لكنه يحسّن كثيرًا:
الأصول الثابتة هي الأشياء التي لا تتغير كل دقيقة: صور، CSS، JavaScript، خطوط. هذه مناسبة لتعيين أوقات تخزين طويلة.
ما تريده مفاهيميًا:
مزوّد الاستضافة أو الـ CMS قد يوفّر خيارًا لتفعيل "تخزين أصول ثابتة". إن كان لديك مطور، اطلب منه ضبط رؤوس Cache-Control المناسبة للأصول.
مخاوف شائعة: "إذا خزّنا الملفات لشهر، كيف يحصل المستخدمون على التصميم الجديد غدًا؟" الحل هو أسماء ملفات مُرقّمة.
بدلًا من إعادة استخدام app.js إلى الأبد، يمكن لعملية البناء إخراج شيء مثل:
app.3f2a1c.jsstyles.a81b09.cssعند تغيّر المحتوى، يتغيّر اسم الملف، فيعامله المتصفح كملف جديد ويقوم بتحميله فورًا—مع استمرار تخزين الإصدارات القديمة بأمان.
يمكن لخادِمات الخدمة أن تدفع التخزين المؤقت إلى مستوى أعلى بالسماح للموقع بالتحكم بما يُخزّن ومتى، وأحيانًا تفعيل العمل دون اتصال. لكنها قد تسبب أيضًا مشكلات "محتوى قديم" إذا نُفّذت بشكل خاطئ. للمبتدئين، اعتبر service workers خيارًا متقدمًا—جيد عندما تكون لديك أهداف واضحة ومن يعرف صيانتها.
سرعة الموقع عادةً تعني أمرين:
يمكن أن يبدو الموقع "محملاً" لكنه لا يزال بطيئاً إذا كانت جافاسكربت تعمل أو إذا كان التخطيط يتحرك.
تقاس Core Web Vitals وتطابق شكاوى المستخدم الشائعة:
تحسين هذه المقاييس عادةً يحسن الإحساس الفعلي بالسرعة، وليس مجرد رقم.
استخدم هذه الأهداف العملية:
اعتبرها أهدافًا إرشادية — ركز على تحريك أسوأ مقياس أولاً.
ابدأ بقاعدة حتى لا تخمن:
سجّل الجهاز، الشبكة، الموقع، والـ URL الدقيق، وغيّر 1–2 شيء فقط قبل إعادة الاختبار.
أكبر الأسباب عادةً:
إصلاحها بهذا الترتيب يعطي أسرع النتائج عادةً.
لأنها غالبًا أكبر الملفات في الصفحة، وتؤثر في زمن التنزيل وLCP. ركّز على أربعة أمور أساسية:
يُفيد التحميل الكسول للمحتوى غير المرئي عند التحميل الأولي، لكنه قد يضر LCP إذا استُخدم على صورة البطل. قواعد عملية:
width/height أو نسبة عرض/ارتفاع ثابتة.إذا كان شيءٌ جوهريًا للشاشة الأولى، فكّر في تحميله مسبقًا بحذر.
التخزين المؤقت يجعل الزيارات المتكررة أسرع لأن المتصفح يعيد استخدام الملفات بدلًا من تنزيلها من الخادم.
app.3f2a1c.js) حتى لا يبقى المستخدمون على نسخ قديمة.إذا أُعدّت بشكل صحيح، يقلّل التخزين المؤقت من إعادة التنزيل والتحميل بدون كسر التحديثات.
تُفيد الشبكات التوزيعية (CDN) عندما يكون لديك زوّار من مناطق مختلفة وتقدم أصولًا ثابتة كثيرة. أفضل استخدام لها:
انتبه لـ:
الـ CDN ليس بديلًا عن تحسين الصور والسكريبتات، لكنه يضاعف الفائدة بعد معالجة الأساسيات.
اتبع تسلسلًا بسيطًا يمكنك إكماله والتحقق منه:
بعد كل خطوة، أعد الاختبار بنفس الشروط وتفقّد الموقع كزائر للتأكد من عدم حدوث كسر.
srcset) ليحصل الهاتف على ملفات أصغر.التغييرات عادةً منخفضة المخاطر ويمكن قياس أثرها فورًا.