مؤشرات الويب الأساسية (Core Web Vitals)

الخلاصة — Core Web Vitals هي ثلاثة مقاييس تستخدمها Google لقياس مدى إحساس المستخدمين الحقيقيين بالصفحة: سرعة التحميل (LCP)، وسرعة الاستجابة عند النقر أو اللمس (INP)، ومقدار القفزات أثناء التحميل (CLS). «جيد» يعني LCP أقل من 2,5 ثانية، وINP أقل من 200 مللي ثانية، وCLS أقل من 0,1. قد تدفع الترتيب قليلًا — لكن المحتوى الجيد أهم بكثير.

ما هي Core Web Vitals

تريد Google مكافأة الصفحات السهلة الاستخدام، لذلك اختزلت «تجربة الصفحة الجيدة» إلى ثلاثة أمور قابلة للقياس. وتُسمى هذه الأمور مجتمعة Core Web Vitals (وغالبًا ما تختصر إلى CWV):

• Largest Contentful Paint (LCP) — التحميل. المدة حتى يظهر أكبر عنصر على الشاشة (عادةً صورة رئيسية أو عنوان). الجيد هو ≤ 2,5 ثانية.
• Interaction to Next Paint (INP) — الاستجابة. عند النقر على زر أو الكتابة، المدة حتى تتفاعل الصفحة. الجيد هو ≤ 200 مللي ثانية.
• Cumulative Layout Shift (CLS) — الاستقرار البصري. مقدار قفز الصفحة أثناء تحميلها (مثل إعلان يدفع النص إلى الأسفل لحظة استعدادك للنقر). الجيد هو ≤ 0,1.

من أين تأتي الدرجات

تأتي الدرجات التي تستخدمها Google فعلًا من أشخاص حقيقيين يزورون موقعك عبر Chrome، لا من اختبار تجريه بنفسك. تجمع Google هذه البيانات، وتُحكم على الصفحة وفق تجربة 75% من الزوار. لذلك لا يمكنك «اجتياز» الاختبار بنتيجة سريعة واحدة على جهازك؛ بل يجب أن يحصل معظم زوارك الحقيقيين على تجربة جيدة. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

لهذا لا تضمن النتيجة المثالية في أداة اختبار السرعة اجتيازك. فهذه الأدوات (مثل PageSpeed Insights وLighthouse) تجري اختبارًا مخبريًا واحدًا على هاتف محاكى — وهو ممتاز للعثور على المشكلات، لكنه ليس الأرقام التي ترتب Google على أساسها.

هل تؤثر في الترتيب؟

إلى حد ما. تقول Google إن Core Web Vitals تُستخدم في أنظمة الترتيب لديها، لكن لا توجد لها قيمة أو نسبة رسمية محددة، وتوضح Google أن المحتوى ذي الصلة يمكنه أن يتفوق على صفحة ذات تجربة أقل من المطلوب. فإذا لم يكن محتواك ذا صلة، فلن تنقذك السرعة والاستقرار. وكما قال John Mueller من Google: “it’s not going to make your site’s rankings jump up.” (ترجمة) «لن تجعل ترتيب موقعك يقفز.»

هذا رأيي الصريح بعد سنوات من العمل: لن ترى معظم المواقع فائدة كبيرة في الترتيب من مطاردة هذه الأرقام. لكن لا بأس بتحسين سرعة موقعك واستقراره — فالزوار يلاحظون ذلك، وتتحسن التحويلات حتى عندما لا يتحرك الترتيب.

أمر يخطئ فيه الناس

تنبيه بشأن الاسم القديم: قد ترى FID (First Input Delay) ما يزال مذكورًا بوصفه Core Web Vital. لقد انتهى — استبدل INP مؤشر FID في 12 مارس 2024. فإذا كانت أداة أو مقالة ما تزال تطلب منك تحسين FID فهي قديمة.

هل تريد النسخة الأعمق — العتبات الدقيقة، والفرق بين بيانات الحقل والمختبر، وحجم وزنها الحقيقي في الترتيب، والأداة المناسبة لكل حالة؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — Core Web Vitals هي ثلاثة مقاييس لتجربة المستخدم تقاس ميدانيًا: LCP (التحميل، «جيد» ≤ 2,5 ث)، وINP (الاستجابة، ≤ 200 مللي ثانية)، وCLS (الاستقرار البصري، ≤ 0,1)، ويُحكم على كل منها عند المئين 75 لمستخدمي Chrome الحقيقيين (CrUX) عبر نافذة متحركة مدتها 28 يومًا. العتبات واحدة للهاتف وسطح المكتب، لكن Google تقيم كل فئة على حدة، وتتوقع أن تكون المقاييس الثلاثة كلها جيدة، لا مقياسًا واحدًا فقط. استبدل INP مؤشر FID في 12 مارس 2024. تقول Google إن أنظمة الترتيب لديها تستخدم Core Web Vitals، لكن لا توجد نسبة رسمية للوزن أو «كاسر تعادل» مرتبط بها — فالنتيجة الجيدة لا تضمن ترتيبًا أفضل، وقد تفوز الصلة. درجات المختبر (Lighthouse/PSI) قياسات تشخيصية وغالبًا لا تطابق بيانات الحقل. أما TTFB وFCP فهما «Web Vitals أخرى» تشخيصية، وTBT وSpeed Index بدائل مخبرية.

ما الذي يُعد Core Web Vital

تعرّف Google Core Web Vitals بأنها “the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (ترجمة) «مجموعة Web Vitals الفرعية التي تنطبق على جميع صفحات الويب، وينبغي لجميع مالكي المواقع قياسها، وستظهر في جميع أدوات Google.» وهي ثلاثة بالضبط، يقيس كل منها بُعدًا مختلفًا من تجربة الصفحة:

تقيّم Google عتبات «الجيد» الثلاث عند المئين 75: LCP عند 2,5 ثانية، وINP عند 200 مللي ثانية، وCLS عند 0,1. ولا تُعد الصفحة «جيدة» إجمالًا إلا بعد أن تتجاوز العتبات الثلاث كلها عند p75، لا واحدة أو اثنتين فقط. والعتبات نفسها واحدة للهاتف وسطح المكتب، مع أن Google تقيّم كل فئة جهاز وتبلغ عنها منفصلة. Evidence for this claim Core Web Vitals are assessed at the 75th percentile, with good thresholds of 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS. Scope: Current stable Core Web Vitals definitions from the Chrome team. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

كل ما عدا ذلك مما سمعت به — TTFB وFCP وTBT وSpeed Index — ليس Core Web Vital. وسأشرح المزيد عنها أدناه.

LCP — التحميل

يصف LCP بأنه “reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (ترجمة) «يسجل وقت رسم أكبر صورة أو كتلة نصية أو مقطع فيديو ظاهر في إطار العرض، قياسًا إلى لحظة انتقال المستخدم أول مرة إلى الصفحة.» عمليًا، يكون عنصر LCP عادةً صورة رئيسية أو صورة خلفية كبيرة أو كتلة العنوان. انتبه إلى أنه أكبر عنصر مرئي — فقد تنتج أحجام العرض المختلفة عناصر LCP مختلفة، وهذا أحد أسباب اختلاف أرقام الحقل والمختبر.

INP — الاستجابة

يقيّم INP “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (ترجمة) «مدى استجابة الصفحة عمومًا لتفاعلات المستخدم، من خلال رصد زمن انتقال جميع تفاعلات النقر واللمس ولوحة المفاتيح طوال زيارة المستخدم للصفحة.» ويقيس التفاعل كاملًا: تأخر الإدخال ← معالجة معالج الحدث ← زمن رسم الإطار التالي.

هذا هو التحسن الكبير مقارنة بالمقياس الذي استبدله. يتفوق INP على FID لأنه يراقب كل التفاعلات، لا التفاعل الأول فقط — فقد كان FID يقيس تأخر إدخال التفاعل الأول وحده. أصبح INP Core Web Vital في 12 مارس 2024، مستبدلًا First Input Delay (FID). Evidence for this claim INP became a Core Web Vital and replaced FID on March 12, 2024. Scope: Chrome and Google tooling transition from FID to INP. Confidence: high · Verified: 2026-07-14 web.dev: INP launch وأزيل FID من Search Console في ذلك اليوم. لقد أُوقف نهائيًا؛ فلا تواصل تحسينه.

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

CLS — الاستقرار البصري

يُعرَّف CLS بأنه “is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (ترجمة) «مقياس لأكبر دفعة من درجات تحوّل التخطيط بين جميع التحولات غير المتوقعة التي تقع طوال دورة حياة الصفحة.» وتجمع «الدفعة» (نافذة الجلسة) التحولات التي تحدث بفارق لا يتجاوز ثانية واحدة، ضمن نافذة إجمالية أقصاها 5 ثوانٍ. ومن الأسباب المعتادة التي تسميها Google: “images or videos with unknown dimensions,” (ترجمة) «صور أو مقاطع فيديو ذات أبعاد غير معروفة»، و*“fonts that render larger or smaller than its initial fallback,”* (ترجمة) «خطوط تظهر أكبر أو أصغر من خطها الاحتياطي الأولي»، و*“third-party ads or widgets that dynamically resize themselves.”* (ترجمة) «إعلانات أو أدوات مصغرة تابعة لجهات خارجية تغيّر حجمها ديناميكيًا.»

بيانات الحقل مقابل بيانات المختبر — القياس والتشخيص

هذا هو الفرق الذي يسبب أكبر قدر من الالتباس، لذا كن دقيقًا بشأنه.

• بيانات الحقل (CrUX) هي “data collected from the real users visiting your site.” (ترجمة) «بيانات جُمعت من المستخدمين الحقيقيين الذين يزورون موقعك.» وتُعرض عند المئين 75 عبر نافذة متحركة مدتها 28 يومًا، مع فصل الهاتف عن سطح المكتب. تمثل Core Web Vitals هذا النوع من التجربة الواقعية وتستخدمها أنظمة ترتيب Google. وهي تعكس الأجهزة والشبكات وحالات التخزين المؤقت وذاكرة التخزين المؤقت للرجوع والتقدم لدى المستخدمين الحقيقيين.
• بيانات المختبر هي “data collected in a controlled environment with predefined device and network settings” (ترجمة) «بيانات جُمعت في بيئة مضبوطة بإعدادات محددة سلفًا للجهاز والشبكة» — أي من هاتف محاكى واحد وذاكرة تخزين مؤقت باردة، بلا مستخدم حقيقي. ينتج Lighthouse والقسم المخبري في PageSpeed Insights هذه البيانات. وهي أداة تشخيصية للعثور على المشكلات، وليست قياسًا ميدانيًا. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

إرشاد Google نفسه: “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (ترجمة) «إذا كانت لديك بيانات حقل وبيانات مختبر لصفحة معينة، فاستخدم بيانات الحقل لترتيب أولويات جهودك.» كما أن درجة Performance من Lighthouse “often does not correlate with field Core Web Vitals.” (ترجمة) «غالبًا لا ترتبط بنتائج Core Web Vitals الحقلية.» وأقول الشيء نفسه في دليلي عن Core Web Vitals: بيانات المختبر أكثر فائدة للاختبار والتكرار، لأن بيانات CWV الحقلية متوسط متحرك لـ28 يومًا — ولن يظهر فيها أثر إصلاحك قبل مرور أسابيع.

قاعدة p75 ولماذا تهم

لا تجتاز الصفحة إلا إذا بلغ 75% من المستخدمين الحقيقيين عتبة «الجيد». إنها عتبة متسامحة لكنها واقعية عمدًا: حصل معظم زوارك (3 من 4) على تجربة جيدة، ولا تُعاقب الصفحة بسبب عدد قليل من المستخدمين على اتصالات سيئة. ولهذا لا تعني مشاهدة هاتفك يحمّل الصفحة خلال 1,8 ثانية شيئًا بمفردها — فالمهم هو p75 للجميع.

على مستوى الصفحة مقابل مستوى الأصل — لا تنخدع

تعرض أدوات كثيرة درجة على مستوى الأصل (متوسط الموقع كله) افتراضيًا، وقد تكون أكثر تفاؤلًا بكثير من درجات صفحاتك الفردية. في دراسة بيانات CWV (CrUX مع 5,2 مليون صفحة من Ahrefs Site Audit)، اجتازت 21,2% فقط من الصفحات الفردية العتبات الثلاث، مقابل 33% على مستوى الأصل. تقول وثائق تجربة الصفحة لدى Google إن أنظمتها تقيّم الصفحات عمومًا بصورة فردية، مع أنها تجري أيضًا تقييمات أوسع للموقع كله — لذلك قد يخفي أصل «ناجح» عددًا كبيرًا من الصفحات الفاشلة. وعندما توفر الأداة العرضين، لا تفترض أن متوسط الأصل يخبرك بما تفعله صفحة بعينها؛ راجع الرقم على مستوى الصفحة أيضًا.

هناك مشكلة مرتبطة: الصفحات التي لا تحصل على حركة مرور كافية لا تملك أي بيانات حقلية من CrUX، كما أن CrUX لا يضم إلا مستخدمي Chrome الذين وافقوا على إحصاءات الاستخدام (لا Chrome على iOS ولا المتصفحات الأخرى). هذه فجوة أهلية بيانات، وليست فشلًا — فغياب بيانات الحقل ليس كالحصول على درجة سيئة. أما كيفية تجميع أداة معينة للصفحات المتشابهة أو اختيارها بديلًا لعناوين URL قليلة الحركة (PSI أو Search Console أو CrUX API)، فتحددها وثائق ذلك المنتج لا قاعدة عالمية واحدة.

ما مقدار أهمية Core Web Vitals فعلًا للترتيب؟

إنها إشارة ترتيب مؤكدة — تقول Google إن أنظمة الترتيب لديها تستخدم Core Web Vitals. لكن ما لا تفعله وثائق Google الحالية هو إسناد وزن أو نسبة أو تسمية «كاسر تعادل» رسمية إلى هذه الإشارة، لذا احذر تكرار هذه الصياغات كما لو كانت كلمات Google نفسها.

في جانب «إنها حقيقية»: تقول وثائق Google إن Core Web Vitals “along with other page experience aspects, aligns with what our core ranking systems seek to reward,” (ترجمة) «تنسجم، إلى جانب جوانب أخرى من تجربة الصفحة، مع ما تسعى أنظمة الترتيب الأساسية لدينا إلى مكافأته»، وقد سجل John Mueller قوله إنها “more than a tie-breaker, but it also doesn’t replace relevance.” (ترجمة) «أكثر من مجرد عامل لكسر التعادل، لكنها لا تحل محل الصلة أيضًا.»

وفي جانب «لا تبالغ»: قال Mueller أيضًا “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that,” (ترجمة) «ليست Core Web Vitals عوامل ضخمة في الترتيب، وأشك في أنك سترى انخفاضًا كبيرًا بسببها وحدها»، وأضاف عبر LinkedIn في تحديث توثيق مارس 2024 أن “it’s not going to make your site’s rankings jump up.” (ترجمة) «لن تجعل ترتيب موقعك يقفز.» وتقول وثائق تجربة الصفحة لدى Google بوضوح: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (ترجمة) «يسعى بحث Google دائمًا إلى عرض المحتوى الأكثر صلة، حتى لو كانت تجربة الصفحة دون المستوى المطلوب.» كما تحذر وثائق 2024 من أن “trying to get a perfect score just for SEO reasons may not be the best use of your time.” (ترجمة) «قد لا تكون محاولة الحصول على درجة مثالية لأسباب تتعلق بـSEO وحده أفضل استثمار لوقتك.» Evidence for this claim Google says Core Web Vitals are used by ranking systems, while page experience does not override more relevant content. Scope: Google Search ranking guidance; no fixed weight or ranking-position effect is promised. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search Google: Page experience

قراءتي العملية: الصلة هي المهيمنة، ولم تضع Google رقمًا لحصة CWV، ولن ترى معظم المواقع فائدة كبيرة من العمل عليها من أجل الترتيب. ومع ذلك تستحق تحسينات تجربة المستخدم الأساسية التنفيذ للمستخدمين والتحويلات — كما تواصل المنصات (WordPress وCloudflare والأطر) تولّي جزء كبير من عبء التحسين تلقائيًا. وبالنسبة إلى الشركات الصغيرة والمحلية خصوصًا، لا ينبغي أن تكون هذه عادةً على رأس القائمة.

توضيح آخر من تحديث 2024: من إشارات تجربة الصفحة الأوسع، Core Web Vitals وحدها مؤكدة على أنها تساهم مباشرة في الترتيب. أما HTTPS وملاءمة الهاتف وعدم وجود النوافذ البينية المتطفلة ووضوح المحتوى فهي ممارسات جيدة، لكنها لا ترفع الترتيب مباشرة بالطريقة التي أوحت بها الوثائق سابقًا.

«Web Vitals الأخرى» — تشخيصية وليست Core

تظهر هذه المقاييس باستمرار ويُساء تصنيفها. لا واحد منها Core Web Vital:

• Time to First Byte (TTFB) — المدة حتى وصول أول بايت من الاستجابة. وهو “precedes every other meaningful loading performance metric” (ترجمة) «يسبق كل مقياس آخر ذي معنى لأداء التحميل»، ويسهم في LCP، لكن Google واضحة: “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold.” (ترجمة) «لأن TTFB ليس من مقاييس Core Web Vitals، فليس من الضروري تمامًا أن تبلغ المواقع عتبة TTFB المصنفة جيدًا.» (الجيد ≤ 0,8 ثانية). وهو مقياس تشخيصي.
• First Contentful Paint (FCP) — المدة حتى يُرسم أي محتوى. تشخيص تحميل مفيد (الجيد ≤ 1,8 ثانية)، لكنه ليس Core.
• Total Blocking Time (TBT) — بديل مخبري لـINP. فأدوات مثل Lighthouse “cannot measure INP” (ترجمة) «لا تستطيع قياس INP» بلا مستخدم حقيقي، لذلك تبلغ عن TBT بدلًا منه. وهو مقياس مخبري فقط.
• Speed Index — بديل مخبري لسرعة التحميل المحسوسة. خاص بـLighthouse.

استخدم هذه المقاييس لتصحيح الأخطاء. لا تبلغ عنها بوصفها Core Web Vitals ولا تتعامل مع عتباتها كحواجز للترتيب.

خرافة آن أوان التخلي عنها

قد ترى «Engagement Reliability» مطروحة بوصفها Core Web Vital جديدة. لا يوجد إعلان رسمي من Google عن مثل هذا المقياس — إنه متداول في محتوى جهات خارجية فقط. Core Web Vitals هي LCP وINP وCLS. وإلى أن تقول Google غير ذلك، فهذه هي القائمة.

كيف تقيس — وأي أداة لأي غرض

طابق الأداة مع المهمة:

• مرتبط بالترتيب (بيانات الحقل): PageSpeed Insights (يعرض بيانات حقل CrUX على مستوى الصفحة والأصل)، وتقرير Core Web Vitals في Google Search Console (يجمع الصفحات المتشابهة ويظهر الأنماط على مستوى الموقع)، وCrUX API / BigQuery (للتحليل المخصص وعلى مستوى البلد)، ومكتبة JavaScript web-vitals (لجمع RUM الخاص بك).
• تصحيح الأخطاء (بيانات المختبر): Lighthouse، ولوحة Performance في Chrome DevTools، والقسم المخبري في PSI. هذه الأدوات تعثر على السبب؛ ولا تحدد ترتيبك.

سير العمل الذي أقترحه: استخدم GSC لمعرفة مجموعات الصفحات الفاشلة في الحقل، ثم أكد ذلك عبر PageSpeed Insights على مستوى الصفحة، وبعدها انتقل إلى Lighthouse / DevTools للتشخيص والتكرار — مع معرفة أن أرقام الحقل لن تُحدَّث لمدة تصل إلى 28 يومًا.

إلى أين تذهب بعد ذلك: مجموعة موضوعات أداء الويب

هذه الصفحة هي الخريطة. وكل موضوع أدناه دليل تفصيلي مستقل.

Core Web Vitals الثلاثة

• Largest Contentful Paint — مقياس التحميل: ما الذي يُعد عنصر LCP، وهدف ≤2,5 ثانية، وكيف تجعله يُرسم أسرع.
• Interaction to Next Paint — مقياس الاستجابة الذي استبدل FID: تأخر الإدخال ومعالجة الحدث وتأخر العرض، وكيف تخفض كل واحد منها.
• Cumulative Layout Shift — مقياس الاستقرار البصري: نوافذ الجلسة والأسباب المعتادة (وسائط ذات أبعاد، وخطوط، وإعلانات محقونة)، وكيف تصل إلى ≤0,1.

المقاييس المساندة والتشخيصية

• Time to First Byte — زمن استجابة الخادم الذي يسهم في LCP؛ مفيد للتصحيح، وليس Core Web Vital.
• First Contentful Paint — وقت رسم أول محتوى؛ تشخيص للتحميل.
• Total Blocking Time — البديل المخبري الذي يستخدمه Lighthouse لتقريب INP.
• Speed Index — البديل المخبري لسرعة التحميل المحسوسة.

كيف تُقاس

• PageSpeed Insights — بيانات حقل (CrUX) مع تقرير Lighthouse مخبري في مكان واحد.
• Google Lighthouse — محرك المختبر/التشخيص خلف PSI وDevTools.
• Chrome UX Report (CrUX) — مجموعة بيانات المستخدمين الحقيقيين التي تستند إليها تقييمات Google.

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

ملخص الذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

• Core Web Vitals = ثلاثة مقاييس حقلية: LCP (التحميل، جيد ≤ 2,5 ث)، وINP (الاستجابة، ≤ 200 مللي ثانية)، وCLS (الاستقرار البصري، ≤ 0,1). كل ما عدا ذلك (TTFB وFCP وTBT وSpeed Index) ليس Core.
• يستند التقييم إلى بيانات الحقل: بيانات مستخدمي Chrome الحقيقيين عبر CrUX، عند المئين 75، خلال نافذة متحركة مدتها 28 يومًا. العتبات واحدة للهاتف وسطح المكتب لكنها تقاس منفصلة، وتتوقع Google أن تكون المقاييس الثلاثة كلها جيدة، لا واحدة فقط.
• استبدل INP مؤشر FID في 12 مارس 2024. تقاعد FID تمامًا؛ ويقيس INP كل التفاعلات، لا التفاعل الأول فحسب.
• أدوات المختبر (Lighthouse/PSI) تشخيصية وليست قياسات حقل، وغالبًا لا تطابق CWV الحقلية. استخدمها للعثور على الأسباب؛ فأرقام الحقل تتأخر حتى 28 يومًا.
• الفرق بين مستوى الصفحة والأصل مهم: تجتاز نحو 21,2% من الصفحات مقابل نحو 33% من الأصول (في دراسة CWV). تستخدم Google مستوى الصفحة؛ ومتوسط الأصل يخفي الصفحات الفاشلة.
• وزن الترتيب: مستخدمة لكن بلا وزن محدد. تقول Google إن أنظمة الترتيب تستخدم Core Web Vitals، بلا نسبة رسمية أو تسمية «كاسر تعادل»؛ الصلة هي المهيمنة، والنتيجة الجيدة ليست ضمانًا للترتيب. قال Mueller: “Core Web Vitals are not giant factors in ranking” (ترجمة) «ليست Core Web Vitals عوامل ضخمة في الترتيب». ووفق وثائق 2024، تساهم CWV وحدها مباشرة، لا HTTPS أو ملاءمة الهاتف أو النوافذ البينية.
• الخرافة التي ينبغي تجاوزها: «Engagement Reliability» ليست Core Web Vital مؤكدة.
• الأدوات: الحقل = PSI وتقرير GSC CWV وCrUX API وweb-vitals.js؛ والتصحيح = Lighthouse وDevTools وقسم PSI المخبري.

التوثيق الرسمي

وثائق من مصادر Google الأولية.

web.dev (فريق Chrome)

• Web Vitals — المبادرة والمقاييس الثلاثة وقاعدة p75، ولماذا يُعد TTFB وFCP «Web Vitals أخرى».
• سرعة عرض أكبر محتوى (LCP) — التعريف والعتبات وعناصر LCP المؤهلة.
• مدة الاستجابة للتفاعل حتى الرسم التالي (INP) — التعريف والعتبات وتقسيم تأخر الإدخال ← المعالجة ← العرض.
• متغيرات التصميم التراكمية (CLS) — التعريف ونوافذ الجلسة والأسباب المعتادة.
• تحديد عتبات مقاييس Core Web Vitals — سبب اختيار عتبة «الجيد» والمئين 75 لكل مقياس.
• الفروق بين بيانات المختبر والحقل — سبب اختلاف أرقام الحقل (CrUX) والمختبر (Lighthouse).
• مسارات عمل وأدوات Core Web Vitals — الأداة التي تبلغ عن بيانات الحقل مقابل المختبر.
• ترقية INP إلى Core Web Vitals (مايو 2023) — إعلان استبدال FID بـINP.
• أصبح INP رسميًا من Core Web Vitals (12 مارس 2024) — تأكيد إطلاقه.
• TTFB وFCP — «Web Vitals الأخرى» التشخيصية.

Google Search Central

• فهم Core Web Vitals ونتائج بحث Google — صلة CWV بالترتيب.
• فهم تجربة الصفحة في نتائج بحث Google — صورة تجربة الصفحة الأوسع وتأطير «الصلة تفوز».
• إدخال INP ضمن Core Web Vitals (مايو 2023) — إعلان Search Central.

Chrome للمطورين

• تقرير تجربة مستخدم Chrome (CrUX) — مجموعة بيانات المستخدمين الحقيقيين والأهلية ونافذة 28 يومًا.

اقتباسات من المصدر

تصريحات مسجلة من Google. كل رابط يقفز إلى المقطع المقتبس في صفحة المصدر.

Google — ما هي Core Web Vitals

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (ترجمة) «Core Web Vitals هي مجموعة Web Vitals الفرعية التي تنطبق على جميع صفحات الويب، وينبغي لجميع مالكي المواقع قياسها، وستظهر في جميع أدوات Google.» — Philip Walton، web.dev. الانتقال إلى الاقتباس
• “LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (ترجمة) «يسجل LCP وقت رسم أكبر صورة أو كتلة نصية أو مقطع فيديو ظاهر في إطار العرض، قياسًا إلى لحظة انتقال المستخدم أول مرة إلى الصفحة.» — web.dev (LCP). الانتقال إلى الاقتباس
• “INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (ترجمة) «INP مقياس يقيّم مدى استجابة الصفحة عمومًا لتفاعلات المستخدم، من خلال رصد زمن انتقال جميع تفاعلات النقر واللمس ولوحة المفاتيح طوال زيارة المستخدم للصفحة.» — web.dev (INP). الانتقال إلى الاقتباس
• “CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (ترجمة) «CLS مقياس لأكبر دفعة من درجات تحوّل التخطيط بين جميع التحولات غير المتوقعة التي تقع طوال دورة حياة الصفحة.» — web.dev (CLS). الانتقال إلى الاقتباس

Google — استبدال INP بـFID

• “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” (ترجمة) «أصبح مقياس Interaction to Next Paint (INP) الآن مقياسًا مستقرًا من Core Web Vitals، ليحل محل First Input Delay (FID).» — Rick Viscomi، web.dev (12 مارس 2024). الانتقال إلى الاقتباس

Google — الحقل والمختبر والترتيب

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (ترجمة) «إذا كانت لديك بيانات حقل وبيانات مختبر لصفحة معينة، فاستخدم بيانات الحقل لترتيب أولويات جهودك.» — Philip Walton، web.dev. الانتقال إلى الاقتباس
• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (ترجمة) «تقرير تجربة مستخدم Chrome، المعروف أيضًا باسم Chrome UX Report أو اختصارًا CrUX، هو مجموعة بيانات تعكس تجربة مستخدمي Chrome الفعليين للوجهات الشائعة على الويب.» — Chrome for Developers (توثيق CrUX). الانتقال إلى الاقتباس

John Mueller، Google

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” (ترجمة) «إنه عامل ترتيب، وهو أكثر من مجرد عامل لكسر التعادل، لكنه لا يحل محل الصلة أيضًا.» — عبر Search Engine Journal (Reddit، أغسطس 2021). قراءة التغطية
• “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that.” (ترجمة) «ليست Core Web Vitals عوامل ضخمة في الترتيب، وأشك في أنك سترى انخفاضًا كبيرًا بسببها وحدها.» — عبر Stan Ventures (2024). قراءة التغطية

قائمة فحص Core Web Vitals

مرور سريع للتأكد من أنك تقيس الشيء الصحيح وتصلح الصفحات الصحيحة:

• تقرأ بيانات الحقل (CrUX)، لا درجة مختبر فقط، للمقاييس التي ترتب Google على أساسها.
• تنظر إلى الأرقام على مستوى الصفحة، لا متوسط مستوى الأصل فقط.
• تفحص المقاييس الثلاثة: LCP ≤ 2,5 ث وINP ≤ 200 مللي ثانية وCLS ≤ 0,1 عند p75.
• تراجع الهاتف وسطح المكتب منفصلين (تقيّم Google كلًا منهما).
• لا تحسن FID — فقد تقاعد في 12 مارس 2024 (استخدم INP).
• تراجع تقرير Core Web Vitals في GSC لمجموعات الصفحات الفاشلة، لا للحالات المنفردة.
• تفهم أن الصفحات قليلة الحركة قد لا تملك أي بيانات حقل من CrUX.
• تستخدم أدوات المختبر (Lighthouse/PSI) للتشخيص لا كبوابة نجاح/فشل — ولا تنتظر Performance Score مثاليًا.
• تتيح حتى 28 يومًا كي تظهر إصلاحات الحقل.
• لا تطارد CWV قبل صلة المحتوى ومكاسب SEO الأكبر.

النماذج الذهنية

1. ثلاثة أبعاد، ثلاثة مقاييس. LCP = التحميل، وINP = الاستجابة، وCLS = الاستقرار البصري. إذا استطعت تحديد البعد الذي تقع فيه المشكلة، عرفت أي مقياس وأي دليل تفصيلي تراجع.

2. الحقل للترتيب؛ المختبر للإصلاح. ترتب Google على بيانات CrUX الحقلية عند p75 عبر 28 يومًا. وتكشف درجات Lighthouse/PSI المخبرية الأسباب. لا تعامل درجة المختبر أبدًا كرقم ترتيبك — فكثيرًا ما لا ترتبطان حتى.

3. مستوى الصفحة يتفوق على مستوى الأصل. قد يخفي أصل «ناجح» صفحات فاشلة. تستخدم Google بيانات مستوى الصفحة حيثما توافرت. وعندما تعرض الأداة المستويين، ثق بعرض الصفحة.

4. مستخدمة، لكن بلا وزن. CWV إشارة ترتيب مؤكدة لم تسند Google إليها وزنًا رسميًا قط — وقد تتغلب الصلة عليها. أصلح CWV للمستخدمين والتحويلات؛ ولا تتوقع قفزة في الترتيب.

5. اختبار «هل هي Core أصلًا؟» LCP وINP وCLS وحدها Core Web Vitals. أما TTFB وFCP فهما تشخيصيان، وTBT وSpeed Index بدائل مخبرية. و«Engagement Reliability» غير مؤكدة أصلًا.

Core Web Vitals — ورقة غش

Core Web Vitals الثلاثة (بيانات الحقل، p75)

المقاييس التشخيصية — ليست Core Web Vitals

حقائق سريعة

• التقييم = بيانات CrUX الحقلية، المئين 75، نافذة متحركة مدتها 28 يومًا، مع فصل الهاتف وسطح المكتب.
• استبدل INP مؤشر FID في 12 مارس 2024. تقاعد FID تمامًا.
• درجات المختبر (Lighthouse/PSI) تشخيصية وليست قياسات حقل — وغالبًا لا تطابق CWV الحقلية.
• ما تستخدمه Google هو مستوى الصفحة؛ وقد تضلل متوسطات مستوى الأصل (~21,2% من الصفحات تجتاز مقابل ~33% من الأصول في دراسة CWV).
• وزن الترتيب: تستخدمه أنظمة ترتيب Google بلا وزن رسمي معلن — الصلة مهيمنة، والنتيجة الجيدة ليست ضمانًا.
• «Engagement Reliability» ليست Core Web Vital مؤكدة.

أي Core Web Vital ينبغي أن أحقق فيه أولًا؟

تتراجع Core Web Vitals بعد إصدار

1. أكد الإشارة. افصل بيانات الحقل عن المختبر، وعنوان URL عن الأصل، والهاتف عن سطح المكتب. إذا تغير تشغيل مختبري واحد فقط، فأعده قبل إعلان حادثة.
2. حدد الـVital الفاشل. يمثل LCP وINP وCLS مشكلات مختلفة. وإذا تحركت عدة مقاييس، فافحص تغييرات الإصدار المشتركة والبرامج النصية التابعة لجهات خارجية أولًا.
3. اربط التراجع بنشر. قارن تسجيلات RUM أو اختبارات المختبر القابلة للتكرار قبل الإصدار وبعده. وإذا لم يتطابق التوقيت، فافحص مزيج الحركة والأجهزة بدلًا من ذلك.
4. شخّص المقياس لا الدرجة. في LCP افحص العنصر والأجزاء الفرعية؛ وفي INP افحص التفاعلات البطيئة وعمل الخيط الرئيسي؛ وفي CLS افحص مصادر التحول.
5. انشر أصغر إصلاح يمكن إسناد أثره إليه. تحقّق منه في المختبر فورًا. وإذا عطّل وظيفة أو أضر بمقياس آخر، فتراجع.
6. راقب المستخدمين الحقيقيين. استخدم RUM للإشارة المبكرة، وCrUX/Search Console للتقييم الحقلي عبر النافذة المتحركة. وثّق النطاق والنافذة حتى لا يتوقع أصحاب المصلحة أن تعكس CrUX الإصلاح في اليوم نفسه.

أخطاء Core Web Vitals التي تهدر العمل

تحسين درجة Lighthouse المركبة

يستخدم تقييم Google الحقلي LCP وINP وCLS من بيانات المستخدمين الحقيقيين، لا رقم Performance الواحد في Lighthouse. شخّص المقياس الحقلي الفاشل واستخدم Lighthouse كبيئة تصحيح مضبوطة واحدة.

التعامل مع Core Web Vitals كاختصار للترتيب

CWV إشارة لتجربة الصفحة لم تسند Google إليها وزنًا رسميًا قط؛ وما تزال الصلة مهيمنة. أصلح التجربة السيئة للمستخدمين، لكن لا تعد بقفزة في الترتيب ولا تزحزح أعمال المحتوى والفهرسة الأهم بلا دليل.

خلط قيم URL والأصل والهاتف وسطح المكتب

قد تروي النطاقات المختلفة قصصًا مختلفة. ضع تسمية لكل قيمة، ولا تدّع أن صفحة اجتازت لمجرد أن القيمة البديلة على مستوى الأصل أو تجميع سطح المكتب مصنف «جيدًا».

انتظار CrUX قبل فحص الإصدار

نافذة الـ28 يومًا المتحركة بطيئة جدًا لاختبار النشر. تحقّق من الآلية في المختبر وRUM فورًا، ثم استخدم CrUX لتأكيد النتيجة الحقلية على المدى الأطول.

أدوات قياس Core Web Vitals

افحصها باستخدام Core Web Vitals History & Competitor Comparison:

1. أضف موقعًا (تتوفر للأصل المجرد مثل example.com عادةً أكبر كمية من بيانات CrUX؛ ويمكنك إضافة ما يصل إلى 5 للمقارنة).
2. اختر الهاتف أو سطح المكتب، ثم شغّل المقارنة.
3. اقرأ بطاقة النتائج لمعرفة اجتياز/فشل LCP وINP وCLS اليوم، ثم مخطط الاتجاه الأسبوعي لترى ما إذا كان كل مقياس يتجه نحو نطاق «الجيد» أو يبتعد عنه.

بيانات الحقل — قياس Core Web Vitals للمستخدمين الحقيقيين

• PageSpeed Insights — بيانات حقل CrUX على مستوى الصفحة والأصل، مع تقرير Lighthouse المخبري بجوارها.
• Google Search Console — تقرير Core Web Vitals — يجمع الصفحات المتشابهة ويظهر أنماط الحقل على مستوى الموقع؛ وهو أسرع طريق للعثور على مجموعات الصفحات الفاشلة.
• CrUX API / BigQuery — تحليل مخصص وعلى مستوى البلد مباشرة من مجموعة البيانات الأصلية.
• مكتبة JavaScript web-vitals — اجمع بيانات المستخدمين الحقيقيين (RUM)، مثل تمريرها إلى التحليلات.

بيانات المختبر — للتصحيح (لا للترتيب)

• Lighthouse — فرص تشخيصية ودرجة Performance غير المرتبطة بالترتيب.
• لوحة Performance في Chrome DevTools — تصحيح تفصيلي عبر تسجيل الأداء لـLCP وتحولات التخطيط والمهام الطويلة.
• القسم المخبري في PageSpeed Insights — التوصيات المدعومة بـLighthouse أسفل بيانات الحقل.

قاعدة عامة: استخدم GSC لمعرفة أين تفشل في الحقل ← PSI للتأكيد على مستوى الصفحة ← Lighthouse / DevTools للتشخيص والتكرار.

موارد تستحق وقتك

كتاباتي ذات الصلة

• Core Web Vitals: كيفية تحسينها (Ahrefs) — دليلي العملي الكامل للمقاييس الثلاثة وما ينبغي إصلاحه.
• دراسة بيانات Core Web Vitals (Ahrefs) — CrUX + 5,2 مليون صفحة؛ نتيجة معدل الاجتياز على مستوى الصفحة مقابل الأصل.
• دليل Largest Contentful Paint (LCP) من Ahrefs.
• دليل Cumulative Layout Shift (CLS) من Ahrefs.
• دليل PageSpeed Insights من Ahrefs.
• دليل المبتدئين إلى SEO التقني — موضع تجربة الصفحة ضمن صورة SEO الأكبر.

رسمي

• web.dev — Web Vitals ومقالات كل مقياس المرتبطة تحت Official Docs.
• Google تحدّث وثائق تجربة الصفحة لتوضيح إشارات الترتيب (Search Engine Land) — تغطية Barry Schwartz لتغيير توثيق مارس 2024.

من أوساط الصناعة

• عامل ترتيب Core Web Vitals لدى Google: أكثر من كاسر تعادل (Search Engine Journal) — تغطية تصريح John Mueller على Reddit بأن CWV «أكثر من كاسر تعادل» لكنها لا تستبدل الصلة.
• أولوية Core Web Vitals لدى Google للشركات الصغيرة والمحلية (Search Engine Roundtable) — تعليق Mueller على Mastodon بأن عمل CWV لا ينبغي أن يكون الأولوية للشركات الصغيرة/المحلية.
• تأكيد: Core Web Vitals ليست عامل ترتيب كبيرًا (Stan Ventures) — اقتباس Mueller «ليست عوامل ضخمة في الترتيب» ضمن سياقه.
• تأثير Core Web Vitals في SEO (RUMvision) — محدث في نوفمبر 2025؛ تجميع شامل بأسلوب الأسئلة الشائعة لتصريحات الممثلين ودقة إشارة الترتيب.
• تحديث تجربة الصفحة لدى Google: كاسر التعادل (Search Engine Roundtable) — صياغة Mueller/Illyes المبكرة حول كاسر التعادل قبل إطلاق التحديث.

إحصاءات تستحق الاستشهاد

• نحو 21,2% فقط من الصفحات الفردية تجتاز Core Web Vitals الثلاث كلها — مقابل نحو 33% على مستوى الأصل — وفق دراسة بيانات CWV (CrUX + 5,2 مليون صفحة من Ahrefs Site Audit). تقيم أنظمة Google الصفحات عمومًا بصورة فردية، لذلك قد يخفي متوسط الأصل المتفائل عددًا كبيرًا من الصفحات الفاشلة. المصدر
• تعاني المواقع أكثر مع LCP. وجدت الدراسة أن المواقع أحرزت تقدمًا في FID القديم وCLS، لكنها تأخرت في LCP — وأن “almost no sites on 3G or slower connections are passing.” (ترجمة) «لا تكاد أي مواقع على اتصالات 3G أو أبطأ تجتاز». المصدر
• عتبات «الجيد»: LCP ≤2,5 ث وINP ≤200 مللي ثانية وCLS ≤0,1، كل منها عند المئين 75 من بيانات الحقل — أهداف Core Web Vitals الموثقة لدى Google. المصدر
• استبدل INP مؤشر FID في 12 مارس 2024 — يوم توقف FID عن كونه Core Web Vital وأزيل من Search Console. المصدر

اختبر نفسك: Core Web Vitals

خمسة أسئلة سريعة عن Core Web Vitals. اختر إجابة لكل سؤال، ثم تحقق.

أثبت أن إصلاح LCP/INP/CLS وصل فعلًا

الفخ في إصلاح الأداء هو الاحتفال بدرجة المختبر يوم النشر. يخبرك المختبر (Lighthouse) بأن التغيير يمكن أن ينجح؛ أما بيانات الحقل (CrUX) وحدها فتخبرك بأنه نجح مع المستخدمين الحقيقيين — وهي تُحدَّث ضمن نافذة متحركة مدتها 28 يومًا. شغّل الاثنين، بهذا الترتيب.

الاختبار 1 — حسّن الإصلاح المقياس المخبري

• الاختبار الذي تجريه — مرّر الصفحة عبر Core Web Vitals Checker (أو Lighthouse / PageSpeed Insights) قبل التغيير وبعده.
• النتيجة المتوقعة — يتحرك المقياس المخبري المستهدف في الاتجاه الصحيح — مثل أن يُرسم عنصر LCP أسرع، وألا يظهر تحول تخطيط جديد، وأن يختفي التشخيص المحدد الذي كنت تصلحه.
• تفسير الفشل — عدم تحرك المختبر يعني أن التغيير لم يمس المسار الحرج (حسّنت عنصرًا ليس عنصر LCP، أو نصًا برمجيًا لم يكن يحجب المسار).
• نافذة المراقبة — فورية؛ فاختبارات المختبر عند الطلب.
• محفز التراجع — حدوث تراجع في مقياس آخر (أصلحت LCP لكن أدخلت CLS، أو أضفت JavaScript أضر بـINP) — يلتقط المختبر ذلك قبل المستخدمين الحقيقيين.

الاختبار 2 — هل يشعر به المستخدمون الحقيقيون فعلًا (بيانات الحقل)

• الاختبار الذي تجريه — تتبع p75 للصفحة/الأصل في LCP وINP وCLS عبر CrUX — باستخدام Core Web Vitals History & Competitor Comparison أو تقرير Core Web Vitals في GSC.
• النتيجة المتوقعة — ينتقل p75 للمقياس المُصلح إلى نطاق «الجيد» ويبقى فيه (عتبات Google: LCP ≤ 2,5 ث، وINP ≤ 200ms، وCLS ≤ 0,1).
• تفسير الفشل — تحسن المختبر لكن الحقل لم يتحسن: ربما أفاد الإصلاح اختبار اتصال سريع ولم يفد مزيج الأجهزة/الشبكات الحقيقي، أو أن عددًا غير كافٍ من عناوين URL في المجموعة يشترك في الإصلاح.
• نافذة المراقبة — 28 يومًا متحركة — فبيانات CrUX تغطي الأيام الـ28 السابقة، ويحتاج الإصلاح إلى نحو 4 أسابيع من بيانات الحقل المتراكمة قبل الوثوق بـp75. لا تحكم عليه في الأسبوع الأول.
• محفز التراجع — يعبر p75 مجددًا إلى ما بعد عتبة «ضعيف»، أو ينخفض عدد عناوين URL «الجيدة» في GSC بعد تغيير قالب — وهي علامة قوية على أن النشر أضعف أداء المستخدمين الحقيقيين.

مؤشر الأداء المستمر لهذا الموضوع

بعيدًا عن التحقق من أي إصلاح منفرد، هذا ما تراقبه ربعًا بعد ربع لتعرف أن تجربة الصفحة صحية. يوجد هنا معيار يمكن الدفاع عنه — فـGoogle تنشر العتبات — لذلك لا نختلق أرقامًا.

p75 لـLCP وINP وCLS (بيانات الحقل)

• المقياس — قيمة المئين 75 لكل Core Web Vital عبر الزيارات الحقيقية، حسب مجموعة الصفحة والجهاز.
• ما الذي يخبرك به — هل يحصل 75% من المستخدمين الحقيقيين على تجربة جيدة — وهو الحد الدقيق الذي تستخدمه Google لتصنيف عنوان URL على أنه ناجح. p75 (لا المتوسط) هو الرقم المهم لأنه يمثل شريحة المستخدمين الأبطأ.
• كيفية جلبه — CrUX عبر Core Web Vitals History & Competitor Comparison، أو تقرير GSC Core Web Vitals (بيانات الحقل مجمعة حسب نمط URL)، أو PageSpeed Insights لعنوان URL واحد.
• المعيار / النطاق الواقعي — عتبات Google نفسها: LCP ≤ 2,5 ث وINP ≤ 200 مللي ثانية وCLS ≤ 0,1 لـ«الجيد»؛ ونطاقا «يحتاج إلى تحسين» / «ضعيف» هما 2,5–4 ث / >4 ث، و200–500ms / >500ms، و0,1–0,25 / >0,25. هذه هي الحدود المنشورة وليست هدفًا مختلقًا.
• الوتيرة — نافذة متحركة مدتها 28 يومًا، لذا راجع شهريًا — فالفحص اليومي يعيد قراءة النافذة اللاحقة نفسها. تعامل مع درجات المختبر كإشارة مبكرة ومع p75 في CrUX كإشارة لاحقة.

تغطية «عناوين URL الجيدة» عبر الموقع

• المقياس — حصة عناوين URL المفهرسة في خانة «جيد» في تقرير GSC Core Web Vitals (مع تتبع الهاتف وسطح المكتب منفصلين).
• ما الذي يخبرك به — مدى انتشار الإصلاحات — فالصفحة السريعة الوحيدة لا تحرك الموقع؛ أما المكاسب على مستوى القالب فتفعل.
• كيفية جلبه — GSC ← تقرير Core Web Vitals ← عدّ عناوين URL الجيدة / التي تحتاج إلى تحسين / الضعيفة بمرور الوقت.
• المعيار / النطاق الواقعي — يعتمد على الحالة — فهو يتوقف على قوالبك ومزيج الحركة، لذا أنشئ خط أساسك الخاص وارفع حصة «جيد» بمرور الوقت بدل مطاردة نسبة مختلقة.
• الوتيرة — شهريًا، أو أسبوعيًا مباشرة بعد تغيير قالب أو سمة بينما تتراكم بيانات نافذة الحقل.

سجل التغييرات