قابلية الاستخدام على الجوال

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

ما قابلية الاستخدام على الجوال؟

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

هناك أربعة أمور تصنع هذه القابلية أو تفسدها:

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

لماذا يهم ذلك؟

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

«مهلاً، أين ذهب تقرير Mobile Usability؟»

إذا كنت تفحص مشكلات الجوال في Google Search Console من قبل فلست تتوهم؛ لقد اختفى التقرير. أوقف Google تقرير Mobile Usability في Search Console وأداة Mobile-Friendly Test المستقلة في 1 ديسمبر 2023. لا يعني هذا أن قابلية الاستخدام على الجوال فقدت أهميتها؛ فقد قال Google عكس ذلك. بل يعني أن التقرير المخصص اختفى لأن أدوات أفضل، مثل Lighthouse المضمن في Chrome، أصبحت تؤدي المهمة. لذا إذا طلب منك دليل “open the Mobile Usability report,” (ترجمة) «فتح تقرير Mobile Usability»، فهو قديم.

كيف تفحصها الآن؟

الخيار الأسهل: افتح صفحتك في Chrome، وانقر بالزر الأيمن ← Inspect، ثم شغّل Lighthouse، أو استخدم PageSpeed Insights على pagespeed.web.dev. يرصد كلاهما الخطوط الصغيرة وأهداف اللمس المتزاحمة ومشكلات إطار العرض. ويمكنك أيضاً تصغير نافذة المتصفح أو استخدام وضع معاينة الهاتف في Chrome ثم النظر إلى الصفحة على شاشة صغيرة؛ فكثير من مشكلات قابلية الاستخدام يصبح واضحاً لحظة فعل ذلك.

لا تخلط بينها وبين فكرتين متشابهتين

• الفهرسة المتنقلة أولاً — تتعلق بنسخة الصفحة التي يقرأها Google، وهي نسخة الجوال. وهذا موضوع مختلف.
• Core Web Vitals — تقيس السرعة والاستقرار. وهي مرتبطة بالموضوع لكنها مجموعة منفصلة من المقاييس.

هل تريد الحدود الدقيقة، مثل حجم هدف اللمس «الكافي»، والقصة الكاملة لإيقاف التقرير، وكل طرق اختبار قابلية الاستخدام اليوم؟ انتقل إلى تبويب متقدم.

الخلاصة — قابلية الاستخدام على الجوال هي سهولة الاستخدام على جهاز لمس، وتحكمها أربع إشارات: نص مقروء (يجتاز Lighthouse عند 12px في ≥60 % من النص، و16px خط أساس عملي لنص المتن)، وأهداف لمس (يفشل Lighthouse ما دون 48×48 بكسل CSS أو عندما يتداخل هدف مجاور مع ≥25 % من مساحة الهدف الواقعة ضمن 48px من مركزه؛ ويمثل تباعد ~8px نقطة بداية، أما حد WCAG 2,2 المنفصل البالغ 24×24 بكسل CSS فهو حد أدنى لإمكانية الوصول لا قاعدة ترتيب في Google)، ومحتوى ملائم لإطار العرض (يحتاج وسم viewport وصفياً صحيحاً، لكن الوسم وحده لا يضمن تخطيطاً متجاوباً؛ ومن دون تمرير أفقي)، وعدم وجود إعلانات بينية متطفلة. أوقف Google تقرير Mobile Usability في Search Console وأداة Mobile-Friendly Test وواجهتها البرمجية في 1 ديسمبر 2023، وأكد ذلك في 4 ديسمبر؛ لا لأن الإشارات فقدت أهميتها، بل لأن Lighthouse نضج ولأن الفهرسة المتنقلة أولاً اكتملت عملياً. افحصها اليوم عبر Lighthouse وPageSpeed Insights ومحاكاة الأجهزة في DevTools واختبار Bing الذي لا يزال متاحًا وأدوات الزحف. وهي تختلف عن الفهرسة المتنقلة أولاً، التي تحدد النسخة المفهرسة، وعن Core Web Vitals، التي تقيس التحميل والتفاعل والاستقرار. إنها إشارة ضمن تجربة الصفحة، لا عامل ترتيب مستقل شديد الوزن.

التعريف الدقيق

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

الإشارة 1: نص مقروء

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

• حد اجتياز التدقيق هو 12px. يقول تدقيق Lighthouse المسمى Document uses legible font sizes: “Aim to have a font size of at least 12 px on at least 60% of the text on your page.” (ترجمة) «استهدف حجم خط لا يقل عن 12 بكسل في 60 % على الأقل من نص صفحتك». وهذه هي العتبة اللازمة لاجتياز الفحص الآلي تقنياً.
• خط الأساس العملي نحو 16px. لا يعني اجتياز التدقيق بحجم 12px أن هذا الحجم مريح للقراءة على هاتف. والحجم 16px هو الحد الأدنى الموصى به عموماً لنص المتن على الجوال، مع عناوين أكبر. لا تصمم وفق الحد الأدنى للتدقيق.

إذن: 12px/60 % هو خط الاجتياز، أما 16px فهو ما ينبغي أن تستهدفه فعلياً في نص المتن.

الإشارة 2: أهداف اللمس

الأصابع أدوات غير دقيقة. يفشل تدقيق Lighthouse المسمى أهداف اللمس ليست بالحجم المناسب هدفاً في حالتين: عندما “the target is smaller than 48 px by 48 px,” (ترجمة) «يكون الهدف أصغر من 48 بكسل في 48 بكسل»، وعندما “at least 25% the target area within 48 px of the center of the target overlaps with another target.” (ترجمة) «تتداخل مع هدف آخر 25 % على الأقل من مساحة الهدف الواقعة ضمن 48 بكسل من مركزه». وتورد الوثيقة نفسها ملاحظات عملية:

• الأهداف بحجم 48×48 بكسل CSS تجتاز الفحص باستمرار.
• المهم هو المنطقة القابلة للنقر لا الحجم المرئي؛ إذ يمكنك إبقاء أيقونة صغيرة وتوسيع منطقة إصابتها باستخدام padding لتبلغ 48px. وهذا يدحض خرافة أن كل زر يجب أن يبدو بحجم 48px.
• يمثل تباعد ~8px بين الأهداف نقطة بداية معقولة، لكنه “is not always enough spacing to pass the audit especially for very small targets.” (ترجمة) «لا يكون دائماً تباعداً كافياً لاجتياز التدقيق، وخصوصاً للأهداف الصغيرة جداً».

كانت إرشادات Google الأقدم تصف أهدافاً بنحو 7mm وتباعداً بنحو 5mm؛ وهو ما يتوافق عموماً مع 48px عند كثافات الجوال المعتادة. استشهد بأرقام 48px و8px بوصفها الأحدث، واعتبر أرقام الملليمترات سياقاً تاريخياً.

وهناك رقم ثان مستقل ينبغي معرفته حتى لا تخلط بين المعايير: يحدد معيار النجاح 2.5.8 في WCAG 2,2 (الحد الأدنى لحجم الهدف، المستوى AA) حداً أدنى يبلغ 24×24 بكسل CSS، مع استثناءات للتباعد والعناصر السطرية والضرورية. هذه قاعدة امتثال لإمكانية الوصول من W3C، وليست عتبة ترتيب في بحث Google. وهي أصغر من عتبة Lighthouse البالغة 48px لأن الجهتين تقيسان شيئين مختلفين: الوفاء برقم Lighthouse البالغ 48px يتجاوز أيضاً حد WCAG البالغ 24px، لكن لا تستشهد بأي منهما على أنه قاعدة ثابتة أبدية تقول «يتطلب Google ‏N بكسل». فرقم Lighthouse عتبة تدقيق في أدوات Chrome، ورقم WCAG معيار امتثال لإمكانية الوصول.

الإشارة 3: محتوى ملائم لإطار العرض

يجب أن يلائم المحتوى عرض الهاتف، بلا تمرير أفقي وبلا صفحة مرسومة بعرض سطح المكتب ثم مصغرة حتى يصبح نصها غير مقروء. والآلية هي وسم viewport الوصفي. بدونه، أو عند ضبطه خطأ، تفترض متصفحات الجوال لوحة بعرض سطح المكتب وتصغر كل شيء. والإصلاح سطر واحد داخل <head>:

<meta name="viewport" content="width=device-width, initial-scale=1">

تقول إرشادات Google: “make sure your page content fits the width of the viewport, keeping in mind that not all mobile devices are the same width.” (ترجمة) «تأكد من أن محتوى صفحتك يلائم عرض إطار العرض، مع مراعاة أن أجهزة الجوال ليست كلها بالعرض نفسه». لذلك لا تثبت عروضاً بالبكسل لا تلائم إلا هاتفاً واحداً.

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

الإشارة 4: لا إعلانات بينية متطفلة

النافذة المنبثقة بملء الشاشة التي تحجب المحتوى لحظة وصول زائر من البحث مشكلة في قابلية الاستخدام والبحث معاً. يقول Google: “intrusive interstitials and dialogs are page elements that obstruct users’ view of the content, usually for promotional purposes,” (ترجمة) «الإعلانات البينية ومربعات الحوار المتطفلة عناصر في الصفحة تحجب رؤية المستخدمين للمحتوى، وعادةً لأغراض ترويجية»، ويحذر من أنها “make it hard for Google and other search engines to understand your content, which may lead to poor search performance.” (ترجمة) «تصعّب على Google ومحركات البحث الأخرى فهم محتواك، ما قد يؤدي إلى أداء ضعيف في البحث». والإرشاد صريح: “don’t obscure the entire page with interstitials” (ترجمة) «لا تحجب الصفحة كلها بإعلانات بينية»، ويقترح بدلاً منها لافتات صغيرة لا تشغل إلا جزءاً من الشاشة. أما التفصيل الكامل لما يعاقب عليه وما يُستثنى ففي الدليل المتعمق للإعلانات البينية المتطفلة.

ماذا حدث لتقرير Mobile Usability؟

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

• أبريل 2023 — الإعلان. قال Google في The role of page experience in creating helpful content: “Also starting December 1, 2023, we’ll be retiring Search Console’s ‘Mobile Usability’ report, the Mobile-Friendly Test tool and Mobile-Friendly Test API. This doesn’t mean that mobile usability isn’t important for success with Google Search.” (ترجمة) «واعتباراً من 1 ديسمبر 2023 سنوقف أيضاً تقرير Mobile Usability في Search Console وأداة Mobile-Friendly Test وواجهة Mobile-Friendly Test البرمجية. ولا يعني هذا أن قابلية الاستخدام على الجوال ليست مهمة للنجاح في بحث Google». وشرح السبب بقوله: “in the nearly ten years since we initially launched this report, many other robust resources for evaluating mobile usability have emerged, including Lighthouse from Chrome.” (ترجمة) «خلال ما يقارب عشر سنوات منذ إطلاقنا هذا التقرير أول مرة، ظهرت موارد قوية كثيرة أخرى لتقييم قابلية الاستخدام على الجوال، ومنها Lighthouse من Chrome».
• 1 ديسمبر 2023 — الإيقاف. اختفى التقرير وأداة Mobile-Friendly Test والواجهة البرمجية. وأزال Google الإشارات إليها من وثائق مساعدة البحث في اليوم نفسه. يعيد عنوان Mobile-Friendly Test القديم (search.google.com/test/mobile-friendly) الآن التوجيه إلى وثائق Lighthouse، ومحاولة فتح تقرير Mobile Usability في Search Console تعيد التوجيه إلى صفحة GSC الرئيسية.
• 4 ديسمبر 2023 — التأكيد. أكد حساب Search Console الإيقاف علناً وشكر أصحاب المواقع بقوله “for working with us on this journey.” (ترجمة) «على العمل معنا في هذه الرحلة».

لماذا في ذلك الوقت؟ سببان. أولاً، كانت الفهرسة المتنقلة أولاً قد اكتملت عملياً؛ إذ أعلن Google في 31 أكتوبر 2023 أن “the trek to Mobile First Indexing is now complete” (ترجمة) «الرحلة إلى الفهرسة المتنقلة أولاً اكتملت الآن»، فصار التقرير المخصص في GSC والمفصول حسب الجهاز أقل منطقية. ثانياً، نضج Lighthouse ليصبح أداة فحص أفضل وأكثر قابلية للتنفيذ من الأداة المستقلة القديمة. لم تتوقف أهمية الإشارات؛ الذي توقف هو التقرير المخصص.

التصحيح العملي: توقف عن مطالبة الناس “check the Mobile Usability report” (ترجمة) «بفحص تقرير Mobile Usability» أو “run the Mobile-Friendly Test” (ترجمة) «بتشغيل Mobile-Friendly Test». كلاهما اختفى. وبصراحة، ما يزال دليلي في Ahrefs، الفهرسة المتنقلة أولاً تصبح للجوال وحده، الذي كان آخر تحديث له في يونيو 2024، يوجّه القراء في موضع واحد إلى هاتين الوجهتين الموقوفتين. وهذا بالضبط نوع النصيحة القديمة التي وُجد هذا المقال لتصحيحها، وهو على قائمة ما سأصححه هناك أيضاً.

كيفية فحص قابلية الاستخدام على الجوال اليوم

بما أنه لم يعد هناك تقرير مخصص واحد، تجمع الفحص من عدة أدوات:

• Chrome Lighthouse ‏(DevTools ← Lighthouse) — البديل المباشر. يشغّل تدقيقات مقروئية الخط وأهداف اللمس وإطار العرض، ويعطيك العناصر المحددة التي تفشل.
• PageSpeed Insights ‏(pagespeed.web.dev) — يشغّل Lighthouse في السحابة بملف الجوال، وهو مناسب لفحص سريع على مستوى عنوان URL ونتيجته قابلة للمشاركة.
• شريط أجهزة Chrome DevTools — يحاكي هاتفاً كي تفحص بالنظر التمرير الأفقي والنص الصغير وعناصر التحكم المتزاحمة بأبعاد حقيقية.
• Bing Mobile Friendliness Test Tool — فارق حقيقي: لا يزال Bing يتيح اختبارًا لملاءمة الجوال في Bing Webmaster Tools رغم اختفاء اختبار Google. يقول Bing: “making pages mobile-friendly increases user engagement on mobile devices. It can also help you rank better in Bing search results on mobile devices.” (ترجمة) «إن جعل الصفحات ملائمة للجوال يزيد تفاعل المستخدمين على الأجهزة المحمولة، ويمكن أن يساعد أيضاً في رفع ترتيبك ضمن نتائج بحث Bing على الجوال». وهو مفيد كرأي ثانٍ في العرض.
• أدوات الزحف الخارجية — يستطيع Ahrefs Site Audit وما شابهه الزحف بوكيل مستخدم للجوال وإظهار المشكلات الخاصة به على نطاق واسع؛ صِل واجهة PageSpeed Insights البرمجية لإجراء فحوص الجوال.
• جهاز حقيقي. لا شيء يتفوق على فتح الصفحة في هاتف فعلي.

لا تثبت أداة واحدة قابلية الاستخدام من البداية إلى النهاية بمفردها. اجمع تدقيقاً آلياً، عبر Lighthouse أو PageSpeed Insights، وفحصاً بصرياً محاكى، عبر شريط أجهزة DevTools، وتمريراً واحداً على الأقل بجهاز حقيقي قبل اعتبار الصفحة مُصلحة.

قابلية الاستخدام مقابل الفهرسة المتنقلة أولاً مقابل Core Web Vitals

يخلط الناس بين هذه المفاهيم الثلاثة باستمرار. هي مترابطة لكنها مختلفة:

قد يكون الموقع خاضعاً بالكامل للفهرسة المتنقلة أولاً وتظل قابليته على الجوال سيئة، كنص صغير وأزرار متزاحمة، والعكس صحيح. يغطي الدليل المتعمق للفهرسة المتنقلة أولاً ومادة Core Web Vitals هذين الموضوعين بالكامل؛ أما هذا المقال فيقتصر على طبقة قابلية الاستخدام.

هل تؤثر قابلية الاستخدام على الترتيب؟

نعم، لكن ضعها في حجمها الصحيح. تسهم قابلية الاستخدام في تجربة الصفحة التي يتعامل معها Google كمجموعة إشارات داخل أنظمة ترتيب أوسع، لا كعامل واحد ذي وزن ثقيل ودرجة ثابتة. ويحذر Google أصحاب المواقع من أنهم “should not focus on only one or two aspects of page experience,” (ترجمة) «ينبغي ألا يركزوا على جانب أو جانبين فقط من تجربة الصفحة»، وأن “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (ترجمة) «بحث Google يسعى دائماً إلى عرض المحتوى الأكثر صلة حتى لو كانت تجربة الصفحة دون المستوى». أصلح قابلية الاستخدام لأنها تساعد الناس الحقيقيين ولأن ذلك هو الصواب، لا لأنك تتوقع قفزة سحرية في الترتيب. إنها مساهم وليست صاحبة القرار.

موضع هذا الموضوع في مجموعة SEO للجوال

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

ملخص AI

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

• قابلية الاستخدام على الجوال هي سهولة الاستخدام على جهاز لمس. إشاراتها الأربع: نص مقروء، وأهداف لمس، ومحتوى ملائم لإطار العرض، وعدم وجود إعلانات بينية متطفلة.
• النص المقروء: يجتاز Lighthouse عند 12px في ≥60 % من النص، لكن 16px خط أساس عملي لنص المتن. لا تصمم وفق الحد الأدنى للتدقيق.
• أهداف اللمس: يفشل Lighthouse ما دون 48×48 بكسل CSS أو عندما يتداخل هدف مجاور مع ≥25 % من المساحة الواقعة ضمن 48px من المركز. المهم هو المنطقة القابلة للنقر، عبر الحشو، لا الحجم المرئي. والتباعد ~8px نقطة بداية. يحدد الحد الأدنى لحجم الهدف في WCAG 2,2 ‏(SC 2.5.8، المستوى AA) أرضية مستقلة لإمكانية الوصول تبلغ 24×24 بكسل CSS؛ وهي قاعدة امتثال من W3C لا عتبة ترتيب في Google.
• إطار العرض: <meta name="viewport" content="width=device-width, initial-scale=1">؛ يجب أن يلائم المحتوى عرض الهاتف بلا تمرير أفقي. يطابق الوسم إطار عرض التخطيط مع عرض الجهاز، لكنه لا يجعل المحتوى ثابت العرض متجاوباً من تلقاء نفسه، وقد تستمر العناصر الفردية في تجاوز العرض.
• الإعلانات البينية المتطفلة: تحجب الطبقات التي تملأ الصفحة عند الدخول المحتوى وتضر أداء البحث، والبديل المقبول هو لافتات صغيرة.
• التقرير اختفى. أوقف Google تقرير Mobile Usability في Search Console وأداة Mobile-Friendly Test والواجهة البرمجية في 1 ديسمبر 2023، وأكد ذلك في 4 ديسمبر؛ لأن Lighthouse نضج والفهرسة المتنقلة أولاً اكتملت عملياً في 31 أكتوبر 2023، لا لأن الإشارات فقدت أهميتها.
• افحصها الآن عبر Lighthouse وPageSpeed Insights ومحاكاة الأجهزة في DevTools واختبار Bing Mobile Friendliness الذي لا يزال متاحًا وأدوات الزحف الخارجية.
• وهي مختلفة عن الفهرسة المتنقلة أولاً، أي النسخة المفهرسة، وعن Core Web Vitals، أي التحميل والتفاعل والاستقرار.
• الترتيب: إنها إشارة واحدة لتجربة الصفحة ضمن أنظمة أوسع، لا عاملاً مستقلاً شديد الوزن. وسيظل Google يعرض المحتوى الأكثر صلة حتى مع تجربة دون المستوى.

الوثائق الرسمية

وثائق المصادر الأولية من محركات البحث.

Google

• The role of page experience in creating helpful content (Apr 2023) — الإعلان الذي أوقف تقرير Mobile Usability وأداة Mobile-Friendly Test والواجهة البرمجية في 1 ديسمبر 2023، وأشار إلى Lighthouse.
• Understanding Google page experience — موضع قابلية الاستخدام كإشارة، وأسئلة التقييم الذاتي، والتحذير من الإفراط في التركيز على إشارة واحدة.
• تجنب الإعلانات البينية ومربعات الحوار المتطفلة — تعريف الإعلانات البينية وبديل اللافتة الصغيرة.
• Mobile-first indexing has landed (Oct 2023) — محطة «اكتمال الرحلة» التي جعلت التقرير المخصص والمفصول حسب الجهاز غير ضروري.

Chrome / Lighthouse

• Document doesn’t use legible font sizes — عتبة التدقيق: 12px في 60 % من النص.
• أهداف اللمس ليست بالحجم المناسب — تدقيق 48×48 بكسل CSS وقواعد التداخل والتباعد.

Bing / Microsoft

• Bing Mobile Friendliness Test Tool — لا يزال متاحًا خلافًا لاختبار Google؛ اختبر أي عنوان URL لملاءمة الجوال في Bing Webmaster Tools.

W3C

• الحد الأدنى لحجم الهدف — شرح معيار النجاح 2.5.8 في WCAG 2,2 — أرضية امتثال إمكانية الوصول 24×24 بكسل CSS، وهي منفصلة عن عتبة تدقيق Lighthouse البالغة 48px.

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

تصريحات موثقة من Google وChrome/Lighthouse وBing. كل رابط عميق ينتقل إلى المقطع المقتبس حيث تدعمه صفحة المصدر.

Google — إيقاف التقرير والأدوات (إعلان أبريل 2023)

• “Also starting December 1, 2023, we’ll be retiring Search Console’s ‘Mobile Usability’ report, the Mobile-Friendly Test tool and Mobile-Friendly Test API. This doesn’t mean that mobile usability isn’t important for success with Google Search.” (ترجمة) «واعتباراً من 1 ديسمبر 2023 سنوقف أيضاً تقرير Mobile Usability في Search Console وأداة Mobile-Friendly Test وواجهة Mobile-Friendly Test البرمجية. وهذا لا يجعل قابلية الاستخدام على الجوال غير مهمة للنجاح في بحث Google». — Google Search Central Blog. اقرأ التدوينة
• “In the nearly ten years since we initially launched this report, many other robust resources for evaluating mobile usability have emerged, including Lighthouse from Chrome.” (ترجمة) «خلال ما يقارب عشر سنوات منذ إطلاقنا هذا التقرير أول مرة، ظهرت موارد قوية كثيرة أخرى لتقييم قابلية الاستخدام على الجوال، ومنها Lighthouse من Chrome». اقرأ التدوينة

Google — إطار تجربة الصفحة

• “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (ترجمة) «يسعى بحث Google دائماً إلى عرض المحتوى الأكثر صلة حتى لو كانت تجربة الصفحة دون المستوى». — وثائق Google Search Central. انتقل إلى الاقتباس

Google — الإعلانات البينية المتطفلة

• “Intrusive interstitials and dialogs are page elements that obstruct users’ view of the content, usually for promotional purposes.” (ترجمة) «الإعلانات البينية ومربعات الحوار المتطفلة عناصر في الصفحة تحجب رؤية المستخدمين للمحتوى، وعادةً لأغراض ترويجية». — وثائق Google Search Central. انتقل إلى الاقتباس

Google — اكتمال الفهرسة المتنقلة أولاً (السياق)

• “We’re delighted to announce that the trek to Mobile First Indexing is now complete.” (ترجمة) «يسعدنا أن نعلن أن الرحلة إلى الفهرسة المتنقلة أولاً اكتملت الآن». — Google Search Central Blog، ‏31 أكتوبر 2023. انتقل إلى الاقتباس

Chrome / Lighthouse — الحدود

• “Aim to have a font size of at least 12 px on at least 60% of the text on your page.” (ترجمة) «استهدف حجم خط لا يقل عن 12 بكسل في 60 % على الأقل من نص صفحتك». — وثائق Chrome for Developers / Lighthouse. انتقل إلى الاقتباس
• تفشل أهداف اللمس عندما لا يتحقق “48 px by 48 px” (ترجمة) «48 بكسل في 48 بكسل»، وعندما تتداخل مناطق الأهداف ضمن 48px من المركز. انتقل إلى الاقتباس

Bing — الأداة التي ما تزال حية

• “Making pages mobile-friendly increases user engagement on mobile devices. It can also help you rank better in Bing search results on mobile devices.” (ترجمة) «يزداد تفاعل مستخدمي الأجهزة المحمولة حين تكون الصفحات ملائمة للجوال، ويمكن لهذا أيضاً أن يحسن ترتيبك في نتائج بحث Bing على الجوال». — Bing Webmaster Tools، ‏Mobile Friendliness Test. افتح الأداة

اختفى التقرير؛ فكيف أفحص قابلية الاستخدام على الجوال الآن؟

لم تعد إجابة “just open the Mobile Usability report” (ترجمة) «افتح تقرير Mobile Usability وحسب» صالحة. تعتمد الأداة الحالية التي تختارها على ما تحاول فعله. انتقل بين خطوات الشجرة.

قائمة تدقيق قابلية الاستخدام على الجوال

مرور على الإشارات الأربع يجرى على العرض المحمول للصفحة، في وضع الأجهزة في DevTools أو على هاتف حقيقي:

• نص المتن مقروء بلا تكبير — خط أساس ~16px، ويجتاز على الأقل تدقيق Lighthouse البالغ 12px في ≥60 % من النص.
• أهداف اللمس 48×48 بكسل CSS، أو أيقونة أصغر مع حشو يوسع المنطقة القابلة للنقر إلى 48px.
• أهداف اللمس غير متزاحمة — الأهداف المتجاورة لا تتداخل ضمن 48px من المركز؛ تباعد ~8px أو أكثر، وزيادة للأهداف الصغيرة جداً.
• وسم viewport الوصفي موجود — <meta name="viewport" content="width=device-width, initial-scale=1">.
• لا تمرير أفقي — يلائم المحتوى عرض إطار العرض، ولا توجد عناصر ثابتة البكسل أعرض من الشاشة.
• لا إعلان بيني متطفل عند الوصول من البحث — الطبقات بملء الصفحة مرفوضة، أما اللافتات الصغيرة والبوابات المطلوبة قانوناً فلا بأس بها.
• CSS وJS غير محظورين في robots.txt — يحتاجهما Googlebot لعرض صفحة الجوال والحكم على قابليتها للاستخدام.
• جرى التدقيق عبر Lighthouse أو PageSpeed Insights — لا عبر Mobile-Friendly Test أو تقرير GSC Mobile Usability الموقوفين.
• جرى فحص عيّنة على جهاز حقيقي — بعض المشكلات لا يظهر إلا على عتاد فعلي.

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

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

2. حد التدقيق ليس الهدف. يجتاز Lighthouse النص عند 12px وأهداف اللمس عند 48px تماماً. هذه أرضيات لا أهداف. استهدف 16px لنص المتن وعناصر تحكم متباعدة براحة؛ فاجتياز التدقيق وراحة الاستخدام ليسا الشيء نفسه.

3. المنطقة القابلة للنقر لا الحجم المرئي. يمكن لأيقونة صغيرة اجتياز تدقيق أهداف اللمس إذا وسّع padding منطقة إصابتها إلى 48px. صمم منطقة الإصابة لا وحدات البكسل الظاهرة فقط.

4. ثلاثة أمور «ليست الشيء نفسه».

• قابلية الاستخدام ≥ الفهرسة المتنقلة أولاً؛ فالأخيرة تحدد النسخة المفهرسة.
• قابلية الاستخدام ≥ Core Web Vitals؛ فالأخيرة تقيس التحميل والتفاعل والاستقرار.
• قابلية الاستخدام ≥ عامل ترتيب ثقيل واحد؛ إنها إشارة ضمن عدة إشارات لتجربة الصفحة.

5. انتقلت الأدوات؛ حدّث عاداتك. اختفى تقرير GSC المخصص وMobile-Friendly Test في ديسمبر 2023. استخدم Lighthouse أو PageSpeed Insights أو DevTools أو اختبار Bing أو أداة زحف. إذا ظلت وثيقة إجراءات تقول “check the Mobile Usability report,” (ترجمة) «افحص تقرير Mobile Usability»، فالخلل في وثيقة الإجراءات.

قابلية الاستخدام على الجوال — قائمة غش

الإشارات الأربع والحدود

سطر إطار العرض

<meta name="viewport" content="width=device-width, initial-scale=1">

تواريخ ينبغي معرفتها

• أبريل 2023 — أعلن Google الإيقاف.
• 31 أكتوبر 2023 — أُعلن اكتمال الفهرسة المتنقلة أولاً.
• 1 ديسمبر 2023 — أُوقف تقرير Mobile Usability وأداة Mobile-Friendly Test والواجهة البرمجية.
• 4 ديسمبر 2023 — تأكد الإيقاف علناً.

إلى أين ذهبت الأدوات القديمة؟

• عنوان Mobile-Friendly Test ← يعيد التوجيه إلى وثائق Lighthouse.
• تقرير GSC Mobile Usability ← يعيد التوجيه إلى صفحة GSC الرئيسية.

افحصها الآن: Lighthouse · PageSpeed Insights · وضع الأجهزة في DevTools · Bing Mobile Friendliness Test (لا يزال متاحًا) · أداة زحف خارجية · جهاز حقيقي.

لا تخلط بينها وبين: الفهرسة المتنقلة أولاً، أي النسخة المفهرسة · Core Web Vitals ‏(LCP/INP/CLS).

إجراء تشغيل: تدقيق قابلية استخدام صفحة على الجوال بعد إيقاف التقرير

إجراء قابل للتكرار بعدما اختفى التقرير بنقرة واحدة. نحو 10 دقائق لكل صفحة.

1. افتح الصفحة في Chrome وشغّل Lighthouse. افتح DevTools عبر (⌘⌥I / Ctrl+Shift+I) ← تبويب Lighthouse ← حدد SEO وPerformance ← Analyze page load، واختر جهاز Mobile. سجّل أي فشل في legible font sizes أو tap targets؛ يسرد Lighthouse العناصر المحددة.
2. أكد وسم viewport. ابحث في Elements داخل DevTools عن name="viewport" في <head>. يجب أن تكون قيمته width=device-width, initial-scale=1. غياب الوسم، أو قيمة ثابتة مثل width=980، هو ما ينبغي إصلاحه.
3. حاكِ هاتفاً وانظر. فعّل شريط الأجهزة (⌘⇧M / Ctrl+Shift+M)، واختر جهازاً صغيراً، مثل عرض iPhone SE. مرر الصفحة كلها؛ فأي شريط تمرير أفقي أو عنصر يخرج من الحافة اليمنى يمثل فشل ملاءمة لإطار العرض.
4. اختبر أهداف اللمس يدوياً. حاول في وضع الأجهزة النقر على الروابط أو الأزرار المتجاورة. إذا كان النقر الخطأ مرجحاً واقعياً، فهي صغيرة أو متقاربة؛ استهدف مناطق إصابة 48px مع تباعد ~8px أو أكثر.
5. افحص الإعلان البيني عند الدخول. حمّل عنوان URL من جديد، في وضع التصفح الخفي، كما لو وصلت من البحث. الطبقة التي تملأ الصفحة قبل أن تقرأ المحتوى مشكلة؛ أما اللافتات الصغيرة وبوابات القانون أو الموافقة فلا بأس بها.
6. قارن باختبار Bing الحي، كرأي ثانٍ اختياري، على bing.com/webmaster/tools/mobile-friendliness، أو استخدم PageSpeed Insights للحصول على سجل قابل للمشاركة.
7. تحقق على جهاز حقيقي إذا كانت الصفحة مهمة. المحاكاة قريبة وليست كاملة.
8. صنّف الإصلاحات حسب الإشارة — حجم الخط، وحجم أهداف اللمس وتباعدها، وإطار العرض، والإعلان البيني — كي يحصل المطورون على قائمة قابلة للتنفيذ، لا طلباً مبهماً «اجعلها ملائمة للجوال».

الأنماط المضادة لقابلية الاستخدام على الجوال

أخطاء متكررة؛ وكثير منها مضمن في نصائح قديمة ما تزال تتداول.

• “Check the GSC Mobile Usability report.” (ترجمة) «افحص تقرير GSC Mobile Usability». أُوقف في 1 ديسمبر 2023، ويعيد العنوان الآن التوجيه إلى صفحة النظرة العامة. إذا قالت وثيقة أو مادة تعليمية هذا فهي قديمة، بما في ذلك، حتى تصحيحه، مقطع في دليلي لدى Ahrefs.
• “Run Google’s Mobile-Friendly Test.” (ترجمة) «شغّل Mobile-Friendly Test من Google». أُوقف هو أيضاً في 1 ديسمبر 2023، ويعيد عنوانه القديم التوجيه إلى وثائق Lighthouse. ما تزال مقالات حية عديدة تصف هذه الأداة بأنها تعمل، لكنها لا تعمل.
• التصميم وفق أرضية التدقيق 12px. لا يجعل اجتياز تدقيق حجم الخط في Lighthouse عند 12px النص مريحاً على الهاتف. استخدم نحو 16px لنص المتن.
• قياس الأيقونة المرئية لا المنطقة القابلة للنقر. يمكن لأيقونة 24px اجتياز تدقيق أهداف اللمس إذا وسع الحشو منطقة إصابتها إلى 48px. الخطأ هو تصغير منطقة الإصابة لتطابق الرسم.
• إغفال وسم viewport الوصفي أو ضبطه خطأ. يجعل غياب الوسم، أو ثبات عرضه، متصفحات الجوال تعرض الصفحة بعرض سطح المكتب وتصغر كل شيء. وهو إصلاح بسطر واحد يسهل نسيانه.
• إعلانات بينية بملء الشاشة عند الدخول من البحث. تحجب طبقات النشرات أو تثبيت التطبيقات أو الإعلانات المحتوى لحظة الوصول، وقد تضر أداء البحث. استخدم لافتة صغيرة بدلاً منها.
• حظر CSS أو JS في robots.txt. إذا تعذر على Googlebot جلب الموارد، تعذر عليه عرض صفحة الجوال كما ينبغي والحكم على قابليتها للاستخدام.
• اعتبار قابلية الاستخدام رافعة ترتيب مستقلة كبيرة. إنها إشارة واحدة لتجربة الصفحة، وسيظل Google يعرض المحتوى الأكثر صلة حتى مع تجربة دون المستوى. أصلحها للمستخدمين لا لقفزة ترتيب متخيلة.
• الخلط بينها وبين الفهرسة المتنقلة أولاً أو Core Web Vitals. مشكلات مختلفة وإصلاحات مختلفة وأدوات مختلفة. أبقها منفصلة.

فحوص سريعة يمكنك تشغيلها بنفسك

لا تحتاج إلى الأدوات الموقوفة لرصد المشكلات الشائعة. إليك مقتطفات عملية.

فحص وسم viewport الوصفي من سطر الأوامر

# Does the page ship a proper viewport meta tag?
curl -s https://example.com/ | grep -i 'name="viewport"'
# Expected: <meta name="viewport" content="width=device-width, initial-scale=1">
# No output = no viewport tag (a mobile-usability failure).

العثور على العناصر التي تسبب التمرير الأفقي (وحدة تحكم DevTools)

الصق هذا في وحدة تحكم Chrome DevTools أثناء محاكاة هاتف. يسرد أي عنصر أعرض من إطار العرض، وهو السبب المعتاد للتمرير الأفقي:

// Flag elements wider than the viewport
const vw = document.documentElement.clientWidth;
[...document.querySelectorAll('*')]
  .filter(el => el.getBoundingClientRect().right > vw + 1)
  .forEach(el => console.log(Math.round(el.getBoundingClientRect().right), el));

العثور على نص أصغر من 16px (وحدة تحكم DevTools)

// List text-bearing elements rendered below the 16px baseline
[...document.querySelectorAll('body *')]
  .filter(el => el.childNodes.length && [...el.childNodes].some(n => n.nodeType === 3 && n.textContent.trim()))
  .map(el => ({ px: parseFloat(getComputedStyle(el).fontSize), el }))
  .filter(x => x.px < 16)
  .forEach(x => console.log(x.px + 'px', x.el));

علامة مرجعية: إبراز أهداف اللمس الصغيرة

احفظه كإشارة مرجعية وشغّله على أي صفحة في محاكاة الجوال؛ فهو يرسم حدوداً حول العناصر التفاعلية التي تقل أبعاد صندوقها المعروض عن 48×48 بكسل CSS:

javascript:(()=>{document.querySelectorAll('a,button,input,select,textarea,[role=button]').forEach(el=>{const r=el.getBoundingClientRect();if(r.width<48||r.height<48){el.style.outline='2px solid red';}});})();

تذكر التحفظ: تقيس الأداة المنطقة القابلة للنقر، بما فيها الحشو. وقد يكون العنصر المعلّم هنا سليماً إذا وسع الحشو منطقة إصابته إلى 48px.

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

• Chrome Lighthouse ‏(DevTools ← Lighthouse) — البديل المباشر لـMobile-Friendly Test الموقوف. يشغّل تدقيقات الخط المقروء وأهداف اللمس وإطار العرض، ويسمي العناصر التي تفشل.
• PageSpeed Insights ‏(pagespeed.web.dev) — Lighthouse في السحابة بملف الجوال، مع نتائج على مستوى عنوان URL قابلة للمشاركة.
• شريط أجهزة Chrome DevTools — محاكاة هاتف لفحص التمرير الأفقي والنص الصغير وعناصر التحكم المتزاحمة بأبعاد حقيقية.
• Bing Mobile Friendliness Test Tool — لا يزال متاحًا في Bing Webmaster Tools، ويوفر رأياً ثانياً حقيقياً بعد اختفاء أداة Google المخصصة.
• URL Inspection في Search Console — شاهد HTML الجوال المعروض ولقطة الشاشة التي رآها Googlebot smartphone. لا يقيّم القابلية، لكنه يؤكد ما يُعرض.
• Ahrefs Site Audit — ازحف بوكيل مستخدم للجوال وأظهر المشكلات الخاصة به عبر كل الصفحات، مع توصيل واجهة PageSpeed Insights البرمجية لفحوص الجوال.
• هاتف حقيقي — المرجع الفعلي الذي تحاول المحاكاة تقريبه.

تبدو صفحة الجوال سليمة في المحاكاة لكنها تفشل على هاتف

العرض: يبدو شريط أجهزة Chrome سليماً، لكن المستخدمين يبلغون عن محتوى مقصوص أو عناصر تحكم متداخلة أو مربعات حوار غير قابلة للاستخدام. السبب المرجح: لم تحاكِ الأداة واجهة متصفح الهاتف أو حواشي المنطقة الآمنة أو تكبير النص أو لوحة مفاتيح نظام التشغيل. الإصلاح: أعد المهمة على جهاز iOS فعلي واحد وجهاز Android فعلي واحد على الأقل. واختبر تغيير الاتجاه وزيادة حجم النص ولوحة المفاتيح على الشاشة، لا حالة الوصول وحدها.

الصفحة تمرر جانبياً

العرض: يمتد شريط ضيق من المحتوى وراء الحافة اليمنى. السبب المرجح: عنصر ثابت العرض أو سلسلة غير قابلة للكسر أو جدول أو صورة أو حاوية 100vw أعرض من إطار عرض التخطيط. الإصلاح: استخدم DevTools لفحص أعرض عنصر، واجعل الوسائط متجاوبة، واسمح للنص الطويل بالالتفاف، وفضّل width: 100% داخل الحاويات ذات الحشو. لا تخف الدليل باستخدام overflow-x: hidden قبل إصلاح المصدر.

تستمر أهداف اللمس في الفشل بعد تكبير الأيقونة

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

يصبح النص غير مقروء بعد التحميل

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

أثبت نجاح إصلاح قابلية الاستخدام على الجوال

اختبر نفسك: قابلية الاستخدام على الجوال

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

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

كتاباتي

• الفهرسة المتنقلة أولاً تصبح للجوال وحده ‏(Ahrefs) — دليلي المتعمق للفهرسة المتنقلة أولاً وأفضل ممارسات تصميم الجوال. تنبيه منصف: ما يزال، حتى تحديث يونيو 2024، يوجه القراء إلى تقرير GSC Mobile Usability وMobile-Friendly Test الموقوفين؛ وهي النصيحة القديمة التي يصححها هذا المقال وشيء أنوي تصحيحه هناك.
• The Beginner’s Guide to Technical SEO ‏(Ahrefs) — موضع قابلية الاستخدام على الجوال ضمن صورة SEO التقني الأوسع.
• Core Web Vitals: ما هي وكيف تحسنها ‏(Ahrefs) — جانب الأداء من تجربة الجوال الذي يخلطه الناس بقابلية الاستخدام دائماً.

محاضراتي

• How Search Works ‏(SlideShare) — شرحي للزحف والعرض والفهرسة والترتيب، بما في ذلك زحف Googlebot كهاتف ذكي. تنبيه ثابت: “This is my understanding of systems… not going to be 100% complete or accurate.” (ترجمة) «هذا فهمي للأنظمة… ولن يكون كاملاً أو دقيقاً بنسبة 100 %».

من أنحاء المجال

• The role of page experience in creating helpful content ‏(Google) — تدوينة أبريل 2023 التي أعلنت إيقاف التقرير والأداة وأشارت إلى Lighthouse.
• Google يوقف رسمياً تقرير Mobile Usability وأداة Mobile-Friendly Test والواجهة البرمجية ‏(Search Engine Land، ‏Barry Schwartz) — الإيقاف بلغة مباشرة.
• اختفاء تقرير Mobile Usability واختبارات Mobile-Friendly من Google Search Console ‏(Search Engine Roundtable، ‏Barry Schwartz) — تأكيد الإيقاف في 4 ديسمبر 2023 ووجهة إعادة توجيه العناوين القديمة.
• Document doesn’t use legible font sizes ‏(Chrome / Lighthouse) — عتبة 12px في 60 % من النص.
• أهداف اللمس ليست بالحجم المناسب ‏(Chrome / Lighthouse) — تدقيق 48×48 بكسل CSS وقواعد التباعد.
• تجنب الإعلانات البينية ومربعات الحوار المتطفلة ‏(Google) — تعريف الإعلانات البينية وبديل اللافتة المقبول.
• Bing Mobile Friendliness Test Tool ‏(Bing Webmaster Tools) — لا يزال متاحًا؛ اختبر أي عنوان URL لملاءمة الجوال.

إحصاءات جديرة بالاستشهاد

• حد اجتياز تدقيق مقروئية الخط: 12px في ≥60 % من النص — عتبة Lighthouse الموثقة. لاحظ أنها أرضية اجتياز لا خط أساس نص المتن الموصى به، نحو 16px. المصدر
• يفشل تدقيق أهداف اللمس ما دون 48×48 بكسل CSS، وكذلك عند تداخل ≥25 % ضمن 48px من المركز — Lighthouse. وتقاس المنطقة القابلة للنقر لا الحجم المرئي. المصدر
• الحد الأدنى لحجم الهدف في WCAG 2,2 ‏(SC 2.5.8، المستوى AA): ‏24×24 بكسل CSS — قاعدة مستقلة لامتثال إمكانية الوصول من W3C، لا عتبة ترتيب في بحث Google؛ وهي أصغر من حد تدقيق Lighthouse البالغ 48px لأنها تقيس شيئاً مختلفاً. المصدر
• تاريخ الإيقاف: 1 ديسمبر 2023 — أوقف Google في هذا التاريخ تقرير Mobile Usability وأداة Mobile-Friendly Test والواجهة البرمجية، وأكد ذلك علناً في 4 ديسمبر. المصدر
• أُعلن اكتمال الفهرسة المتنقلة أولاً في 31 أكتوبر 2023 — المحطة التي جعلت تقرير قابلية الاستخدام المخصص والمفصول حسب الجهاز غير ضروري. المصدر

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