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

آخر مراجعة نوفمبر 2026

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

الأرقام التي تستهدفها

تعطيك مقاييس Core Web Vitals من Google ثلاثة مقاييس وهدفًا واضحًا لكل منها.

قِس المئين 75 من تحميلات الصفحة، مع احتساب الهاتف وسطح المكتب كلًّا على حدة. تنجح الصفحة حين تحقق المقاييس الثلاثة الهدف عند هذا المئين.

استخدم بيانات ميدانية من زيارات حقيقية: تقرير Core Web Vitals في Search Console أو PageSpeed Insights أو Chrome User Experience Report. إن Lighthouse مفيد في المختبر، لكنه لا يستطيع قياس INP، ويعرض بدلًا منه Total Blocking Time.

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

صفحة واحدة للشاشتين

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

• المحتوى الأساسي
• العناوين
• البيانات المنظمة
• وسوم robots الوصفية (قد يُبقي وسم noindex شارد صفحة الهاتف خارج الفهرس)

ابدأ بوسم viewport، ثم تحقق من أن الصفحة تُعاد صياغتها عند عرض 320 بكسل CSS دون تمرير جانبي.

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

على الهاتف

• ضع العنوان وسطر الكاتب والتاريخ الظاهر أولًا، ثم الصورة الرئيسية أو الفقرة الافتتاحية.
• أبقِ نص المقال في HTML. فقد يخفي زر «متابعة القراءة» الذي يجلب الباقي عند اللمس ذلك النص عن Google، التي لا تنقر ولا تمرّر ولا تكتب.
• اجعل أهداف اللمس 24 في 24 بكسل CSS على الأقل، وهو الحد الأدنى في WCAG 2.2 AA. وللقوائم وأزرار الإغلاق، استهدف 44 في 44، وهو المستوى AAA.
• أبقِ الترويسة الثابتة قصيرة، واضبط scroll-padding-top على ارتفاعها كي لا يختفي رابط مُركَّز خلفها.

على سطح المكتب

• أبقِ نص المتن عند 80 حرفًا في السطر أو أقل، أو 40 للصينية واليابانية والكورية. هذا إرشاد WCAG AAA، ويفيد كل قارئ.
• اضبط تباعد الأسطر على 1.5 على الأقل داخل الفقرات.
• ضع المحتوى المساند في شريط جانبي لا يحرّك المقال عند تحميله.

تحميل أسرع

كثيرًا ما يكون أكبر عنصر في صفحة الأخبار هو الصورة الرئيسية. تعامل معها بوصفها أهم طلب في الصفحة.

<img
  src="/images/lead-1200.jpg"
  srcset="/images/lead-800.jpg 800w, /images/lead-1200.jpg 1200w"
  sizes="(min-width: 768px) 720px, 100vw"
  width="1200"
  height="675"
  alt="Describe what the photo shows"
  fetchpriority="high">

• لا تؤجّل أبدًا تحميل صورة LCP بالتحميل الكسول.
• ضعها في HTML الأولي، ليجدها المتصفح قبل تشغيل أي سكربت.
• استخدم fetchpriority="high" على صورة أو صورتين على الأكثر. وأكثر من ذلك يفقد فائدته.
• استخدم loading="lazy" فقط للصور وعناصر iframe الواقعة خارج نافذة العرض الأولى.
• قلّل عمليات إعادة التوجيه، وأبقِ الصفحة قابلة للتخزين المؤقت. فقد تعيد معاملات URL الفريدة الطلبات إلى خادم المصدر بدلًا من CDN.

صفحة تثبت في مكانها

• اضبط width وheight على كل صورة وفيديو، وأبقِ height: auto في CSS.
• استخدم نسبة العرض إلى الارتفاع نفسها لكل الصور داخل srcset.
• احجز مساحة للإعلانات والمحتوى المضمَّن وعناصر iframe قبل تحميلها. ويتناول فصل الإعلانات أحجام المساحات.
• اجعل إشعارات ملفات تعريف الارتباط ونوافذ التسجيل تطفو فوق المحتوى، أو احجز لها مكانًا، كي لا تدفع المقال إلى الأسفل.
• استخدم font-display: optional، أو خطًّا احتياطيًّا مضبوطًا ليطابق مقاييس خط الويب لديك.
• حرّك العناصر بـ transform. فتحريك top أو left يسبب تغيّرات في التخطيط.

استجابات سريعة

يتكون إجمالي زمن التفاعل من ثلاثة أجزاء: الانتظار قبل تشغيل كودك، وكودك، والرسم الذي يليه. وأي مهمة تتجاوز 50 ميلي ثانية هي مهمة طويلة.

• افعل أقل ما يمكن في دوال معالجة الأحداث. حدّث الشاشة أولًا، ثم أجّل الباقي.
• جزّئ العمل الطويل بـ scheduler.yield()، واحتط بـ setTimeout في المتصفحات التي لا تدعمه.
• أبقِ DOM صغيرًا. ويمكن لقوائم المقالات الطويلة استخدام content-visibility لعرض العناصر الخارجة عن الشاشة لاحقًا.
• تذكّر أن لكل iframe خيطه الرئيسي الخاص، فتحقق من الإطار الذي جاء منه التفاعل البطيء.

الصفحات الطويلة والتمرير اللانهائي

إذا كانت صفحة قسم تتمرر بلا نهاية، فامنح كل جزء عنوان URL دائمًا خاصًا به برقم صفحة مطلق مثل ?page=12، واربط هذه الصفحات بالتسلسل. وحدّث العنوان بواجهة History API أثناء تقدم القارئ. لا تمرّر Google ولا تنقر، لذلك يجب أن يُحمَّل المحتوى المؤجل حين يدخل نافذة العرض، دون الحاجة إلى أي إجراء.

قائمة التحقق

• افحص LCP وINP وCLS في Search Console، للهاتف وسطح المكتب كلًّا على حدة.
• افتح قالب مقالك الأكثر زيارة على هاتف وتأكد أن العنوان والتاريخ على الشاشة الأولى.
• تأكد أن نص المقال كاملًا موجود في HTML الذي يرسله الخادم.
• قارن الهاتف بسطح المكتب من حيث تطابق المحتوى والعناوين والبيانات المنظمة ووسوم robots.
• أزل loading="lazy" من الصورة الرئيسية وأضف fetchpriority="high".
• أضف width وheight إلى كل صورة وفيديو.
• احجز مساحة لكل إعلان ومحتوى مضمَّن ولافتة.
• اضبط scroll-padding-top ليطابق ترويستك الثابتة.
• اختبر الصفحة عند عرض 320 بكسل CSS.
• امنح كل جزء من صفحة التمرير اللانهائي عنوان URL خاصًا به.

المصادر

• Understanding Google Page Experience, Google Search Central
• Understanding Core Web Vitals and Google search results, Google Search Central
• Mobile-first Indexing Best Practices, Google Search Central
• Fix Lazy-Loaded Website Content, Google Search Central
• Web Vitals, web.dev
• Optimize Largest Contentful Paint, web.dev
• Optimize Cumulative Layout Shift, web.dev
• Optimize Interaction to Next Paint, web.dev
• Optimize long tasks, web.dev
• Browser-level image lazy loading for the web, web.dev
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C
• Understanding Target Size (Enhanced), W3C WAI
• Understanding Visual Presentation, W3C WAI