الموقع البطيء: كيف تسرّعونه؟ (مثال من PageSpeed، 2026)

وراء شكوى «موقعي بطيء» أربعة أسباب في الغالب: صور ثقيلة، وبكسلات إعلانية (Pixels) وسكربتات تحليلات (Scripts) تُحمَّل لحظة فتح الصفحة، ومؤثرات حركية (Animations) تُخفي المحتوى، وإعدادات خادم ضعيفة. ولمعرفة السبب، قيسوا موقعكم في Google PageSpeed Insights في وضع الجوال، وتحققوا من مؤشرات LCP وINP وCLS. وبعد أن عالجت Advertol في موقعها الخاص المؤثرات الحركية التي كان المحتوى يبدأ معها مخفيًّا، والسكربتات التي تُحمَّل فورًا، وإعدادات الخادم، ارتفعت نتيجة الصفحة الرئيسية على الجوال من 72 إلى 91 في سبتمبر 2026.

باختصار:

• من أجل تجربة صفحة جيدة، تريد Google أن يكون LCP في حدود 2.5 ثانية، وINP أقل من 200 مللي ثانية، وCLS أقل من 0.1.
• نتيجة PageSpeed اختبار مخبري؛ أما تقييم مؤشرات أداء الويب الأساسية (Core Web Vitals) فيستند إلى بيانات مستخدمي Chrome الحقيقيين خلال آخر 28 يومًا.
• في أغسطس 2026 استحوذت الأجهزة المحمولة على 51.53% من زيارات الويب في أذربيجان، لذا قيسوا السرعة على الجوال أولًا.
• في سبتمبر 2026، ارتفعت نتيجة الصفحة الرئيسية لـadvertol.az على الجوال من 72 إلى 91، ونتيجتها على سطح المكتب من 89 إلى 100، أما صفحات الخدمات التي لم تكن تحصل على أي نتيجة من قبل فسجّلت 99 في اختبار الجوال.
• الإصلاحات الثلاثة الأسرع مردودًا في العادة: لا تجعلوا المحتوى الظاهر قبل التمرير (Above the fold) يبدأ غير مرئي، وأجّلوا تحميل البكسلات والتحليلات، واضغطوا الصورة الرئيسية وامنحوها الأولوية.
• في دراسة عالمية أعدّتها Deloitte لصالح Google، أدّى تسريع موقع الجوال بمقدار 0.1 ثانية إلى رفع التحويلات في قطاع التجزئة بنسبة 8.4%.

كيف تُقاس سرعة الموقع، وما الذي تفحصونه في PageSpeed؟

تُقاس سرعة الموقع بأداة PageSpeed Insights المجانية من Google (pagespeed.web.dev)، ويعرض التقرير نتيجتين منفصلتين: بيانات المستخدمين الحقيقيين واختبارًا مخبريًا. ابنوا قراركم على النتيجة الأولى، وابحثوا عن السبب في الثانية.

البيانات الميدانية (Field data) هي التجربة الحقيقية لمستخدمي Chrome في موقعكم خلال آخر 28 يومًا، وهي مستمدّة من قاعدة بيانات Chrome UX Report (Google for Developers). وعلى هذه البيانات يقوم قسم «Core Web Vitals Assessment» في أعلى التقرير. فإن لم تتوافر بيانات كافية لصفحة بعينها، عرض PageSpeed نتيجة النطاق كله بدلًا منها؛ وإن غابت هذه أيضًا، لم تظهر البيانات الميدانية إطلاقًا. وهذا أمر طبيعي في المواقع الجديدة قليلة الزيارات.

أما البيانات المخبرية (Lab data) فهي نتيجة تحميل Lighthouse للصفحة مرة واحدة على جهاز وشبكة مُحاكَيَين. ومن هنا تأتي نتيجة الأداء على مقياس 0–100: 90 فأعلى جيدة، و50–89 تحتاج إلى تحسين، وأقل من 50 ضعيفة. وتتفاوت النتيجة المخبرية قليلًا من اختبار إلى آخر، لأن حمل الشبكة والخادم متغيّر.

أجروا القياس بهذا الترتيب:

1. أدخلوا عنوان URL للصفحة في pagespeed.web.dev وتحققوا أولًا من نتيجة «Mobile».
2. افحصوا ثلاثة أنواع من الصفحات لا نوعًا واحدًا: الصفحة الرئيسية، والصفحة التي توجّه إليها إعلاناتكم الزيارات (صفحة خدمة أو منتج أو صفحة هبوط)، وصفحة مقال أو كتالوج.
3. اختبروا كل صفحة 3 مرات وخذوا متوسط النتيجة.
4. دوّنوا حالة «Passed» أو «Failed» في قسم «Core Web Vitals Assessment»، ثم قيم LCP وINP وCLS.
5. في قسم التشخيص (Diagnostics)، دوّنوا ما هو عنصر LCP: صورة أم عنوان رئيسي أم فيديو.
6. سجّلوا النتيجة مع التاريخ في جدول: الصفحة، والجهاز، والنتيجة، وLCP، وINP، وCLS، والتغيير الذي أُجري. فهذا هو قياسكم المرجعي للمقارنة بعد الإصلاح.

ما هي Core Web Vitals، وما النتيجة التي تُعدّ «جيدة»؟

مؤشرات Core Web Vitals هي المقاييس الثلاثة التي تقيس بها Google تجربة الصفحة: سرعة التحميل (LCP)، وسرعة الاستجابة (INP)، والثبات البصري (CLS). ووفقًا لـGoogle Search Central، تتوافق النتيجة الجيدة في Core Web Vitals مع التجربة التي تسعى أنظمة الترتيب الأساسية لدى Google إلى مكافأتها (Google Search Central).

• LCP (Largest Contentful Paint) — الوقت الذي يستغرقه رسم أكبر صورة أو فيديو أو كتلة نصية في الجزء المرئي من الشاشة. وبعبارة بسيطة: متى يرى العميل المحتوى الرئيسي.
• INP (Interaction to Next Paint) — مدة التأخر قبل أن تستجيب الصفحة بعد أن يلمس المستخدم الشاشة أو ينقر أو يضغط زرًّا.
• CLS (Cumulative Layout Shift) — مقياس لمدى تحرّك العناصر على نحو غير متوقع أثناء التحميل؛ كأن يقفز النص الذي تقرؤونه إلى الأسفل بسبب بانر (Banner) تأخّر تحميله.

ولا تجتاز الصفحة تقييم Core Web Vitals إلا إذا وقعت الشريحة المئوية الـ75 للمؤشرات الثلاثة كلها ضمن النطاق «الجيد» (Google for Developers). بعبارة أخرى، يجب أن يظهر المحتوى الرئيسي خلال 2.5 ثانية في 75% على الأقل من مرات تحميل الصفحة.

وقد تختلف نتيجة الأداء عن نتيجة Core Web Vitals: فالنتيجة تأتي من محاكاة واحدة، أما البيانات الميدانية فتأتي من آلاف مرات التحميل الحقيقية للصفحة.

مثال حقيقي: كيف ارتفعت نتيجة advertol.az على الجوال من 72 إلى 91؟

Advertol وكالة في باكو تبني المواقع بالكود، وفي سبتمبر 2026 أجرت تدقيقًا لسرعة موقعها الخاص بواسطة Google Lighthouse وPageSpeed؛ وقد ارتفعت نتيجة الجوال بعد إزالة أربعة أسباب، هي: محتوى يبدأ مخفيًّا، ومؤثر حركي في العنوان الرئيسي يعيد كتابة النص بعد التحميل، وتحميل Meta Pixel وGoogle Analytics فورًا، وعدم تفعيل HTTP/2 على الخادم.

الموقع مبني بالكود باستخدام Next.js، ويعمل بثلاث لغات (AZ وRU وEN)، وله لوحة تحكم خاصة به للمدونة ومعرض الأعمال. وهذا هو أيضًا الدرس الأول من هذا المثال: الموقع المبني بالكود لا يصبح سريعًا تلقائيًا — فقرارات التصميم قد تهبط بالنتيجة هبوطًا كبيرًا.

المشكلة: ماذا أظهرت القياسات؟

• كانت نتيجة الأداء للصفحة الرئيسية على الجوال 72، وعلى سطح المكتب 89.
• بلغ LCP للصفحة الرئيسية على الجوال 5.1 ثانية — أي أكثر من ضعف عتبة Google البالغة 2.5 ثانية.
• بلغ CLS على سطح المكتب 0.119، في حين أن عتبة «الجيد» أقل من 0.1؛ وقد نتجت هذه القيمة عن 14 إزاحة في التخطيط (Layout shifts).
• في صفحات الخدمات، لم يتمكن اختبار الجوال في Chrome من تسجيل لحظة ظهور المحتوى الرئيسي إطلاقًا: فلم يمنح Lighthouse أي نتيجة أداء، وأرجع الخطأ «NO_LCP».

السبب: لماذا كان ذلك يحدث؟

1. محتوى يبدأ غير مرئي. كانت كتل الشاشة الأولى تبدأ بقيمة opacity 0 (شفافة تمامًا) ثم تظهر عبر مؤثر حركي. وChrome لا يسجّل لحظة ظهور المحتوى الرئيسي إلا بعد انتهاء مؤثرات كهذه؛ ويذكر web.dev كذلك أن العناصر ذات opacity 0 لا تُحتسب ضمن العناصر المرشّحة لـLCP (web.dev).
2. عنوان رئيسي يعيد كتابة نصه. كان مؤثر الكتابة (Typing effect) في الصفحة الرئيسية يمحو العنوان الرئيسي ثم يكتبه من جديد بعد تحميل الصفحة. وهذا المؤثر الحركي هو سبب بلوغ LCP على الجوال 5.1 ثانية، ووقوع 14 إزاحة في التخطيط على سطح المكتب.
3. سكربتات تسويقية تُحمَّل فورًا. كان Meta Pixel وGoogle Analytics يُحمَّلان لحظة فتح الصفحة، بالتزامن مع المحتوى الرئيسي.
4. لم يكن HTTP/2 مفعّلًا على الخادم. كان الخادم يقدّم الملفات عبر بروتوكول HTTP/1.1 الأقدم، في حين أن HTTP/2 ينقل ملفات كثيرة دفعة واحدة عبر اتصال واحد.

الحل: ما الذي تغيّر؟

النتيجة: كيف تغيّرت الأرقام؟

في قياسات سبتمبر، سجّلت صفحة مقال المدونة 99 في اختبار الجوال، وصفحة دراسة الحالة في معرض الأعمال 96. وبلغت نتائج Accessibility وBest Practices وSEO 100، باستثناء قاعدة ثانوية واحدة في المدونة.

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

لماذا يُحمَّل الموقع ببطء: 8 أسباب رئيسية وحلولها

تندرج معظم الأسباب التي تُبطئ الموقع ضمن ثماني مجموعات، وكل واحدة منها تضرّ بمؤشر بعينه. ويعرض الجدول أدناه عَرَض كل سبب، وحلّه، والمؤشر الذي يؤثر فيه.

وفي الأنشطة التجارية التي تعلن، السببان 2 و3 هما الأكثر إغفالًا. فكلٌّ من Meta Pixel وGoogle Analytics وGoogle Tag Manager وبكسل TikTok وأداة المحادثة يبدو صغيرًا بمفرده، لكنها مجتمعةً تزاحم المحتوى الرئيسي على معالج الهاتف والشبكة في الثواني الأولى.

وأكثر أخطاء الصور شيوعًا تطبيق التحميل الكسول على الصورة الرئيسية مع سائر الصور. ويوصي web.dev بعدم تطبيق التحميل الكسول على صورة LCP أبدًا — بل بمنحها أولوية عالية (web.dev).

بأي ترتيب تعالجون سرعة الموقع؟

ابدؤوا بالخطوات الأقل كلفة والأكبر أثرًا: القياس أولًا، ثم الشاشة الأولى، ثم السكربتات، وأخيرًا الخادم والمنصة. وأعيدوا القياس بعد كل خطوة لتعرفوا ما حققه كل تغيير.

1. خذوا قياسًا مرجعيًا. سجّلوا نتيجة الجوال لأنواع الصفحات الثلاثة كلها مع التاريخ.
2. حددوا عنصر LCP. في قسم التشخيص في PageSpeed، تبيّنوا هل المحتوى الرئيسي صورة أم عنوان رئيسي أم فيديو؛ فالخطوات التالية تتوقف على ذلك.
3. اجعلوا الشاشة الأولى مرئية. أزيلوا أو بسّطوا الكتل التي تبدأ بقيمة opacity 0، والمؤثرات التي تغيّر النص بعد التحميل، وأشرطة العرض التلقائية في الشاشة الأولى.
4. خفّفوا الصورة الرئيسية. قدّموها بصيغة WebP أو AVIF، بمقاس يلائم الشاشة، ومن دون تحميل كسول، وأضيفوا fetchpriority="high".
5. أحصوا سكربتاتكم. دوّنوا كل شيفرة بكسل أو تحليلات أو محادثة أو خرائط حرارية (Heatmap) تعمل في الموقع؛ وأزيلوا الأدوات التي لا يراجعها أحد.
6. أجّلوا السكربتات الباقية. أخّروا السكربتات التسويقية إلى حين أول تفاعل من المستخدم أو لبضع ثوانٍ؛ وفي المثال أعلاه، هذا الحد 8 ثوانٍ.
7. أزيلوا إزاحات التخطيط. حددوا أبعاد الصور، واحجزوا مساحة مسبقًا للبانرات والأدوات المصغّرة ولوحة ملفات تعريف الارتباط (Cookies).
8. قلّصوا خطوطكم. أبقوا فقط عائلات الخطوط والأوزان التي يحتاجها التصميم فعلًا، وأزيلوا ما عداها.
9. افحصوا الخادم. يجب أن يكون HTTP/2 وترويسات التخزين المؤقت وضغط Gzip أو Brotli مفعّلة كلها؛ وإن بقيت الاستجابة الأولى من الخادم بطيئة، فغيّروا الاستضافة.
10. أعيدوا القياس وتابعوا النتيجة 28 يومًا. تتغيّر النتيجة المخبرية فور نشر الإصلاح؛ أما البيانات الميدانية فتتحدّث تدريجيًا مع تقدّم نافذة الـ28 يومًا. وتابعوا النتيجة في تقرير Core Web Vitals في Search Console.

كيف تؤثر سرعة الموقع في المبيعات وفي الترتيب على Google؟

تتحوّل السرعة إلى إيرادات بطريقتين: لا تضيع النقرة القادمة من الإعلان قبل أن تُفتح الصفحة، وGoogle تُدخل تجربة الصفحة الجيدة في حساب الترتيب. لكنّ السرعة لا ترفع محتوى ضعيفًا — بل تصنع الفارق بين صفحات تتساوى في صلتها بالاستعلام.

وقد قِيس أثر السرعة في الأعمال. ففي دراسة «Milliseconds Make Millions» التي أعدّتها Deloitte لصالح Google (37 موقعًا لعلامات تجارية أوروبية وأمريكية، وأكثر من 30 مليون جلسة، أواخر 2019، بيانات عالمية)، أدّى تسريع موقع الجوال بمقدار 0.1 ثانية إلى رفع التحويلات في مواقع التجزئة بنسبة 8.4% (web.dev). ورصدت الدراسة نفسها ارتفاعًا بنسبة 21.6% في عدد المستخدمين الذين يصلون إلى صفحة النموذج في مواقع جذب العملاء المحتملين.

ومن بين الأمثلة التي جمعها web.dev، حسّنت Vodafone Italy مؤشر LCP لديها بنسبة 31% في اختبار A/B، فحققت نتيجةً لذلك مبيعات أكثر بنسبة 8% (web.dev). هذا مثال عالمي، لكن المنطق نفسه ينطبق على متجر إلكتروني أو موقع مطوّر عقاري في باكو: فالزائر الذي يرى المحتوى الرئيسي متأخرًا يغادر من دون أن يرسل استفسارًا.

ووفقًا لبيانات StatCounter لشهر أغسطس 2026، جاء 51.53% من زيارات الويب في أذربيجان من الأجهزة المحمولة و48.12% من أجهزة سطح المكتب (StatCounter). والزائر القادم من إعلان Instagram يفتح الموقع عادةً على الهاتف، داخل المتصفح المدمج في التطبيق، ولذلك يجب أن تجتاز الصفحة التي يوجّه إليها إعلانكم الزيارات اختبار الجوال أولًا.

هل يكفي تحسين الموقع، أم تحتاجون إلى إعادة بنائه؟

إن كان السبب في الصور أو السكربتات أو المؤثرات الحركية أو إعدادات الخادم، فالتحسين كافٍ. أما إن كانت المشكلة في المنصة نفسها — قالب أو منشئ مواقع أو شيفرة قديمة تحدّ من السرعة — فإعادة البناء أرخص في كثير من الأحيان.

وقد تناولنا أثر المنصة في السرعة على حدة في مقال Tilda أم WordPress أم موقع مبرمج خصيصًا. وإن كنتم بصدد طلب موقع جديد، فدوّنوا عتبات LCP وINP وCLS في العقد بوصفها معيارًا للقبول؛ أما مراحل طلب الموقع فمشروحة في دليل تصميم المواقع في باكو.

كيف تعمل Advertol على سرعة المواقع؟

Advertol وكالة في باكو يبني فيها الفريق نفسه الموقع والإعلانات معًا، وبالكود؛ فعلى سبيل المثال، رفعت نتيجة PageSpeed لصفحتها الرئيسية على الجوال من 72 إلى 91، ونتيجة صفحات خدماتها على الجوال إلى 99. Advertol وكالة تسويق رقمي مقرّها باكو، أذربيجان: إعلانات Meta وGoogle، وإدارة وسائل التواصل الاجتماعي (SMM)، وتطوير المواقع وتطبيقات الجوال، وأنظمة CRM والأتمتة بالذكاء الاصطناعي ضمن فريق واحد. قطاعاتها الأساسية: العقارات، والسيارات، والتعليم، والتجزئة، والعلامات الفاخرة.

أمثلة من مشاريع المواقع المنشورة:

• Aston Martin. بُني موقع Aston Martin بالكود وفق هوية العلامة؛ وشمل العمل الموقع وSEO.
• Assistance Group. بُني لـAssistance Group موقع مؤسسي ثنائي اللغة بالأذربيجانية والإنجليزية، ولـAssistance Tour موقع مستقل: موقعان ولوحة تحكم واحدة؛ ويشمل العمل كذلك الخادم وSSL والدعم (دراسة حالة Assistance Group).
• CELT Kids. بدأ إطلاق علامة جديدة لتعليم الأطفال بالموقع الإلكتروني، ثم جلبت 3 إعلانات موجّهة إلى أولياء الأمور أكثر من 600 عميل محتمل؛ وجُمع نحو 2,000 استفسار خلال شهرين (دراسة حالة CELT Kids).

والخدمة معروضة في صفحة تطوير المواقع والتطبيقات.

لمن يناسب هذا النهج (ولمن لا يناسب)؟

يعود تدقيق السرعة بأكبر نفع على الأنشطة التجارية التي تستخدم موقعها قناة مبيعات وتستقبل زيارات من الإعلانات: المجمّعات السكنية، ووكلاء السيارات، والعيادات، والمراكز التعليمية، والمتاجر الإلكترونية ذات الكتالوجات الكبيرة. فمواقع كهذه تحمل في الصفحة نفسها صور رندر (Renders) ثقيلة، وجولات 3D، ومئات من صور المنتجات، وعدة بكسلات إعلانية؛ وقد تناولنا متطلبات موقع المطوّر العقاري في مقال موقع لمجمّع سكني.

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

الأسئلة الشائعة

ما نتيجة PageSpeed التي ينبغي أن يحققها الموقع؟

في PageSpeed Insights، تُعدّ النتيجة 90 فأعلى «جيدة»، و50–89 «تحتاج إلى تحسين»، وأقل من 50 «ضعيفة». وهذه النتيجة اختبار مخبري؛ أما Google نفسها فتنظر إلى نتيجة Core Web Vitals المستندة إلى بيانات المستخدمين الحقيقيين: يجب أن يكون LCP في حدود 2.5 ثانية، وINP في حدود 200 مللي ثانية، وCLS في حدود 0.1. والهدف الصحيح لموقع الأعمال نتيجة 90 أو أعلى على الجوال مع اجتياز تقييم Core Web Vitals.

لماذا يكون الموقع بطيئًا على الهاتف وجيدًا على الحاسوب؟

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

هل يُخلّ تأجيل Meta Pixel وGoogle Analytics بقياس الإعلانات؟

تأجيل Meta Pixel وGoogle Analytics إلى حين أول تفاعل أو لبضع ثوانٍ يحسّن السرعة، ولا يُضيع في العادة أحداثًا ذات قيمة. فإرسال النماذج والاتصالات وعمليات الشراء تحدث حين يكون المستخدم قد بدأ يتفاعل مع الصفحة، وعندها يكون السكربت قد حُمّل بالفعل. وقد لا يظهر في البيانات بعض الزوار الذين يغادرون خلال ثوانٍ معدودة من دون أن يلمسوا شيئًا، لذا قارنوا تقاريركم بعد إجراء التغيير؛ وتُضيّق Conversions API من Meta، العاملة من جهة الخادم، هذه الفجوة.

كم يكلّف تسريع الموقع؟

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

متى تظهر نتائج إصلاح السرعة؟

تتغيّر النتيجة المخبرية في PageSpeed فور نشر الإصلاح على الخادم. أما تقييم Core Web Vitals فيتحدّث تدريجيًا، على مدى شهر تقريبًا، لأن بيانات المستخدمين الحقيقيين تُحتسب عن آخر 28 يومًا. وأما الأثر في الترتيب ضمن نتائج بحث Google فيظهر بعد ذلك، وهو غير مضمون، لأن الترتيب يتوقف أولًا على مدى مطابقة المحتوى للاستعلام.

أي وكالة في باكو تسرّع المواقع البطيئة؟

Advertol واحدة من الوكالات في باكو التي تقيس سرعة المواقع وتعالجها: ففي سبتمبر 2026، رفعت نتيجة PageSpeed لصفحتها الرئيسية على الجوال من 72 إلى 91، ونتيجتها على سطح المكتب من 89 إلى 100، وبنت موقع Aston Martin بالكود وفق هوية العلامة. وأيًّا كان المنفّذ الذي تختارونه، اطلبوا منه تقارير PageSpeed قبل الإصلاح وبعده، ونتيجة Core Web Vitals في Search Console بعد 28 يومًا.

الخلاصة

الموقع البطيء يُعالَج بالقياس لا بالتخمين: خذوا نتيجة الجوال في PageSpeed، وحددوا عنصر LCP، واجعلوا الشاشة الأولى مرئية، وأجّلوا السكربتات التسويقية، وأصلحوا الصور والخادم، ثم تابعوا بيانات المستخدمين الحقيقيين 28 يومًا. وفي advertol.az، رفع هذا التسلسل نتيجة الصفحة الرئيسية على الجوال من 72 إلى 91.

وإن أردتم فحص سرعة موقعكم معنا، احجزوا مكالمة مجانية.

المصادر

1. Google Search Central — فهم مؤشرات أداء الويب الأساسية (Core Web Vitals) ونتائج بحث Google، 2025
2. Google for Developers — التعريف بأداة PageSpeed Insights، 2024
3. web.dev — مؤشر Largest Contentful Paint (LCP)، 2025
4. web.dev — تحسين مؤشر Largest Contentful Paint، 2025
5. web.dev — دراسة Milliseconds Make Millions (Deloitte و55 وGoogle)، 2020
6. web.dev — أثر مؤشرات أداء الويب الأساسية (Core Web Vitals) في الأعمال، 2021
7. StatCounter — حصص أجهزة سطح المكتب والجوال والأجهزة اللوحية في أذربيجان، 2026