قل لا للأداء البطيء. تعرّف على كيفية تحسين سرعة موقعك الإلكتروني باستخدام مؤشرات Core Web Vitals (INP وLCP وCLS) على منصات مثل WordPress وShopify وReact/Next.js.
أهم النقاط:
1. كيف أزيد سرعة موقعي الإلكتروني؟
يُعد تحسين سرعة الموقع أمرًا بالغ الأهمية لأداء موقعك. وقبل وضع أي استراتيجية، من المهم البدء بتشخيص دقيق باستخدام أدوات مثل Google PageSpeed Insights أو GTmetrix. تساعدك هذه الأدوات على تحديد المشكلات التي تُبطئ موقعك بدقة. ومعظم هذه المشكلات شائعة، مثل الصور كبيرة الحجم، ومشكلات التخزين المؤقت في المتصفح، وملفات CSS الكبيرة، والإضافات غير المستخدمة، وأدوات الجهات الخارجية. ويمكنك معالجة المشكلات ذات التأثير الكبير بضغط الصور بصيغة WebP أو AVIF، واستخدام شبكة CDN، وتصغير ملفات مثل CSS وJavaScript وHTML. واحذف الإضافات والأدوات التي لم تعد مستخدمة. والأهم من ذلك، أصلح مشكلات Core Web Vitals مثل العناصر بطيئة التحميل وتغيّرات التخطيط. وبعد إصلاحها، قد تتحسن سرعة موقعك بنسبة 70–90%. وإذا ظل موقعك بطيئًا، فيمكن لوكالة محترفة أو مستشاري السيو مساعدتك أكثر.
2. ما السرعة التي ينبغي أن يكون عليها موقعي الإلكتروني فعلًا؟
من الناحية المثالية، ينبغي أن يُحمَّل موقعك خلال ثانيتين إلى ثلاث ثوانٍ. فهذا يوفر تجربة أفضل للمستخدم ويقلل معدلات الارتداد. لكن الأهم من إجمالي وقت التحميل هو المقاييس المحددة في Core Web Vitals من Google. ركّز على أن يكون Largest Contentful Paint (LCP) أقل من 2.5 ثانية، وFirst Input Delay (FID) أقل من 100 مللي ثانية، وCumulative Layout Shift (CLS) قريبًا من 0. فهذه المقاييس تؤثر مباشرة في تجربة المستخدم وترتيب نتائج البحث.
3. هل يمكن لتحسين سرعة الموقع أن يزيد العملاء المحتملين أو المبيعات فعلًا؟
نعم. فالسرعة تؤثر مباشرة في سلوك المستخدمين. والموقع الأسرع يحافظ على تفاعل المستخدمين ويبني الثقة ويحسّن معدلات التحويل.
ركّز على المجالات الرئيسية مثل تسريع تحميل الصفحات المقصودة، وتحسين الأداء على الأجهزة المحمولة، وتقليل التأخير في النماذج وعمليات الدفع. فحتى التحسينات الصغيرة يمكن أن تؤدي إلى نمو ملحوظ في معدلات التحويل.
سرعة الموقع ليست مجرد ميزة. بل تؤثر مباشرة في مبيعاتك وإيراداتك.
وفقًا لشركة Akamai Technologies، تنخفض معدلات التحويل بنسبة 7% مع كل ثانية تأخير. وفي المقابل، يمكن أن يؤدي خفض وقت التحميل من 5 ثوانٍ إلى ثانيتين إلى زيادة التحويلات بنسبة تصل إلى 74%.
تُظهر بيانات Google أن 53% من مستخدمي الأجهزة المحمولة يغادرون الصفحة إذا استغرق تحميلها أكثر من 3 ثوانٍ.
الموقع البطيء لا يُحبط الزوار فحسب، بل يكلّفك فعليًا ترتيبك وإيراداتك وعملاءك المحتملين.
في هذا الدليل، نتناول تقنيات وأدوات وحلولًا عملية لتحسين سرعة موقعك. والأهم من ذلك أنك ستجد أيضًا أساليب متقدمة لا تتطرق إليها معظم الأدلة.
والنتيجة تجربة مستخدم أفضل، وترتيب أفضل في السيو، ومعدلات تحويل أعلى، ومعدلات ارتداد أقل.
لماذا أصبحت سرعة الموقع أهم من أي وقت مضى في 2026
تُخفي معظم المقالات التأثير الحقيقي على الأعمال في حاشية صغيرة. فلنبدأ به، لأنك إن لم تشعر بالإلحاح، فلن تأخذ الأمر على محمل الجد.
يمكنك تغيير الاستراتيجيات. ويمكنك الظهور في الصفحة الأولى. لكن إذا كان موقعك بطيئًا، فسيغادر الزوار قبل أن يروا حتى ما تقدمه.
وجدت Amazon أن كل 100 مللي ثانية من التأخير تكلّفها 1% من مبيعاتها. وبالنسبة إلى نشاط تجارة إلكترونية يحقق $10M سنويًا، فهذا يعني خسارة $100,000 مقابل كل 100 مللي ثانية. هذا ليس تسربًا صغيرًا؛ بل استنزاف صامت للإيرادات.
إذا كنت تريد فهم أرقامك الخاصة:
خذ عدد زوارك الشهري. واضربه في معدل التحويل ومتوسط قيمة الطلب. ثم طبّق انخفاضًا بنسبة 7% عن كل ثانية إضافية يستغرقها تحميل موقعك.
الرقم النهائي؟ إنه الإيرادات التي تهدرها حاليًا.
ماذا تعني السرعة فعلًا في 2026؟
تسمع في كل مرة تقريبًا أن موقعك يجب أن يكون سريعًا، ولكن ما مدى السرعة المطلوبة؟ لا أحد يوضح ذلك بجلاء. وهنا نفصّل الأمر باستخدام Core Web Vitals، التي تحدد معايير أداء قابلة للقياس. وتؤثر هذه المقاييس مباشرة في إشارات الترتيب لديك. ففي مارس 2024، استبدلت Google مقياس First Input Delay (FID) القديم بمقياس Interaction to Next Paint (INP). ويُعد هذا المقياس الجديد طريقة أكثر صرامة بكثير لقياس التفاعلية، ولم تواكبه كثير من الأدلة حتى الآن.
LCP. التحميل
< 2.5s
Largest Contentful Paint. كم يستغرق ظهور المحتوى الرئيسي؟
جيد: <2.5 ث. يحتاج إلى تحسين: 2.5-4 ث. ضعيف: >4 ث
INP. التفاعلية
<200 مللي ثانية
Interaction to Next Paint. يقيس جميع تفاعلات المستخدم، وليس التفاعل الأول فقط.
حلّ محل FID في 2024. جيد: < 200 مللي ثانية. ضعيف: >500 مللي ثانية
CLS. الثبات
<0.1
Cumulative Layout Shift. يقيس الثبات البصري، أي مدى تحرك عناصر الصفحة أثناء تحميلها. جيد: <0.1. ضعيف: >0.25
لماذا يُعد INP أهم مما يدركه الناس
كان FID يقيس فقط التأخير قبل أن يبدأ المتصفح معالجة التفاعل الأول. أما INP فيقيس المدة الكاملة لكل تفاعل طوال الجلسة، بما في ذلك النقرات واللمسات وإدخالات لوحة المفاتيح. والصفحة التي تبدو أزرارها بطيئة ستفشل في INP حتى لو كان FID لديها مثاليًا. ويؤثر ذلك بشكل غير متناسب في تطبيقات الصفحة الواحدة ولوحات المعلومات وأي موقع يعتمد على JavaScript معقد من جهة العميل.
TTFB. استجابة الخادم
< 0.8s
Time to First Byte. مدى سرعة استجابة خادمك عندما يطلب المستخدم الصفحة.
جيد: <0.8 ث. يحتاج إلى تحسين: 0.8–1.8 ث. ضعيف: >1.8 ث
FCP. العرض الأول
< 1.8s
First Contentful Paint. اللحظة التي يظهر فيها أول محتوى مرئي (نص أو صورة) على الشاشة.
جيد: <1.8 ث. يحتاج إلى تحسين: 1.8–3 ث. ضعيف: >3 ث
TBT. وقت الحظر
< 200ms
Total Blocking Time. يقيس المدة التي يكون فيها المتصفح محظورًا وغير قادر على الاستجابة لإدخالات المستخدم.
جيد: <200 مللي ثانية. يحتاج إلى تحسين: 200–600 مللي ثانية. ضعيف: >600 مللي ثانية
Speed Index. التحميل المرئي
< 3.4s
يوضح مدى سرعة عرض محتوى الصفحة بصريًا أثناء التحميل.
جيد: <3.4 ث. يحتاج إلى تحسين: 3.4–5.8 ث. ضعيف: >5.8 ث
شخّص قبل أن تُصلح: أجرِ هذه الاختبارات الخمسة
عندما تبحث عن سرعة الموقع، ستحصل دائمًا على الإجابة نفسها: حسّن الصور واستخدم شبكة CDN فحسب. ولا شك أن هذه نصائح عديمة الجدوى، لأنها لا تحدد موضع الاختناق. وقبل أن تلمس ملفًا واحدًا، نفّذ خطوات التشخيص هذه وسجّل درجاتك الأساسية. فهي نقاط البداية التي ستُظهر مدى التحسن الذي تحققه.
| الأداة | نوع البيانات | ما يخبرك به حصريًا |
|---|---|---|
| Google PageSpeed Insights | ميدانية + مختبرية | بيانات مستخدمين حقيقيين من مجموعة بيانات CrUX، أي الأداء الفعلي على أجهزة حقيقية، وليس مجرد محاكاة مختبرية. كما يعرض حالة Core Web Vitals. |
| GTmetrix | مختبرية (اصطناعية) | مخططات شلالية، وتوقيت تفصيلي للطلبات، ودرجات Lighthouse. رائع لتصحيح موارد محددة. |
| WebPageTest | مختبرية (مواقع متعددة) | يختبر الأداء من مواقع جغرافية وسرعات اتصال مختلفة. مفيد لتحليل تجربة الجمهور العالمي. |
| Chrome DevTools – الشبكة | مختبرية | أكثر تحليل شلالي تفصيلًا متاح. يعرض كل مورد وحجم الملفات وترتيب التحميل والطلبات الحاجبة. |
| Google Search Console – CWV | ميدانية (متوسط 28 يومًا) | يوضح الصفحات التي تفشل في Core Web Vitals استنادًا إلى بيانات المستخدمين الحقيقيين. ويعكس مباشرة التأثير المحتمل في ترتيب Google. |
الفرق الذي لا يشرحه أحد
PageSpeed Insights أداة مجانية من Google تحلل أداء موقعك وسرعته وتجربة المستخدم فيه.
وهي توفر نوعين من البيانات:
البيانات الميدانية (من مستخدمي Chrome الحقيقيين عبر مجموعة بيانات CrUX)
البيانات المختبرية (من اختبار Lighthouse محاكى)
إذا لم يتطابق النوعان، فاعتمد على البيانات الميدانية، لأنها تعكس تجربة المستخدم الحقيقية وما تأخذه Google فعليًا في الاعتبار للترتيب.
تُستخدم البيانات المختبرية أساسًا لتصحيح الأخطاء وتحديد المشكلات.
إذا كانت درجتك منخفضة، فابدأ بفحص Core Web Vitals في البيانات الميدانية، ثم استخدم البيانات المختبرية لإصلاح المشكلات.
بطاقة قياسك الأساسية
قبل إجراء أي تغييرات، سجّل هذه الأرقام السبعة. دوّنها. ستستخدمها لقياس كل تحسين:
- درجة LCP (بالثواني) من PageSpeed Insights
- درجة INP (بالمللي ثانية) من PageSpeed Insights
- درجة CLS من PageSpeed Insights
- TTFB (Time to First Byte) من WebPageTest
- إجمالي حجم الصفحة بالكيلوبايت/الميغابايت من GTmetrix
- إجمالي عدد طلبات HTTP من GTmetrix
- حالة Core Web Vitals من Google Search Console (ناجح / راسب)
تعرّف على كيفية تحسين سرعة الموقع الإلكتروني
قبل إصلاح أي شيء، عليك أن تفهم ما الذي يُبطئ موقعك فعلًا. فمعظم الشركات تقفز مباشرة إلى "التحسين" دون تشخيص المشكلة الحقيقية، وهنا تحديدًا تسوء الأمور.
لنستعرض المشكلات الشائعة وما يمكنك فعله واقعيًا لإصلاحها:
1. الطبقة الأساسية: الاستضافة والخادم والبنية التحتية
الاستضافة هي أساس سرعة موقعك، ويعتمد أداؤك عليها اعتمادًا كبيرًا. فحتى الموقع المحسّن جيدًا سيبدو بطيئًا إذا كان الخادم ضعيفًا.
وهذه غالبًا أكبر فرصة ضائعة، لأن تغيير الاستضافة يبدو أمرًا صعبًا. لكنه في الواقع قد يحسّن سرعتك فورًا دون أي برمجة.
اختيار الاستضافة المناسبة
- الاستضافة المشتركة: للمواقع الصغيرة ذات الزيارات المنخفضة فقط (< 1000 زائر شهريًا). وهي غير مناسبة إذا كان موقعك يولّد عملاء محتملين أو مبيعات.
- الخادم الافتراضي الخاص (VPS): خيار وسط جيد. سرعة أفضل وتحكم أكبر مقارنة بالاستضافة المشتركة.
- الاستضافة السحابية المُدارة: مزودون مثل Kinsta وWP Engine وCloudways يتولون الأداء نيابةً عنك. الأفضل لمواقع الأعمال.
- الاستضافة الطرفية (Edge): منصات مثل Vercel وNetlify وCloudflare Pages تحمّل موقعك من خوادم قريبة من المستخدمين. وهذا يجعل موقعك سريعًا للغاية في جميع أنحاء العالم.
مقياس سرعة مهم: TTFB (Time to First Byte)
جيد: أقل من 800 مللي ثانية
ممتاز: أقل من 200 مللي ثانية
إذا بدا موقعك بطيئًا، فهذا هو السبب عادةً
3 أسباب شائعة لبطء السرعة
عدم وجود تخزين مؤقت: يعيد موقعك تحميل كل شيء في كل مرة. ويمكن للتخزين المؤقت أن يجعله أسرع بكثير.
موقع الخادم البطيء: إذا كان خادمك بعيدًا عن مستخدميك، فسيُحمَّل موقعك بشكل أبطأ.
قاعدة بيانات أو واجهة خلفية ثقيلة: المعالجة الزائدة على الخادم تُبطئ كل شيء.
حل بسيط يغفل عنه معظم الناس
فعّل HTTP/3 وQUIC
أصبح HTTP/3 في 2026 مدعومًا على نطاق واسع في جميع المتصفحات وشبكات CDN الرئيسية. ويستخدم HTTP/3 بروتوكول النقل QUIC بدلًا من TCP. وهو يحسّن السرعة، خاصةً على شبكات الهاتف المحمول. ويدعمه بالفعل كثير من مزودي الاستضافة وCloudflare.
ما تحصل عليه بعد إصلاح هذه الطبقة
وقت تحميل أسرع للموقع
تجربة مستخدم أفضل
تحويلات أعلى
معدل ارتداد أقل
2. تحسين الصور: أكبر مكسب في السرعة
يأتي معظم حجم صفحاتك من الصور، إذ تشكّل في حالات كثيرة ما بين 50 و80% من إجمالي حجم الصفحة. لذا، إذا كان موقعك بطيئًا، فهذا أول ما يجب إصلاحه. والخبر الجيد أنك لا تحتاج إلى معرفة عميقة في السيو التقني لتحسين ذلك.
استخدم صيغ صور حديثة
الصيغ القديمة مثل JPEG وPNG ثقيلة. انتقل إلى:
WebP: حجم أصغر بالجودة نفسها. يعمل على جميع المتصفحات تقريبًا.
AVIF: أصغر حتى من WebP. الأفضل لتحقيق أقصى ضغط.
SVG: استخدمه للشعارات والأيقونات. خفيف جدًا وقابل للتحجيم.
يستخدم التطبيق الصحيح في HTML العنصر <picture> لتقديم أفضل صيغة يدعمها المتصفح:
قدّم حجم الصورة المناسب (srcset وsizes)
لا تحمّل صورة كبيرة واحدة لجميع الأجهزة. استخدم srcset و sizes حتى يختار المتصفح حجم الصورة الصحيح. إليك التطبيق الصحيح:
إذا كانت السمة sizes مفقودة، فقد يحمّل المتصفح صورة أكبر من اللازم، مما يُبطئ موقعك.
استخدم التحميل الكسول بحذر
يساعد التحميل الكسول على تحميل الصور عند الحاجة فقط. استخدم loading=”lazy” للصور الموجودة أسفل الجزء المرئي من الشاشة.
لكن تجنّب خطأً شائعًا واحدًا:
لا تطبّق التحميل الكسول أبدًا على صورة LCP
صورة LCP (وهي عادةً الصورة الرئيسية، أو صورة المنتج في الجزء المرئي من الصفحة، أو الصورة المميزة للمقال) هي ما تقيسه Google. فإذا طبّقت عليها التحميل الكسول، فسيؤخر المتصفح تحميلها عمدًا، مما يُضعف مباشرة درجة LCP وترتيبك في Core Web Vitals. لذا طبّق loading=”lazy” على الصور الموجودة أسفل الجزء المرئي فقط. أما صورة LCP، فاستخدم لها fetchpriority=”high” بدلًا من ذلك لتطلب من المتصفح تحميلها بأولوية قصوى.
الأدوات الموصى بها حسب حالة الاستخدام
- Squoosh (squoosh.app): مجاني ويعمل من المتصفح. الأفضل لتحويل الصور الفردية وضغطها. يدعم AVIF وWebP وجميع الصيغ الحديثة مع معاينة مرئية للجودة.
- ImageOptim: تطبيق لنظام Mac للضغط المجمّع دون فقدان. مناسب لتحسين دفعة واحدة من الصور.
- Cloudinary / Imgix: تحويل الصور عبر شبكة CDN. يقدّم الصيغة والحجم والجودة المناسبة تلقائيًا بحسب الجهاز والمتصفح الطالب. الأفضل للمواقع ذات مكتبات الصور الكبيرة أو المحتوى الذي ينشئه المستخدمون.
- ShortPixel / Imagify: إضافات WordPress تضغط الصور وتحوّلها تلقائيًا عند رفعها. حل "اضبطه وانسَه" لمواقع WordPress.
ما يُصلحه ذلك:
تحميل أسرع، ونتائج أفضل في Core Web Vitals، وتحسين السيو، وانخفاض معدل الارتداد.
3. ملفات JavaScript وCSS الحاجبة للعرض
عند تحميل صفحتك، يقرأ المتصفح HTML من الأعلى إلى الأسفل. فإذا وجد ملفات <Script> أو <link rel=” stylesheet”>، فإنه يوقف كل شيء لتنزيلها ومعالجتها. ويُسمى هذا التأخير حجب العرض، وهو سبب رئيسي لبطء التحميل وضعف درجات LCP.
لماذا يهم ذلك
قبل عرض أي شيء على الشاشة، يحتاج المتصفح إلى:
- تحويل HTML إلى DOM
- تحويل CSS إلى CSSOM
- دمج الاثنين في شجرة عرض
يمكن لـ JavaScript تغيير الاثنين معًا، لذا يتوقف المتصفح عن العرض إلى أن تتم معالجة النصوص البرمجية. وكلما زاد الحجب، تأخر ظهور أول محتوى مرئي.
حل بسيط يمكن لأي شخص تطبيقه
Defer مقابل Async مقابل Module: الدليل الشامل
<script src=”…”>— الوضع الافتراضي. يحجب تحليل HTML بالكامل. ويتم التنزيل والتنفيذ بشكل متزامن. لا تستخدمه أبدًا للنصوص البرمجية غير الحرجة.
<script defer src=”…”>— يُنزَّل بالتوازي مع تحليل HTML لكنه لا يُنفَّذ إلا بعد اكتمال التحليل، وبترتيب المستند. استخدمه للنصوص البرمجية التي تعتمد على DOM أو على بعضها بعضًا (أدوات التحليلات ومعظم الإضافات).
<script async src=”…”>— يُنزَّل بالتوازي ويُنفَّذ فور جاهزيته، مقاطعًا تحليل HTML. ولا يكون ترتيب التنفيذ مضمونًا. استخدمه للنصوص البرمجية المستقلة تمامًا (الإعلانات وأدوات التواصل الاجتماعي) حيث لا يهم الترتيب.
<script type=”module”>— مؤجَّل افتراضيًا، ويدعم استيراد وحدات ES، ويعمل دائمًا في الوضع الصارم. استخدمه لـ JavaScript الحديثة التي تعتمد صيغة import/export
قاعدة عملية
انقل جميع وسوم <script> إلى ما قبل </body> مباشرةً، أو أضف defer إلى النصوص البرمجية في <head>. ولا تضع أبدًا نصوصًا برمجية حاجبة في <head> دون defer أو async، فهذا هو الإصلاح الأكثر تأثيرًا على الإطلاق لمشكلة حجب العرض.
قلّل حجم الملفات
صغّر ملفات CSS وJavaScript. فهذا يزيل المسافات الزائدة ويقلل حجم الملفات بنسبة تصل إلى 40% دون تغيير وظائفها.
التحميل الذكي في 2026
بدلًا من ملف واحد كبير، قسّم شيفرتك حسب الصفحات أو الميزات. فالمتصفحات الحديثة تستطيع تحميل عدة ملفات صغيرة بسرعة أكبر.
احذف CSS غير المستخدم
تحمّل معظم المواقع ملفات CSS أكثر من اللازم. احذف الأنماط غير المستخدمة لتقليل حجم الملفات وتسريع العرض.
حيلة أداة Coverage في Chrome DevTools
افتح Chrome DevTools ثم More tools – Coverage (أو اضغط Ctrl+Shift+P) وابحث عن coverage. ثم انقر زر التسجيل وحمّل صفحتك. يعرض تبويب Coverage بدقة النسبة المستخدمة فعليًا من كل ملف CSS وJS. وأي ملف CSS تزيد نسبة غير المستخدم فيه على 70% هو هدف رئيسي للتنظيف. استخدم PurgeCSS أو UnCSS أو ميزة التنظيف المدمجة في Tailwind لإزالة الأنماط غير المستخدمة تلقائيًا.
4. استراتيجية التخزين المؤقت: المتصفح والخادم وشبكة CDN
التخزين المؤقت ليس إعدادًا واحدًا، بل له ثلاث طبقات، تحل كل منها مشكلة مختلفة. وإذا تعاملت معها بالطريقة نفسها، فقد يعرض موقعك محتوى قديمًا أو يظل بطيئًا.
- 1. ذاكرة التخزين المؤقت للمتصفح: تخزّن الملفات على جهاز المستخدم باستخدام Cache-Control وExpires. الأفضل للزوار العائدين. ولا تأثير لها على المستخدمين الجدد.
- 2. ذاكرة التخزين المؤقت للخادم: تخزّن البيانات المعالَجة باستخدام أدوات مثل Redis أو Memcached. تقلل TTFB وتسرّع المواقع الديناميكية مثل WordPress.
- 3. ذاكرة التخزين المؤقت لشبكة CDN: تخزّن موقعك على خوادم عالمية. وتقدّم المحتوى من أقرب موقع، مما يحسّن وقت التحميل في جميع أنحاء العالم.
أساسيات Cache-Control
تتحكم هذه الترويسات فيما يتم تخزينه مؤقتًا ولأي مدة:
إبطال ذاكرة التخزين المؤقت عبر تجزئة المحتوى
تُعاد تسمية ملفات مثل main.js إلى main.a3f9c2d.js. وعندما يتغير المحتوى، يتغير اسم الملف. وهذا يتيح تخزينًا مؤقتًا طويل الأمد دون عرض محتوى قديم.
خيارات CDN
- Cloudflare: نقطة انطلاق جيدة. تغطي الخطة المجانية معظم الاحتياجات.
- BunnyCDN: فعّال من حيث التكلفة للمواقع ذات الزيارات الكثيفة والمحتوى الإعلامي الكثيف.
- Fastly / Akamai Technologies: إعداد متقدم للمواقع الكبيرة.
لماذا يهم ذلك
يحسّن التخزين المؤقت الصحيح السرعة، ويقلل الحمل على الخادم، ويعزز معدلات التحويل.
إذا كان التخزين المؤقت لديك خاطئًا، فحتى الخادم السريع سيبدو بطيئًا.
5. الضريبة الخفية: النصوص البرمجية للجهات الخارجية
تؤدي النصوص البرمجية للجهات الخارجية على الموقع، مثل أدوات التحليلات والدردشة المباشرة وأدوات التواصل الاجتماعي وشبكات الإعلانات وأدوات اختبار A/B، إلى إضافة حمل إضافي على متجرك الإلكتروني. وفي هذه الحالة، لا تتحكم في شيفرتها أو خادمها أو توقيتها.
يضيف كل نص برمجي لجهة خارجية عملية بحث DNS واحدة واتصالًا واحدًا على الأقل، أي أنه كلما زادت طلبات الاتصال زاد التأخير. وهذا يؤثر مباشرة في السرعة وتجربة المستخدم.
كيفية التحقق من ذلك
افتح Chrome DevTools، ثم انتقل إلى تبويب Network.
رتّب حسب النطاقات وابحث عن طلبات الجهات الخارجية
أو شغّل Lighthouse وتحقق من
"قلّل تأثير شيفرة الجهات الخارجية".
ركّزوا على:
وقت السلسلة الرئيسية
حجم النقل
عدد الطلبات
لماذا يهم ذلك؟
كلما أردت إضافة نص برمجي، اطرح هذا السؤال: ما تكلفة ذلك؟ ونوضح هنا ما يحدث بعد دمج الأداة.
يمكن لأداة دردشة واحدة أن تعيق السلسلة الرئيسية لمدة تتراوح بين 300 و800 مللي ثانية.
يمكن لأدوات التحليلات أن تضيف ما بين 200 و400 كيلوبايت من JavaScript
يمكن لأداة اختبار أن تؤخر LCP لديك بمقدار 300 إلى 600 مللي ثانية
باختصار، قارن التكلفة؛ وإذا لم تبررها القيمة التجارية، فاحذفه ببساطة.
أصلح العناصر بطيئة التحميل بأسلوب ذكي: استخدم الواجهات البديلة للعناصر المضمّنة الثقيلة
هذا تحسين ذكي كثيرًا ما يُغفل عنه حتى في 2026. والواجهة البديلة (Facade) عنصر نائب خفيف يؤجل تحميل العناصر المضمّنة الثقيلة إلى أن يتفاعل معها المستخدم.
بدلًا من تحميل عناصر مثل YouTube أو الخرائط أو أدوات الدردشة فورًا، تعرض معاينة بسيطة (مثل صورة أو صورة مصغّرة). ولا يُحمَّل المحتوى الفعلي إلا عندما ينقر المستخدم.
يقلل ذلك وقت التحميل الأولي للصفحة ويحسّن الأداء دون إزالة أي وظائف.
النتيجة: لا حمل إضافي إلا عند الحاجة.
مكاسب تقنية سريعة
استضف الخطوط ذاتيًا للتخلص من تأخيرات DNS والاتصال الإضافية
استخدم font-display: swap لإبقاء النص مرئيًا
حمّل الخطوط المهمة مسبقًا باستخدام <link rel=”preload”>
بالنسبة إلى النصوص البرمجية المهمة للجهات الخارجية، استخدم:
<link rel=”preconnect”>
وبالنسبة إلى الأقل أهمية، استخدم:
<link rel=”dns-prefetch”>
6. تحسين INP: اجعل موقعك سريعًا عند الاستخدام
أصبح INP (Interaction to Next Paint) الآن أحد أهم مقاييس السرعة، بعد أن حلّت إشارة الترتيب المهمة هذه من Google محل FID في مارس 2024.
وهو يقيس مدى سرعة استجابة صفحتك بصريًا بعد تفاعل المستخدم، سواء بالنقر أو الكتابة أو التفاعل مع أي عنصر.
قد يُحمَّل الموقع بسرعة لكنه يظل بطيئًا في الإحساس إذا تأخرت التفاعلات. ولهذا يُعد INP أهم من مجرد سرعة تحميل الصفحة.
الأسباب الرئيسية لضعف INP
المهام الطويلة التي تحجب السلسلة الرئيسية: أي مهمة JavaScript تستغرق أكثر من 50 مللي ثانية تُعد "مهمة طويلة". وهي تمنع المتصفح من معالجة إدخالات المستخدم حتى تنتهي
معالجات الأحداث الثقيلة: إذا كان النقر على زر يُجري حسابات ثقيلة، ويحدّث عناصر كثيرة في الصفحة، ويستدعي واجهة API، كل ذلك في الوقت نفسه، فإنه يحجب المتصفح.
تكرار إعادة حساب التخطيط (Layout thrashing): عندما تواصل قراءة حجم العناصر وتغييره داخل حلقة (مثل التحقق من العرض ثم ضبطه مجددًا)، يضطر المتصفح إلى إعادة حساب التخطيط في كل مرة. وهذا يُبطئ موقعك.
تنفيذ قدر كبير من JavaScript الخاصة بالجهات الخارجية عند التفاعل: أحداث التحليلات وبكسلات تتبع الإعلانات التي تُطلق عند النقر تضيف مئات المللي ثانية إلى زمن الاستجابة.
كيفية الإصلاح
- قسّم المهام الطويلة إلى أجزاء أصغر باستخدام setTimeout أو scheduler.postTask()
- قلّل JavaScript الثقيلة في أحداث النقر
- تجنّب تحديثات DOM المتكررة داخل الحلقات
- حدّ من النصوص البرمجية للجهات الخارجية عند التفاعل
- بالنسبة إلى مواقع React، استخدم startTransition() في React 18 لتحديثات أكثر سلاسة
الثبات البصري (CLS): امنع صفحتك من القفز
يقيس CLS (Cumulative Layout Shift) مدى تحرك صفحتك أثناء التحميل.
إذا تحرك النص فجأة أو انتقل زر أثناء النقر عليه، فهذا هو CLS. فالصفحة الثابتة تمنح إحساسًا بالسلاسة، أما الصفحة المتقافزة فتخسر المستخدمين.
الأسباب الشائعة لـ CLS وكيفية إصلاحها
الصور ومقاطع الفيديو بلا أبعاد محددة: لا يعرف المتصفح مقدار المساحة التي يجب حجزها.
الحل: أضف width وheight في كل وسم <img>.
الإعلانات أو إطارات iframe دون مساحة محجوزة: تُحمَّل لاحقًا وتدفع المحتوى إلى الأسفل.
الحل: حدّد ارتفاعًا ثابتًا أو حدًا أدنى للارتفاع لحاويات الإعلانات.
المحتوى المضاف بعد تحميل الصفحة: النوافذ المنبثقة أو اللافتات أو إشعارات ملفات تعريف الارتباط تُزيح المحتوى.
الحل: احجز لها مساحة أو ضعها في أسفل الصفحة.
مشكلات تحميل الخطوط (FOUT): يتغير نمط النص بعد التحميل فيُزيح التخطيط.
الحل: استخدم font-display: optional أو اضبط أحجام الخطوط بشكل متطابق.
حركات CSS الخاطئة: استخدام top أو left أو margin يسبب تغيّرات في التخطيط.
الحل: استخدم transform وopacity.
الأقسام المتأخرة في التحميل: بطاقات أو محتوى يُحمَّل بحجم أكبر من المتوقع.
الحل: اجعل حجم العنصر النائب (skeleton) مطابقًا لحجم المحتوى النهائي.
حل حديث وبسيط للصور
استخدم aspect-ratio في CSS حتى تُحجز المساحة قبل تحميل الصورة.
يمنع ذلك تمامًا تغيّرات التخطيط الناتجة عن الصور.
دليل سريع لـ font-display
font-display: swap ← نص سريع، وتغيّر طفيف في التخطيط
font-display: optional ← لا تغيّر في التخطيط، لكن قد لا يُحمَّل الخط
font-display: block ← نص غير مرئي، تجنّب استخدامه
قوائم تحقق السرعة الخاصة بكل منصة
قائمة تحقق سرعة WordPress (2026)
يُشغّل WordPress نسبة 43% من المواقع الإلكترونية، لكن الإعدادات الافتراضية غالبًا ما تكون بطيئة. ركّز على هذه النقاط أولًا:
- استخدم استضافة WordPress مُدارة لأداء أفضل: Kinsta أو WP Engine أو Cloudways
- ثبّت إضافة للتخزين المؤقت وفعّل جميع طبقاته.
- اختر قالبًا خفيفًا لتقليل حمل CSS وJavaScript.
- احذف الإضافات غير المستخدمة لتقليل الحمل على الخادم والنصوص البرمجية.
- استضف الخطوط ذاتيًا لتجنّب الطلبات الخارجية.
- نظّف قاعدة بياناتك بانتظام للحفاظ على سرعة الاستعلامات.
- حسّن الصور واضغطها قبل رفعها أو أثناءه.
قائمة تحقق Shopify والتجارة الإلكترونية
تنشأ مشكلات السرعة عادةً من التطبيقات والصور:
- راجع جميع التطبيقات المثبتة لتقليل JavaScript غير الضرورية.
- اختر قالبًا محسّنًا للأداء.
- غيّر حجم صور المنتجات واضغطها إلى أحجام مناسبة للويب.
- فعّل التحميل الكسول لصور المنتجات والمجموعات.
- احذف النصوص البرمجية غير الحرجة للجهات الخارجية أو أجّلها.
نصائح السرعة لـ React / Next.js
- استخدم الاستيراد الديناميكي لتحميل الشيفرة عند الحاجة فقط.
- اختر طريقة العرض المناسبة لكل صفحة.
- استخدم startTransition للحفاظ على سلاسة الواجهة.
- اجلب الروابط مسبقًا لتحسين سرعة التنقل.
تقنيات متقدمة تجعل موقعك سريعًا بالفعل في نظر المستخدمين
تتجاوز هذه التقنيات التحسين الأساسي، إذ تحسّن السرعة الفعلية والسرعة التي يشعر بها المستخدمون على حد سواء.
1. Speculation Rules API (تحميل فوري للصفحات)
تتيح هذه الميزة للمتصفح تحميل الصفحات قبل أن ينقر المستخدم.
وعندما ينقر المستخدم، تظهر الصفحة فورًا لأنها جاهزة بالفعل في الخلفية.
وبالنسبة إلى المطورين، يتم ذلك باستخدام Speculation Rules API مع إعدادات prerender. ابدأ بالوضع moderate حتى لا تهدر الموارد.
لماذا يهم ذلك: لا يشعر المستخدمون بأي تأخير أثناء التنقل.
2. Priority Hints (حسّن LCP بسرعة)
ليست كل الموارد متساوية في الأهمية.
باستخدام fetchpriority، تخبر المتصفح بما يجب تحميله أولًا.
اجعل صورتك الرئيسية (عنصر LCP) ذات أولوية عالية
اجعل النصوص البرمجية مثل أدوات التحليلات ذات أولوية منخفضة
لماذا يهم ذلك: تحميل المحتوى الأساسي بسرعة أكبر يحسّن LCP وتجربة المستخدم.
3. الحوسبة الطرفية (قلّل تأخير الخادم)
بدلًا من تحميل موقعك من خادم واحد بعيد، تقدّمه الحوسبة الطرفية من موقع قريب.
تعالج أدوات مثل Cloudflare وVercel الطلبات بالقرب من المستخدم.
لماذا يهم ذلك: انخفاض TTFB وأوقات استجابة أسرع في جميع أنحاء العالم.
4. View Transitions API (اجعل السرعة محسوسة أكثر)
السرعة لا تتعلق بالأرقام فقط، بل بالإدراك أيضًا.
مع View Transitions API، تبدو تغييرات الصفحات سلسة بدلًا من أن تكون مفاجئة.
وحتى لو كان وقت التحميل أطول قليلًا، يشعر المستخدمون بأن الموقع أسرع.
لماذا يهم ذلك: تجربة مستخدم أفضل وتفاعل أكبر.
خطة عملك لمدة 30 يومًا
الأسبوع 1
التشخيص وإصلاح الصور
- إجراء تشخيص كامل (PSI وGTmetrix وWebPageTest)
- تسجيل بطاقة القياس الأساسية
- تحويل جميع الصور إلى WebP/AVIF
- إضافة width/height إلى جميع وسوم img
- إضافة fetchpriority="high" إلى صورة LCP
- إزالة التحميل الكسول من الصور في الجزء المرئي من الصفحة
الأسبوع 2
التخزين المؤقت والاستضافة
- تفعيل التخزين المؤقت للصفحة الكاملة من جهة الخادم
- ضبط ترويسات Cache-Control للأصول الثابتة
- تفعيل شبكة CDN (الخطة المجانية من Cloudflare إن لم يتوفر غيرها)
- استضافة الخطوط ذاتيًا وإزالة رابط Google Fonts
- تقييم ترقية الاستضافة إذا كان TTFB > 600 مللي ثانية
الأسبوع 3
النصوص البرمجية والجهات الخارجية
- إضافة defer/async إلى جميع النصوص البرمجية غير الحرجة
- مراجعة النصوص البرمجية للجهات الخارجية وحذف غير المستخدم منها
- إضافة preconnect للجهات الخارجية المتبقية
- تطبيق واجهة بديلة لمقاطع YouTube المضمّنة
- مراجعة CSS غير المستخدم باستخدام تبويب Coverage
الأسبوع 4
التقنيات المتقدمة والمراقبة
- تحليل مشكلات INP وإصلاحها
- مراجعة CLS وإصلاح العناصر المسببة لتغيّر التخطيط
- إضافة Speculation Rules إلى الصفحات ذات الزيارات العالية
- إعداد Lighthouse CI في مسار النشر لديك
- ضبط تنبيهات CWV في Search Console
- إعادة القياس وتوثيق التحسينات
الكلمة الأخيرة!
سرعة الموقع ليست مشروعًا له تاريخ انتهاء، بل ممارسة مستمرة. فكل ميزة أو إضافة أو صورة جديدة قد تُحدث تراجعًا محتملًا. والفرق التي تحافظ على مواقع سريعة هي تلك التي تتعامل مع الأداء بوصفه انضباطًا مستمرًا — مع المراقبة والميزانيات وعادة المراجعة الفصلية — لا مجرد جهد سريع لمرة واحدة. وسيتراجع العمل الذي تنجزه هذا الشهر دون صيانة. فابنِ الأنظمة، لا الإصلاحات فقط.
