اختبار سرعة الموقع: اكتشف ما يبطّئ صفحتك

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

يقيس اختبار سرعة الصفحة هذا ما يحدث في الخادم وفي HTML: زمن أول بايت، وزمن التنزيل، وحجم HTML وضغطه، وإصدار HTTP، وعدد السكربتات وملفات الأنماط والصور وأوزانها، والموارد المعطِّلة للعرض، ورؤوس التخزين المؤقت، وصيغ الصور. وعندما تتوفر لدى جوجل بيانات ميدانية للرابط، يعرض أيضًا LCP وINP وCLS من PageSpeed Insights.

كيف تجري اختبار سرعة الصفحة

1. أدخل رابط الصفحة

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

2. اقرأ النوعين من البيانات

   مقاييس الخادم ووزن الصفحة تأتي من جلبنا للصفحة، ومؤشرات Core Web Vitals من مستخدمي Chrome الحقيقيين عند توفرها.

3. أصلح الأكثر تكلفة أولًا

   ابدأ بـ TTFB البطيء والصور الضخمة والملفات المعطِّلة للعرض، ثم أعد اختبار الرابط نفسه.

حدود مؤشرات Core Web Vitals

تقيس Core Web Vitals من جوجل التحميل والاستجابة والثبات البصري لدى مستخدمي Chrome الحقيقيين، وتُقيَّم عند المئين الخامس والسبعين (75th percentile) لتحميلات الصفحة:

المقياس	جيد	يحتاج إلى تحسين	ضعيف
LCP (Largest Contentful Paint)	≤ 2.5 s	2.5–4 s	> 4 s
INP (Interaction to Next Paint)	≤ 200 ms	200–500 ms	> 500 ms
CLS (Cumulative Layout Shift)	≤ 0.1	0.1–0.25	> 0.25

حلّ INP محل First Input Delay في مارس 2024. وتأتي البيانات الميدانية من تقرير Chrome UX Report على نافذة متحركة مدتها 28 يومًا، لذلك تحتاج التحسينات أسابيع لتظهر، وقد لا تتوفر أي بيانات للصفحات قليلة الزيارات. ويغطي دليلنا لـ Core Web Vitals كل مقياس بعمق.

قراءة أرقام جانب الخادم

• TTFB: الزمن حتى وصول أول بايت من HTML. يقترح web.dev هدفًا تقريبيًا قدره 0.8 s أو أقل. وكل شيء آخر، ومنه LCP، ينتظره؛ والحلول المعتادة هي التخزين المؤقت للصفحات وشبكة CDN.
• الضغط: يجب تقديم HTML وCSS وJavaScript مضغوطة بـ Brotli أو gzip.
• إصدار HTTP: يتيح HTTP/2 أو HTTP/3 للمتصفح جلب ملفات كثيرة عبر اتصال واحد.
• الطلبات والوزن: كل سكربت وملف أنماط يكلّف وقت تنزيل ومعالجة؛ والصور عادةً أثقل البايتات.
• الموارد المعطِّلة للعرض: ملفات الأنماط والسكربتات المتزامنة في head التي يجب أن تُحمَّل قبل رسم أي شيء.
• التخزين المؤقت: الملفات الثابتة بلا مدة تخزين طويلة تُنزَّل من جديد في كل زيارة.
• صيغ الصور: WebP وAVIF أصغر عادةً بكثير من JPEG وPNG بجودة مماثلة.

إصلاحات تحرّك LCP وINP وCLS

حمّل الصورة الرئيسية مبكرًا ولا تؤجّل تحميلها أبدًا (lazy-load)؛ وحدّد أبعاد كل صورة حتى لا تزيح التخطيط:

<img src="/img/hero.avif" width="1200" height="630"
     fetchpriority="high" alt="Fresh sourdough loaves">
<img src="/img/team.webp" width="600" height="400"
     loading="lazy" alt="Our bakery team">
<script src="/js/app.js" defer></script>

السمة defer تمنع السكربتات من تعطيل أول رسم. وبالنسبة لـ INP، قصّر المهام الطويلة في الخيط الرئيسي: أزل وسوم الأطراف الثالثة غير المستخدمة، وقسّم معالجات الأحداث الثقيلة، وأعد التحكم للمتصفح بين أجزاء العمل. وبالنسبة لـ CLS، احجز مساحة للإعلانات والمحتوى المضمّن وشرائط ملفات تعريف الارتباط بأبعاد ثابتة أو بـ aspect-ratio.

تخزين الملفات الثابتة مؤقتًا

الملفات التي يتغير اسمها مع كل إصدار مثل app.3f9a1c.js يمكن تخزينها سنة كاملة. على Nginx:

location ~* \.(css|js|woff2|avif|webp|jpg|png|svg)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

وعلى Apache تُوضع القيمة نفسها في كتلة <FilesMatch> مع Header set Cache-Control. افعل ذلك للملفات ذات الأسماء المبصومة فقط: فملف عادي مثل style.css يُخزَّن سنة يعني أن الزوار العائدين سيبقون على التصميم القديم بعد أن تغيّره. وتحقق من النتيجة بـفحص رؤوس HTTP.

نصائح لصفحة أسرع

• أصلح القوالب لا الروابط المفردة: فتسريع قالب المنتج يسرّع كل صفحات المنتجات دفعة واحدة.
• غيّر حجم الصور قبل رفعها؛ فصورة بعرض 4,000px تُعرض في مساحة 600px تُهدر معظم بايتاتها.
• راجع وسوم الأطراف الثالثة كل بضعة أشهر؛ فأدوات الدردشة وخرائط الحرارة والبيكسلات المنسية كثيرًا ما تكلّف أكثر من شيفرتك الخاصة.
• استضف الخطوط المهمة بنفسك بصيغة WOFF2 وحمّل مسبقًا (preload) الملف أو الملفين المستخدمين في أعلى الصفحة فقط.
• أعد الاختبار بعد كل تغيير لا بعد عشرة تغييرات، لتعرف أي إصلاح أفاد فعلًا.

حدود يجب مراعاتها

يجلب اختبارنا الصفحة من خادمنا ولا ينفّذ JavaScript ولا يعرض الصفحة، لذلك يقيس استجابة الخادم وأوزان الملفات وبنية HTML لا أزمنة الرسم المخبرية. ولا تظهر Core Web Vitals إلا إذا كانت لدى PageSpeed Insights بيانات مستخدمين حقيقيين للصفحة. ولاختبار مخبري كامل في متصفح حقيقي، استخدم Lighthouse في Chrome DevTools أو PageSpeed Insights، وافحص مشكلات التخطيط على الجوال بـاختبار توافق الموقع مع الجوال.

آخر تحديث: 30‏/10‏/2026 بواسطة فريق Yes SEO.