مقدمة
لماذا نستخدم PageSpeed Insights؟
أداة Google PageSpeed Insights (PSI) هي المقياس الرسمي من جوجل لمعرفة مدى سرعة وكفاءة صفحة الويب. لم تعد السرعة مجرد "ميزة إضافية"، بل هي عامل أساسي في ترتيب نتائج البحث وتجربة المستخدم.
عندما يكون موقعك بطيئاً، فإن جوجل يزحف إلى صفحات أقل، والمستخدمون يغادرون قبل رؤية محتواك، مما يرفع من معدل الارتداد (Bounce Rate) ويدمر مبيعاتك. كل ما يحدث خلف الكواليس التقنية ينعكس مباشرة على أرباحك وتصنيفك.
53%
من زوار الموبايل يغادرون إذا استغرق التحميل أكثر من 3 ثوانٍ
7%
انخفاض في المبيعات مقابل كل ثانية تأخير إضافية
عامل ترتيب
جوجل تستخدم مقاييس CWV كعامل ترتيب رسمي منذ 2021
+74%
ارتفاع في معدلات التحويل عند تسريع الموقع بثانية واحدة
+15%
زيادة في الزيارات العضوية للمواقع التي تجتاز Core Web Vitals
×2.4
تحسن في معدلات إتمام الطلبات على المتاجر الإلكترونية السريعة
32%
زيادة معدل الارتداد مع كل ثانية تأخير إضافية بين 1-3 ثوانٍ
أولوية
جوجل يعطي أولوية الفهرسة للمواقع السريعة في Crawl Budget
60%
من الزيارات العالمية تأتي من الأجهزة المحمولة بشبكات أبطأ
التاريخ
كيف تطورت أداة PageSpeed عبر السنين؟
لم تصل PageSpeed Insights إلى شكلها الحالي دفعة واحدة. فهم تطورها يساعدك على فهم لماذا تُعطى الأولوية لمقاييس بعينها اليوم.
2010
الإطلاق الأول كإضافة متصفح
أطلقت جوجل PageSpeed كإضافة لمتصفح فايرفوكس وكروم لقياس سرعة الصفحة باستخدام أكثر من 25 قاعدة تقنية بسيطة مثل ضغط الصور وتمكين الضغط Gzip.
2013
أداة ويب مستقلة وإضافة API
تحولت الأداة إلى موقع مستقل على الإنترنت مع توفر API للمطورين. بدأت النتائج تنقسم لتقييمات للموبايل والديسكتوب بشكل منفصل لأول مرة.
2018
اعتماد Lighthouse كمحرك رئيسي
اندمجت PSI مع محرك Lighthouse الأقوى. ظهرت نتيجة أداء شاملة من 100، ومقاييس جديدة مثل First Contentful Paint وTime to Interactive.
2020-2021
Core Web Vitals وعامل الترتيب الرسمي
أعلنت جوجل رسمياً عن LCP وFID وCLS كعوامل ترتيب في تحديث Page Experience. أصبح اجتياز هذه المقاييس ضرورة سيو وليس مجرد توصية.
2024
استبدال FID بـ INP كمقياس تفاعل رسمي
أصبح مقياس INP (Interaction to Next Paint) المقياس الرسمي بديلاً عن FID القديم. يقيس INP كل التفاعلات خلال جلسة الزيارة وليس فقط التفاعل الأول.
تحليل البيانات
بيانات المختبر (Lab Data) مقابل البيانات الحقيقية (Field Data)
أول ما يُربك المستخدمين في أداة PageSpeed هو وجود مجموعتين من الأرقام. لكي تفهم النتائج بشكل صحيح، يجب أن تفرق بينهما:
البيانات الحقيقية (Field Data - CrUX)
هذه هي الأرقام التي يعتمد عليها جوجل في الترتيب.
مأخوذة من مستخدمين حقيقيين يتصفحون موقعك عبر متصفح Chrome.
تمثل متوسط الأداء خلال آخر 28 يوماً.
تتأثر بسرعة إنترنت المستخدمين ونوع هواتفهم الفعلية.
بيانات المختبر (Lab Data)
هي النتيجة اللحظية (الرقم من 100) التي تراها عند الفحص.
بيئة محاكاة (هاتف متوسط عبر شبكة 4G).
تُستخدم لاكتشاف الأخطاء وتجربة الحلول البرمجية فوراً.
لا تؤثر بشكل "مباشر" على السيو، بل تتنبأ بأداء المستخدمين.
نقطة مهمة جداً للمواقع الجديدة
إذا كان موقعك جديداً أو حركة الزيارات قليلة، قد لا تظهر لك بيانات CrUX الحقيقية أبداً (ستظهر رسالة "لا تتوفر بيانات كافية"). في هذه الحالة، ركز فقط على تحسين بيانات المختبر لتتنبأ بتجربة زوارك القادمين.
كيف تُحسب نتيجة الـ 100 في بيانات المختبر؟
المقاييس الحيوية
شرح مؤشرات Core Web Vitals الحديثة
للحصول على العلامة الخضراء، يجب أن تنجح في المقاييس الثلاثة الرئيسية التي تحددها جوجل. (ملاحظة: تم استبدال مقياس FID بمقياس INP مؤخراً).
LCP (التحميل)
الهدف: أقل من 2.5s
INP (الاستجابة)
الهدف: أقل من 200ms
CLS (الاستقرار)
الهدف: أقل من 0.1
FCP (البداية)
الهدف: أقل من 1.8s
LCP (Largest Contentful Paint)
سرعة تحميل أكبر عنصر في الشاشة
يقيس الوقت الذي يستغرقه تحميل الصورة الرئيسية (Hero Image) أو كتلة النص الكبيرة في بداية الصفحة. إذا كان LCP بطيئاً، سيشعر المستخدم أن الموقع معطل. العناصر التي تؤثر على LCP هي: الصور الكبيرة، الفيديوهات المضمنة، كتل النص الكبيرة التي تحتاج لتحميل خط خارجي. الحل الأبرز هو ضغط صورة الغلاف واستخدام خوادم سريعة وتفعيل Preload للموارد الحيوية.
INP (Interaction to Next Paint)
سرعة استجابة الموقع للنقرات
المقياس الجديد الذي استبدل FID. يقيس الوقت من لحظة نقر المستخدم على زر (مثل القائمة المنسدلة أو "إضافة للسلة") حتى يتغير شكل الشاشة استجابةً له. سببه الرئيسي هو أكواد الجافاسكريبت (JS) الثقيلة التي تشغل المتصفح. الفرق بينه وبين FID أنه يقيس كل النقرات طوال الجلسة وليس الأول فقط.
CLS (Cumulative Layout Shift)
الاستقرار البصري للصفحة
هل سبق وحاولت النقر على رابط فجأة تحركت الشاشة فنقرت على إعلان؟ هذا هو الـ CLS. يحدث بسبب تحميل خطوط متأخرة أو صور وإعلانات لا تمتلك أبعاداً (Width/Height) محددة مسبقاً في الكود. كلما قل الرقم كان أفضل، والصفر هو المثالي.
مقارنة الأجهزة
الجوال مقابل سطح المكتب — أيهما يجب أن تركز عليه أولاً؟
PageSpeed Insights يعطيك تقريرين منفصلين: واحد للموبايل وواحد للديسكتوب. غالباً ما تكون نتيجة الديسكتوب أعلى بكثير. إليك لماذا وكيف تتعامل مع كل منهما:
فحص الجوال — الأهم!
المحاكاة تستخدم هاتف متوسط (Moto G4)
شبكة 4G بطيئة (10 ميجابت تنزيل)
معالج محدود (تباطؤ ×4 محاكاة)
جوجل يعتمده لترتيب Mobile-First
نتائج دائماً أقل من الديسكتوب
الهدف: 80+ يكفي في البداية
فحص سطح المكتب
محاكاة شبكة سريعة (10 جيجابت)
بدون تباطؤ معالج
النتائج دائماً أعلى بفارق كبير
يعكس تجربة مستخدمي الحاسوب فقط
أهمية أقل من الجوال في السيو
الهدف: 95+ سهل التحقيق
لماذا نتيجة الجوال دائماً أقل؟
لأن الأداة تحاكي هاتفاً متوسطاً بمعالج ضعيف على شبكة 4G بطيئة. هذا يعني أن نتيجة 60 في الجوال قد تعني نتيجة ممتازة في الواقع، لأن كثيراً من مستخدميك يملكون هواتف أحدث وشبكات أسرع. لا تنزعج من النتيجة المنخفضة في الجوال — قارن بالبيانات الحقيقية دائماً.
التشخيص
كيف تشخّص مشاكل موقعك خطوة بخطوة؟
قبل البدء في إصلاح أي شيء، عليك أولاً تحديد المشكلة الحقيقية. إليك المنهجية الصحيحة لتشخيص أداء موقعك:
افحص الصفحة الرئيسية
ابدأ بفحص الصفحة الرئيسية ثم أهم 5 صفحات
حدد أضعف مقياس
ركز على المقياس الأكثر تأثيراً في نتيجتك
طبّق الإصلاح
ابدأ بالإصلاحات السهلة ذات التأثير الأكبر
اختبر وكرر
انتظر 24 ساعة وافحص من جديد لقياس التحسن
1
افتح PSI وافحص أهم صفحاتك
اذهب إلى pagespeed.web.dev وأدخل رابط الصفحة الرئيسية، ثم أكثر 3 صفحات زيارةً في موقعك (استخرجها من Google Analytics). لا تفحص صفحة واحدة فقط.
2
اقرأ قسم "الفرص" (Opportunities) أولاً
هذا القسم يحدد المشاكل ذات التأثير الأكبر على وقت التحميل ويقدر وقت الإنقاذ لكل منها. ابدأ بما يعطيك أكبر وقت توفير.
3
افحص قسم "التشخيصات" (Diagnostics)
يكشف مشاكل برمجية عميقة مثل DOM الضخم، طلبات الشبكة الكثيرة، الخطوط المعيقة للعرض. هذه مشاكل تقنية تحتاج مطوراً.
4
تحقق من Filmstrip عبر WebPageTest
استخدم webpagetest.org لرؤية الـ Filmstrip: ماذا يرى المستخدم في الثانية 1، 2، 3؟ هذا يكشف بوضوح لماذا يشعر المستخدم بالبطء حتى لو الأرقام جيدة.
5
قارن مع المنافسين
افحص أفضل 3 منافسين لك في نفس الكلمات المفتاحية. إذا كانت نتيجتهم أعلى بكثير، هذا تهديد مباشر لترتيبك. إذا كنت أفضل منهم، فأنت في وضع جيد حالياً.
الأخطاء الشائعة
أكثر الأخطاء شيوعاً وكيفية إصلاحها
بعد تحليل مئات المواقع العربية، هذه هي التنبيهات الأكثر تكراراً في أداة PageSpeed وما الذي يسببها وكيف تحلها:
Render-blocking resources
ملفات CSS أو JS في الـ head تمنع المتصفح من عرض الصفحة حتى يُحملها بالكامل. هذا أكثر سبب شائع لـ LCP سيء.
أضف defer/async للـ JS، وقسّم الـ CSS لـ Critical وغير Critical
Serve images in next-gen formats
الموقع يستخدم صور JPEG/PNG عوضاً عن WebP أو AVIF الأحدث. الصور تمثل في المتوسط 60% من حجم الصفحة.
حوّل جميع الصور لـ WebP باستخدام Squoosh أو TinyPNG
الموقع يحمّل أكواد JS لا تستخدمها الصفحة الحالية. الإضافات الثقيلة مثل Sliders والـ Builders المرئية أشهر أسبابها.
استخدم Code Splitting أو أزل الإضافات غير الضرورية
القوالب تحمّل ملفات CSS ضخمة للموقع بأكمله رغم أن كل صفحة تستخدم 10% منها فقط. يزيد وقت الـ Render ويبطئ FCP.
استخرج Critical CSS وضعه Inline، أو استخدم PurgeCSS
Reduce initial server response time (TTFB)
السيرفر يأخذ وقتاً طويلاً للرد. يحدث بسبب استضافة بطيئة، قواعد بيانات بطيئة، أو غياب التخزين المؤقت.
انتقل لاستضافة أفضل أو فعّل Page Cache + Object Cache
Avoid chaining critical requests
الصفحة تحتاج لتحميل ملف A ثم ليتحمل ملف B ثم ليتحمل ملف C. هذه السلسلة تضاعف وقت التحميل بشكل كبير.
استخدم Preload للموارد الحيوية وقلل عمق الاعتمادية
الخطوات العملية
كيف تحصل على 100/100 فعلياً؟
للوصول للعلامة الخضراء، يجب عليك معالجة التنبيهات التي تظهر في أسفل أداة PageSpeed. إليك أهم الخطوات العملية للقضاء على هذه التنبيهات:
1
تحسين الصور (الصيغة والأبعاد)
حول جميع صورك إلى صيغة WebP أو AVIF. تأكد من إعطاء عرض وطول (Width/Height) لكل صورة لمنع اهتزاز الصفحة (CLS). قم بتأجيل تحميل الصور السفلية عبر خاصية loading="lazy". والصورة الأولى في الصفحة (LCP) يجب أن تحمّل بـ fetchpriority="high".
2
تأجيل أكواد الجافاسكريبت (Defer JS)
أكواد التتبع والإعلانات (Google Analytics, Adsense) توقف عملية عرض الصفحة. استخدم خصائص defer أو async، أو الأفضل تأخير تحميلها (Delay) حتى يقوم المستخدم بالتحريك (Scroll). هذا يحل مشكلة الـ INP وTBT تماماً.
3
تفعيل الكاش (Caching) و CDN
استخدم شبكة توصيل محتوى (مثل Cloudflare) لتقديم ملفاتك من سيرفرات قريبة لزوارك، وفعل التخزين المؤقت (Page Caching) لتقليل زمن استجابة السيرفر (TTFB) مما يرفع مقياس LCP بشكل ملحوظ.
4
تقليل حجم الـ CSS غير المستخدم
القوالب الجاهزة تحمل ملفات تصميم ضخمة. استخدم أدوات لعمل Minify، والأفضل استخراج (Critical CSS) ووضعه داخل الـ <head> لسرعة عرض الجزء العلوي للمستخدم.
5
تحسين الخطوط (Font Optimization)
الخطوط الخارجية من Google Fonts تسبب CLS وتبطئ FCP. استخدم font-display: swap لعرض نص بديل ريثما يتحمل الخط. الأفضل هو تحميل ملفات الخطوط على سيرفرك مباشرة واستخدام preload في الـ head.
6
تفعيل Preconnect للخدمات الخارجية
إذا كان موقعك يستخدم خدمات خارجية (Google Fonts, Analytics, CDN)، أخبر المتصفح مسبقاً بالاتصال بها قبل الحاجة إليها باستخدام <link rel="preconnect"> في أعلى الـ head.
أمثلة برمجية
أمثلة برمجية عملية جاهزة للنسخ
إليك أكواداً جاهزة يمكنك تطبيقها مباشرة في مشروعك لتحسين مقاييس PageSpeed:
تحميل صورة LCP بأعلى أولوية
<!-- صورة Hero بأعلى أولوية تحميل -->
<link rel="preload" as="image"
href="/images/hero.webp"
fetchpriority="high">
<img
src="/images/hero.webp"
width="1200"
height="630"
alt="وصف الصورة"
fetchpriority="high"
decoding="sync"
>
<!-- باقي الصور: Lazy Load -->
<img
src="/images/other.webp"
width="800"
height="450"
loading="lazy"
decoding="async"
>
تحسين تحميل الخطوط
<!-- في <head> — Preconnect + Preload للخط -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
/* في CSS: استخدم font-display: swap */
@font-face {
font-family: 'Cairo';
src: url('/fonts/cairo.woff2') format('woff2');
font-display: swap; /* مهم جداً لمنع CLS */
font-weight: 400 900; /* Variable font */
}
تأجيل الجافاسكريبت الثقيل
// تحميل الأكواد الثقيلة بعد تفاعل المستخدم
function loadScriptsOnInteraction() {
// Google Analytics
const script = document.createElement('script');
script.src = 'https://www.googletagmanager.com/gtag/js';
script.async = true;
document.head.appendChild(script);
}
// تنفيذ عند أول تفاعل فقط (scroll/click/touchstart)
['scroll', 'mousemove', 'touchstart'].forEach(evt => {
window.addEventListener(evt, loadScriptsOnInteraction, {
once: true,
passive: true
});
});
الاستضافة
دور الاستضافة في سرعة موقعك — اختر بحكمة
كثيرون يضيعون وقتهم في ضغط الصور وتأجيل الـ JS بينما سيرفرهم بطيء أصلاً. TTFB الجيد (أقل من 200ms) هو الأساس — لا يمكنك بناء موقع سريع على سيرفر بطيء.
| نوع الاستضافة |
متوسط TTFB |
مناسب لـ |
السعر التقريبي |
التوصية |
| Shared Hosting (مشتركة) |
800ms – 2s |
مواقع شخصية صغيرة |
$1-5 / شهر |
ضعيفة للسيو |
| Cloud VPS (سحابي) |
200 – 500ms |
مواقع متوسطة |
$5-20 / شهر |
جيدة مع إعداد |
| Managed WordPress |
50 – 200ms |
متاجر ومواقع نشطة |
$20-60 / شهر |
ممتازة |
| Edge + CDN (Cloudflare Pages) |
10 – 50ms |
مواقع Static / JAMstack |
مجاناً إلى $20 |
الأسرع عالمياً |
نصيحة الخبراء: اختر سيرفراً في منطقة جمهورك
إذا كان 80% من زوارك من السعودية والخليج، اختر استضافة بسيرفر في الإمارات أو أوروبا مع Cloudflare. السيرفر الأمريكي يضيف 150-300ms إضافية لكل طلب من المنطقة العربية — هذا يدمر TTFB تماماً.
ووردبريس
قائمة مراجعة شاملة لمواقع ووردبريس
ووردبريس يحتل 43% من مواقع الإنترنت، لكنه بدون تحسين صحيح يكون أحد أبطأ الأنظمة. إليك قائمة مراجعة شاملة مقسمة بحسب الأولوية:
التخزين والكاش (الأهم)
تفعيل Page Cache (WP Rocket / LiteSpeed)
تفعيل Object Cache (Redis أو Memcached)
تفعيل Browser Cache على السيرفر
ضبط GZIP/Brotli Compression
تفعيل CDN (Cloudflare على الأقل)
الصور والوسائط
تحويل جميع الصور لـ WebP
تحديد width و height لكل صورة
تفعيل Lazy Load للصور السفلية
استخدام responsive images مع srcset
حذف صور الوسائط القديمة غير المستخدمة
الجافاسكريبت والـ CSS
Minify وDeferJS للأكواد غير الحيوية
تأخير تحميل الإضافات الثقيلة
استخراج وتضمين Critical CSS
إزالة الإضافات غير المستخدمة
تحميل إضافات مشروطة (لصفحات معينة فقط)
قاعدة البيانات والسيرفر
تنظيف قاعدة البيانات (مسودات، مراجعات، ترانزنت)
تحديد عدد المراجعات في wp-config.php
استخدام PHP 8.2+ لأداء أعلى
تفعيل HTTP/2 أو HTTP/3 على السيرفر
تفعيل Heartbeat API Control لتقليل الطلبات
تجنب هذه الإضافات الثقيلة قدر الإمكان
بعض الإضافات الشائعة تضر بالأداء أكثر مما تنفع: Page Builders الثقيلة (Divi, WPBakery) تحمّل CSS/JS هائلاً. Sliders مثل Revolution Slider تضيف مئات الـ KB. إضافات الإحصاء المحلية تكتب لقاعدة البيانات مع كل زيارة. إضافات الأمان الثقيلة تضيف طلبات تحقق مع كل صفحة. بديل؟ استخدم Google Analytics، Gutenberg، ومكتبة Swiper خفيفة.
نصيحة الخبراء
وهم الـ 100/100 المطلق
أكبر خطأ يقع فيه أصحاب المواقع هو الهوس بالوصول إلى النتيجة 100/100 في المختبر (Lab Data) على حساب تجربة المستخدم أو جودة التصميم.
الرقم ليس كل شيء
الوصول لدرجة 90 هو أمر ممتاز. إذا كان الحصول على 100 يتطلب منك حذف الخطوط الجميلة، التخلي عن الصور التوضيحية، أو إزالة أكواد التتبع المهمة لتسويقك، فلا تفعل ذلك! جوجل يهتم بأن يمر موقعك باختبار Core Web Vitals في (البيانات الحقيقية)، وليس تحقيق 100 في اختبار محاكاة.
أهداف خاطئة شائعة
الهوس بالوصول لـ 100/100 في المختبر
تعطيل خطوط وصور جميلة لتوفير ms
إزالة Analytics لتحسين TBT
إهمال البيانات الحقيقية (CrUX)
تحسين الديسكتوب فقط وإهمال الجوال
الأهداف الصحيحة
الوصول لـ 90+ في المختبر (هدف واقعي)
إصلاح مشاكل CrUX الحقيقية أولاً
ضمان اجتياز Core Web Vitals الثلاثة
التركيز على تجربة المستخدم الفعلية
تحسين الجوال بأولوية قصوى
"السرعة هي ميزة (Feature) وليست مجرد مقياس سيو. اجعل موقعك سريعاً لأنك تحترم وقت زوارك وتود رفع مبيعاتك، وليس فقط لإرضاء مؤشرات جوجل."
فريق Seovix — خبراء تحسين أداء المواقع
الأسئلة الشائعة
أسئلة يسألها الجميع عن PageSpeed
إليك إجابات واضحة ومباشرة على أكثر الأسئلة التي تتكرر حول PageSpeed Insights وسرعة المواقع:
هل نتيجة 90+ كافية للسيو أم يجب الوصول لـ 100؟
نعم، نتيجة 90+ ممتازة تماماً للسيو. جوجل لا يشترط 100/100، بل يشترط اجتياز عتبات Core Web Vitals في البيانات الحقيقية (LCP أقل من 2.5s، INP أقل من 200ms، CLS أقل من 0.1). الوصول من 90 إلى 100 يتطلب جهداً كبيراً مقابل فائدة سيو صغيرة.
لماذا تختلف النتيجة في كل مرة أفحص فيها الموقع؟
هذا طبيعي تماماً! بيانات المختبر تتأثر بحمل السيرفر في لحظة الفحص، حركة مرور الشبكة، وتحميل الموارد الخارجية (Google Fonts, Analytics). الفارق المقبول هو 5-10 نقاط. إذا كان الفارق أكبر، قد يعاني السيرفر من عدم استقرار. افحص 3 مرات وخذ المتوسط.
موقعي يحصل على 95 في الديسكتوب لكن 55 في الجوال. هل هذا مشكلة؟
هذا الفارق شائع جداً وليس مقلقاً بالضرورة. الجوال يحاكي هاتفاً بطيئاً على شبكة 4G متعثرة. نتيجة 55 في المختبر قد تعني تجربة جيدة لمستخدمي الجوال الحقيقيين. الأهم هو تحقيق Core Web Vitals في البيانات الحقيقية. حاول رفع نتيجة الجوال إلى 70+ على الأقل.
هل تحسين PageSpeed يرفع ترتيبي في جوجل مباشرة؟
ليس بشكل فوري أو مباشر. Core Web Vitals هي عامل ترتيب "تعادل" (Tiebreaker) — أي عند تساوي المحتوى والروابط بينك وبين منافسك، تفوز بالسرعة. لكن التأثير الأكبر هو غير المباشر: موقع أسرع = زيارة أطول = تفاعل أكبر = إشارات إيجابية لجوجل = ترتيب أفضل على المدى البعيد.
موقعي جديد ولا تظهر بيانات حقيقية. ماذا أفعل؟
المواقع الجديدة أو ذات الزيارات المحدودة (أقل من 1000 زيارة شهرياً عبر Chrome) لن تظهر لها بيانات CrUX. في هذه الحالة، ركز على تحسين نتيجة المختبر للوصول إلى 85+ وتأكد أن مقاييس Core Web Vitals في المختبر تجتاز العتبات. مع نمو الزيارات ستظهر البيانات الحقيقية تدريجياً.
ما الفرق بين PageSpeed Insights وGTmetrix وWebPageTest؟
PageSpeed Insights هي الأداة الرسمية من جوجل وتحتوي على بيانات حقيقية (CrUX) — استخدمها لمعرفة وضعك الفعلي في السيو. GTmetrix أفضل لتحليل Waterfall وفهم تسلسل التحميل. WebPageTest للمختبرين المتقدمين مع تحكم كامل في بيئة الاختبار والموقع الجغرافي. الأفضل استخدام الثلاثة معاً.
هل إضافة أكواد التتبع (Analytics, Pixel) تضر بنتيجتي؟
نعم، لكن يمكن التقليل من تأثيرها بشكل كبير. Google Analytics 4 (gtag.js) يضيف ~30ms للـ TBT إذا حُمّل مباشرة. الحل: تأجيل تحميله لأول تفاعل من المستخدم (scroll/click)، استخدام Google Tag Manager مع تحسين الترتيب، أو استخدام Partytown library لتشغيل الأكواد الخارجية في Web Worker.
هل موقعك سريع بما يكفي للزوار؟
لا تعتمد على التخمين. استخدم أداة فحص سرعة الموقع من Seovix لتحليل أداء موقعك، اكتشاف أسباب البطء، والحصول على تقرير مفصل بالحلول باللغة العربية.
افحص سرعة موقعك مجاناً