DEV Community: playgames

لماذا لا أحمّل لعبة الـ iframe فور فتح الصفحة؟

playgames — Thu, 06 Aug 2026 02:00:16 +0000

عند تطوير موقع ألعاب متصفح، يبدو الحل الأسرع واضحًا: نضع رابط اللعبة داخل عنصر iframe، ثم نعرض الصفحة للمستخدم.

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

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

على الهاتف واتصال الإنترنت المتوسط، تكون النتيجة واضحة:

الصفحة تتأخر في الظهور؛
الصورة والعنوان يتحركان أثناء التحميل؛
الهاتف يستهلك بيانات أكثر؛
التمرير يصبح أثقل؛
اللعبة تبدأ في طلب الموارد قبل أن يضغط المستخدم على أي شيء؛
العودة إلى الصفحة السابقة تصبح أبطأ.

لهذا توقفت عن تحميل اللعبة فور فتح الصفحة. أصبحت أعرض غلافًا خفيفًا وزرًا واضحًا، ثم أنشئ iframe فقط عندما يضغط المستخدم على “ابدئي اللعب”.

هذه ليست حركة تجميلية. إنها تغير طريقة تحميل الصفحة بالكامل.

لماذا يمثل الـ iframe عبئًا حقيقيًا؟

عنصر iframe ليس مجرد مستطيل يحتوي على صفحة أخرى.

عندما يحمّله المتصفح، فإنه يفتح مستندًا مستقلًا تقريبًا داخل الصفحة الحالية. وقد يتضمن هذا المستند:

ملفات JavaScript؛
ملفات CSS؛
صورًا وأصواتًا؛
خطوطًا؛
إعلانات؛
أدوات تحليل؛
اتصالات بخوادم إضافية؛
تخزينًا محليًا أو ملفات تعريف ارتباط؛
ملفات اللعبة نفسها.

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

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

`loading="lazy"` مفيد، لكنه ليس الحل الكامل

يمكن إضافة الخاصية التالية:

<iframe
  src="https://example-game-provider.com/game"
  loading="lazy"
  title="لعبة تلبيس"
></iframe>

تطلب loading="lazy" من المتصفح تأجيل تحميل الـ iframe عندما يكون بعيدًا عن الجزء الظاهر من الصفحة. هذا مفيد للعناصر الموجودة أسفل الصفحة، ويقلل تحميل موارد لا يراها المستخدم بعد.

لكن في صفحة لعبة، يكون الـ iframe غالبًا قريبًا من أعلى الصفحة. عندها قد يقرر المتصفح تحميله مبكرًا، لأن المستخدم سيصل إليه بسرعة.

كما أن توقيت التحميل المتكاسل ليس عقدًا صارمًا. المتصفح يأخذ في الاعتبار المسافة من الشاشة والاتصال وعوامل أخرى.

لذلك، إذا كنت لا أريد تحميل اللعبة قبل تفاعل المستخدم فعلًا، فلا أضع رابط اللعبة داخل src منذ البداية.

الحل الذي استخدمته: واجهة غلاف بدل اللعبة

عند فتح الصفحة، أعرض:

صورة حقيقية من اللعبة؛
اسم اللعبة؛
وصفًا قصيرًا؛
زر “ابدئي اللعب”؛
معلومات أن اللعبة تعمل في المتصفح.

لا يوجد iframe نشط في هذه المرحلة.

<section class="game-shell" data-game-url="https://provider.example/game">
  <img
    src="/images/dress-up-game.webp"
    alt="لعبة تلبيس واختيار فساتين وتسريحات شعر"
    width="960"
    height="540"
  >

  <button type="button" class="play-button">
    ابدئي اللعب
  </button>
</section>

عندما يضغط المستخدم على الزر، ينشئ JavaScript عنصر iframe ويستبدل الغلاف به:

const gameShell = document.querySelector(".game-shell");
const playButton = gameShell.querySelector(".play-button");

playButton.addEventListener("click", () => {
  const gameUrl = gameShell.dataset.gameUrl;

  if (!gameUrl) {
    return;
  }

  const iframe = document.createElement("iframe");

  iframe.src = gameUrl;
  iframe.title = "لعبة متصفح";
  iframe.allow = "fullscreen; autoplay";
  iframe.allowFullscreen = true;
  iframe.referrerPolicy = "strict-origin-when-cross-origin";

  gameShell.replaceChildren(iframe);
});

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

لماذا أفضل هذا على زر يغيّر قيمة `src` فقط؟

يمكن وضع iframe فارغ ثم إضافة src عند النقر:

<iframe data-src="https://provider.example/game"></iframe>

ثم:

iframe.src = iframe.dataset.src;

هذا يعمل، لكنه يترك إطارًا فارغًا يحتاج إلى ضبط أبعاده وحالة التحميل.

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

كما يقل خطر أن يبدأ iframe في التحميل بسبب خطأ في القالب أو إضافة تلقائية للخاصية src.

لا تستخدم صورة غلاف عامة

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

الأفضل استخدام لقطة توضّح النشاط الأساسي:

شخصية وملابس في لعبة التلبيس؛
مطبخ ومكونات في لعبة الطبخ؛
وجه وأدوات تجميل في لعبة المكياج؛
أثاث وغرفة في لعبة الديكور.

الغلاف ليس إعلانًا. هو معاينة تساعد المستخدم على تحديد ما إذا كانت اللعبة تناسبه.

لهذا أكتب أيضًا نصًا بديلًا واضحًا للصورة، بدل كلمات عامة مثل “أفضل لعبة رائعة”.

احجز مساحة اللعبة قبل بدء التحميل

عند استبدال الغلاف بالـ iframe، يجب ألا يتغير ارتفاع الصفحة فجأة.

استخدمت نسبة أبعاد ثابتة للحاوية:

.game-shell {
  width: 100%;
  aspect-ratio: 16 / 9;
  overflow: hidden;
  border-radius: 1rem;
  background: #f1f1f1;
}

.game-shell img,
.game-shell iframe {
  display: block;
  width: 100%;
  height: 100%;
  border: 0;
}

.game-shell img {
  object-fit: cover;
}

وجود aspect-ratio يعني أن المتصفح يعرف مساحة اللعبة قبل وصول الصورة أو إنشاء الـ iframe.

هذا يمنع المحتوى الموجود أسفل اللعبة من القفز عند بدء التشغيل.

لا تؤجل صورة الغلاف الرئيسية

قد يبدو من المنطقي وضع loading="lazy" على كل الصور، لكن صورة الغلاف الموجودة في أعلى صفحة اللعبة غالبًا هي أكبر عنصر مرئي للمستخدم.

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

لذلك أتعامل مع الصور بهذه الطريقة:

صورة اللعبة الرئيسية: تحميل عادي؛
أول صف من الألعاب المشابهة: تحميل عادي أو حسب موقعه الفعلي؛
البطاقات الموجودة أسفل الصفحة: loading="lazy".

<img
  src="/images/main-game.webp"
  alt="لعبة طبخ وتزيين كعكة"
  width="960"
  height="540"
  fetchpriority="high"
>

ولا أضع fetchpriority="high" على عشر صور. الأولوية المرتفعة يجب أن تبقى للعنصر الأساسي فقط.

ماذا عن الصفحة التي تعرض عشرات الألعاب؟

في صفحة التصنيف، المشكلة ليست iframe بل الصور.

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

هناك أستخدم:

<img
  src="/images/game-card.webp"
  alt="لعبة مكياج وتسريح شعر"
  width="320"
  height="180"
  loading="lazy"
  decoding="async"
>

لكنني لا أضيف loading="lazy" تلقائيًا إلى جميع البطاقات. الصور الظاهرة فور فتح الصفحة يجب أن تصل بسرعة.

أفضل تقسيم عملي هو:

الصور داخل أول شاشة: تحميل عادي؛
الصور القريبة منها: يمكن أن يقرر المتصفح تحميلها؛
بقية القائمة: تحميل متكاسل.

المبالغة في التحميل المتكاسل قد تؤخر الصور التي ينتظرها المستخدم فعلًا.

استخدم صورًا متعددة المقاسات

إرسال صورة بعرض 1200 بكسل إلى بطاقة لا يتجاوز عرضها 240 بكسل يهدر البيانات.

استخدمت srcset حتى يختار المتصفح الحجم المناسب:

<img
  src="/images/game-480.webp"
  srcset="
    /images/game-320.webp 320w,
    /images/game-480.webp 480w,
    /images/game-640.webp 640w
  "
  sizes="
    (max-width: 600px) 50vw,
    (max-width: 1100px) 33vw,
    240px
  "
  alt="لعبة اختيار أزياء أميرة"
  width="320"
  height="180"
  loading="lazy"
>

هذه الخطوة أهم من تبديل امتداد الصورة فقط. صورة WebP كبيرة جدًا قد تبقى أثقل من JPEG بالحجم الصحيح.

لا تجعل الصفحة الرئيسية تحمل الألعاب نفسها

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

الفكرة تبدو سريعة، لكنها سيئة عمليًا.

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

حتى لو استخدمت loading="lazy"، تصبح بنية الصفحة معقدة ويصعب التحكم في الموارد.

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

زر التشغيل يجب أن يكون مختلفًا عن الإعلان

في مواقع الألعاب، يشعر المستخدم بالشك عندما يرى عدة أزرار كبيرة تحمل كلمات مثل:

تحميل؛
ابدأ الآن؛
تشغيل؛
تثبيت؛
متابعة.

إذا كان زر اللعبة يشبه إعلان التنزيل، فقد يتردد المستخدم أو يضغط على العنصر الخطأ.

استخدمت زرًا واحدًا داخل الغلاف، في مكان ثابت، مع نص واضح:

ابدئي اللعب

لا أستخدم كلمة “تحميل” لأن اللعبة لا تحتاج إلى ملف.

ولا أستخدم “التالي” لأنها لا توضّح ما سيحدث.

أضف حالة تحميل بعد النقر

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

لذلك أعرض مؤشرًا داخل الحاوية حتى يطلق iframe حدث load:

playButton.addEventListener("click", () => {
  const gameUrl = gameShell.dataset.gameUrl;

  gameShell.innerHTML = `
    <div class="game-loading" role="status">
      جارٍ تحميل اللعبة…
    </div>
  `;

  const iframe = document.createElement("iframe");

  iframe.src = gameUrl;
  iframe.title = "لعبة متصفح";
  iframe.allowFullscreen = true;
  iframe.hidden = true;

  iframe.addEventListener("load", () => {
    const loading = gameShell.querySelector(".game-loading");

    if (loading) {
      loading.remove();
    }

    iframe.hidden = false;
  });

  gameShell.appendChild(iframe);
});

لكن لا أعد المستخدم بأن اللعبة ستفتح خلال رقم محدد من الثواني، لأن سرعة الخادم الخارجي ليست تحت سيطرتي.

ضع مهلة وخيار إعادة المحاولة

بعض الألعاب لا تُحمّل بسبب انقطاع الشبكة، حظر النطاق، مشكلة في المصدر أو توقف اللعبة نفسها.

يمكن إضافة مهلة بسيطة:

const timeoutId = window.setTimeout(() => {
  if (!iframe.hidden) {
    return;
  }

  gameShell.innerHTML = `
    <div class="game-error">
      <p>تعذر تحميل اللعبة.</p>
      <button type="button" data-retry>حاولي مرة أخرى</button>
    </div>
  `;
}, 15000);

iframe.addEventListener("load", () => {
  window.clearTimeout(timeoutId);
  iframe.hidden = false;
});

حدث load لا يضمن أن اللعبة تعمل بالكامل، خصوصًا مع المحتوى الخارجي، لكنه أفضل من ترك المستخدم أمام مساحة فارغة إلى ما لا نهاية.

لا تثق بأي رابط لعبة يدخل قاعدة البيانات

إذا كان الموقع يستورد ألعابًا من مصادر خارجية، فلا يجب وضع أي رابط مستلم مباشرة داخل iframe.

أتحقق من النطاق المسموح:

from urllib.parse import urlparse

ALLOWED_GAME_HOSTS = {
    "games.example-provider.com",
    "cdn.example-provider.com",
}

def is_allowed_game_url(url: str) -> bool:
    parsed = urlparse(url)

    return (
        parsed.scheme == "https"
        and parsed.hostname in ALLOWED_GAME_HOSTS
    )

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

لا أستخدم مقارنة تنتهي باسم النطاق فقط، لأن نطاقًا مثل:

games.example-provider.com.attacker.example

ليس تابعًا للمصدر المسموح.

فكر في صلاحيات iframe

لا أعطي اللعبة صلاحيات أكثر مما تحتاج.

إذا كانت اللعبة تحتاج إلى ملء الشاشة، أضيف ذلك صراحة:

allow="fullscreen; autoplay"

إذا لم تكن بحاجة إلى الكاميرا أو الميكروفون أو الموقع الجغرافي، فلا أضيف هذه الصلاحيات.

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

الأفضل اختبار كل مصدر وتحديد الحد الأدنى من الصلاحيات بدل نسخ قائمة واسعة من الإنترنت.

ما علاقة ذلك بالبحث عن ألعاب البنات؟

من يبحث عن العاب بنات لا يهتم باسم تقنية التحميل التي استخدمتها.

لكنه يهتم بنتيجتها مباشرة:

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

الأداء هنا ليس رقمًا في تقرير Lighthouse فقط. الأداء هو تقليل الوقت بين اختيار اللعبة والبدء الفعلي.

لا تجعل نتيجة Lighthouse هي الهدف الوحيد

يمكن أن تحصل صفحة غلاف بلا لعبة على نتيجة أداء ممتازة، ثم يضغط المستخدم ويجد أن اللعبة نفسها بطيئة جدًا.

لذلك أختبر مرحلتين منفصلتين:

قبل الضغط على التشغيل

أقيس:

سرعة ظهور العنوان والصورة؛
استقرار التخطيط؛
حجم الصفحة الأولي؛
سرعة التفاعل مع زر اللعب.

بعد الضغط على التشغيل

أراقب:

الوقت حتى ظهور محتوى اللعبة؛
هل يتجمد التمرير؟
هل يتغير ارتفاع الحاوية؟
هل تعمل اللعبة على الهاتف؟
هل تظهر رسائل خطأ؟
هل يفتح المصدر نوافذ جديدة؟

صفحة سريعة قبل التشغيل لا تعني أن تجربة اللعب جيدة، لكنها تمنع اللعبة الخارجية من إفساد الصفحة قبل أن يطلبها المستخدم.

متى أحمّل اللعبة تلقائيًا؟

لا أرى أن التحميل بعد النقر قاعدة إلزامية لكل موقع.

قد يكون التحميل التلقائي مناسبًا عندما:

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

لكن في دليل يحتوي على عدد كبير من الألعاب ومصادر متعددة، أفضّل التحميل بعد التفاعل.

إنه قرار يمنحني تحكمًا أكبر ويمنع استهلاك الموارد لمن يغادر الصفحة قبل اللعب.

الخلاصة

أكبر خطأ في صفحات ألعاب المتصفح هو افتراض أن وجود iframe يعني أن اللعبة جاهزة.

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

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

الهدف ليس منع تحميل اللعبة، بل تحميلها في اللحظة التي تصبح فيها مفيدة.

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

ما تعلمته من بناء واجهة RTL لموقع ألعاب عربية تعمل على الهاتف

playgames — Thu, 06 Aug 2026 01:59:10 +0000

عند بناء موقع عربي للألعاب، من السهل أن نعتقد أن دعم اللغة العربية يعني ترجمة العناوين، وإضافة dir="rtl" إلى عنصر html، ثم اعتبار المهمة منتهية.

هذا يكفي لجعل النص يبدأ من اليمين، لكنه لا يكفي لصناعة تجربة جيدة.

المستخدم الذي يصل إلى موقع ألعاب لا يريد قراءة مقدمة طويلة عن المشروع. يريد أن يعرف بسرعة:

ما نوع اللعبة؟
هل تعمل على الهاتف؟
هل تحتاج إلى تحميل؟
أين زر التشغيل؟
هل يستطيع الرجوع إلى الألعاب المشابهة بسهولة؟

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

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

ابدأ من نية المستخدم، لا من تصميم القالب

قبل كتابة أي مكوّن، يجب فهم سبب دخول الزائر إلى الصفحة.

من يبحث عن ألعاب بنات لا يبحث غالبًا عن مراجعة طويلة أو أخبار صناعة الألعاب. هو يريد فتح لعبة من نوع واضح، مثل:

تلبيس؛
طبخ؛
مكياج؛
تزيين غرف؛
عناية بالحيوانات؛
ألعاب أميرات؛
ألعاب خفيفة تعمل على الهاتف.

لذلك لا يجب أن يبدأ الموقع بشاشة ترحيب ضخمة تدفع الألعاب إلى أسفل الصفحة. كما لا يحتاج المستخدم إلى فقرة طويلة قبل أن يرى أول صف من الألعاب.

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

القرار الصحيح بالنسبة لي كان عرض عنوان واضح، وصف قصير جدًا، ثم الألعاب مباشرة.

استخدام `dir="rtl"` لا يحل كل شيء

الخطوة الأساسية هي تحديد اللغة والاتجاه على مستوى الصفحة:

<html lang="ar" dir="rtl">

هذا يجعل المتصفح يتعامل مع النصوص والتخطيط الافتراضي بصورة أفضل، لكنه لا يحل العناصر التي تجمع العربية مع الإنجليزية والأرقام والروابط.

مثال شائع هو عنوان يحتوي على اسم لعبة إنجليزي داخل جملة عربية. قد تنتقل الأقواس أو الأرقام إلى مكان غير متوقع، وقد يظهر الرابط بطريقة مربكة.

في الحالات المختلطة يمكن استخدام:

<bdi>Cooking Game 2</bdi>

عنصر bdi يعزل اتجاه النص الداخلي، ويمنع اسم اللعبة من إفساد ترتيب الجملة العربية المحيطة به.

استخدمته خصوصًا مع:

أسماء الألعاب الإنجليزية؛
أرقام المراحل؛
أسماء الملفات؛
النطاقات والروابط؛
أسماء التقنيات أو الشركات.

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

لا تعكس كل شيء لمجرد أن الصفحة RTL

من الأخطاء الشائعة قلب جميع الأيقونات تلقائيًا.

هناك عناصر يجب أن تتبع اتجاه القراءة، مثل سهم الانتقال إلى القسم السابق أو التالي. لكن توجد رموز عالمية لا تحتاج إلى قلب، مثل:

زر التشغيل؛
أيقونة الصوت؛
أيقونة ملء الشاشة؛
رمز الإغلاق؛
أيقونة البحث؛
رمز المشاركة.

كذلك، لقطة اللعبة نفسها لا يجب قلبها أفقيًا. صورة المطبخ أو الشخصية أو واجهة اللعبة يجب أن تبقى كما هي.

عند استخدام مكتبة أيقونات، لا تطبق transform: scaleX(-1) على حاوية كاملة. اقلب فقط السهم الذي يمثل اتجاه التنقل عندما تكون هناك حاجة حقيقية لذلك.

بطاقة اللعبة يجب أن تجيب قبل النقر

بطاقة اللعبة ليست مجرد صورة جميلة. هي أداة لاتخاذ القرار.

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

إذا كانت اللعبة عن الطبخ، من الأفضل أن تظهر:

الطعام؛
أدوات المطبخ؛
المكونات؛
أو واجهة إعداد الطلبات.

إذا كانت عن التلبيس، يجب أن تظهر الشخصية والملابس أو شاشة اختيار الأزياء.

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

أفضل بنية وجدتها للبطاقة كانت بسيطة:

<article class="game-card">
  <a href="/games/example-game/">
    <img
      src="/images/example-game.webp"
      alt="لعبة تلبيس واختيار فساتين للحفلة"
      width="320"
      height="180"
      loading="lazy"
    >
    <h2>لعبة تلبيس للحفلة</h2>
    <p>اختاري الفستان وتسريحة الشعر والإكسسوارات.</p>
  </a>
</article>

العنوان يوضح النوع، والوصف يذكر الفعل الذي سيقوم به اللاعب. لا حاجة إلى عبارات مثل “أفضل لعبة مذهلة لن تنسيها”.

اجعل مساحة النقر تشمل البطاقة

على الهاتف، النقر على عنوان صغير ليس مريحًا.

لذلك جعلت الصورة والعنوان والوصف جزءًا من رابط واحد. يستطيع المستخدم النقر على أي مساحة داخل البطاقة بدل محاولة إصابة زر صغير.

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

رابط واحد واضح أفضل.

الشبكة المرنة أهم من عدد الأعمدة

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

استخدمت شبكة تعتمد على الحد الأدنى لعرض البطاقة:

.games-grid {
  display: grid;
  grid-template-columns: repeat(
    auto-fill,
    minmax(min(100%, 220px), 1fr)
  );
  gap: 1rem;
}

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

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

النص العربي قد يحتاج إلى سطرين بينما يحتاج اسم إنجليزي إلى سطر واحد. يجب أن تتحمل البطاقة هذا الاختلاف من دون تداخل.

لا تجعل العنوان الطويل يكسر شكل الصفحة

أسماء بعض الألعاب طويلة، خصوصًا عند محاولة وصف كل شيء داخل العنوان:

“لعبة تلبيس ومكياج وقص شعر وتجهيز الأميرة لحفل الزفاف”.

هذا النوع من العناوين قد يكون مفهومًا لمحرك البحث، لكنه سيئ داخل بطاقة صغيرة.

الأفضل فصل الوظائف:

العنوان:

لعبة تجهيز الأميرة للحفل

الوصف:

اختاري الفستان والمكياج وتسريحة الشعر.

العنوان يحدد اللعبة، والوصف يشرح التفاصيل. لا تحتاج إلى وضع جميع الكلمات في السطر نفسه.

يمكن أيضًا تحديد عدد الأسطر داخل البطاقات:

.game-card h2 {
  display: -webkit-box;
  -webkit-line-clamp: 2;
  -webkit-box-orient: vertical;
  overflow: hidden;
}

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

التصنيفات يجب أن تطابق ما يبحث عنه اللاعب

من السهل على المطور إنشاء تصنيفات مبنية على بنية البيانات الداخلية، مثل:

ألعاب ثنائية الأبعاد؛
ألعاب HTML5؛
ألعاب Canvas؛
ألعاب تعمل باللمس.

هذه التصنيفات مفيدة للمطور، لكنها ليست الطريقة التي يبحث بها اللاعب.

المستخدم لا يقول عادة: أريد لعبة Canvas.

هو يقول:

أريد لعبة طبخ؛
أريد لعبة تلبيس؛
أريد لعبة مكياج؛
أريد لعبة أميرات؛
أريد لعبة حيوانات.

لذلك يجب أن تعكس القائمة لغة المستخدم، لا لغة قاعدة البيانات.

يمكن الاحتفاظ بالتقنيات والخصائص في الخلفية لأغراض الفلترة، لكن التصنيفات العامة يجب أن تكون مفهومة فورًا.

لا تنشئ عشرات التصنيفات الفارغة

إضافة كل تصنيف يمكن تخيله تبدو طريقة سهلة لتوسيع الموقع، لكنها تؤدي إلى صفحات ضعيفة تحتوي على لعبة أو لعبتين فقط.

من الأفضل إنشاء تصنيف عندما توجد مجموعة حقيقية من الألعاب التي تشترك في نية واضحة.

على سبيل المثال، يمكن جمع ألعاب إعداد الكعك والبيتزا والمطاعم تحت “ألعاب طبخ” إذا لم يكن هناك عدد كافٍ لبناء صفحة مستقلة لكل نوع.

التقسيم الزائد يجعل المستخدم ينتقل بين صفحات كثيرة ولا يجد خيارات كافية في أي صفحة.

صفحة اللعبة يجب أن تضع اللعب قبل الشرح

عندما يفتح المستخدم صفحة لعبة، لا يريد النزول عبر مقال طويل حتى يصل إلى زر التشغيل.

رتبت صفحة اللعبة بهذا الشكل:

اسم اللعبة؛
وصف قصير يوضح المهمة؛
منطقة التشغيل؛
تعليمات مختصرة عند الحاجة؛
ألعاب مشابهة؛
معلومات إضافية في الأسفل.

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

استخدام عبارة “ابدئي اللعب” أفضل من زر غامض يحمل كلمة “التالي”.

لا تستخدم زر تنزيل في موقع ألعاب متصفح

إذا كانت اللعبة تعمل داخل المتصفح، فلا يوجد سبب لاستخدام كلمات توحي بالتثبيت.

كلمات مثل:

تحميل؛
تنزيل؛
تثبيت؛
Get App؛

قد تجعل الزائر يعتقد أنه سيغادر الصفحة أو يثبت ملفًا.

استخدم:

العب الآن؛
ابدأ اللعبة؛
افتح اللعبة؛
جرّب اللعبة.

النص يجب أن يصف ما سيحدث بعد النقر بدقة.

اختبر الصفحة بإبهام واحد

اختبار سطح المكتب لا يكفي.

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

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

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

ثبّت أبعاد الصور قبل تحميلها

عندما لا تحدد أبعاد الصور، تتحرك البطاقات أثناء التحميل. قد يحاول المستخدم النقر على لعبة، ثم تنتقل البطاقة فجأة ويضغط على لعبة أخرى.

لذلك أضفت width وheight إلى الصور، واستخدمت aspect-ratio في CSS:

.game-card img {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
  border-radius: 0.75rem;
}

هذا يحجز المساحة قبل وصول الصورة ويجعل الشبكة أكثر استقرارًا.

لا تؤجل الصورة الأولى

استخدام loading="lazy" مفيد للبطاقات الموجودة أسفل الصفحة، لكنه ليس مناسبًا دائمًا لأول صور يراها المستخدم.

يمكن تحميل الصور الأولى بصورة طبيعية، وتأجيل الصور البعيدة فقط. تأجيل كل الصور قد يجعل أعلى الصفحة يبدو فارغًا للحظات، خصوصًا على اتصال بطيء.

كما أن ضغط الصور وتحويلها إلى WebP أو AVIF يقلل وقت الانتظار أكثر من إضافة مؤثر تحميل جميل.

ماذا فعلت في المشروع الفعلي؟

طبقت هذه القرارات أثناء تنظيم موقع العاب بنات ليكون الوصول إلى ألعاب الطبخ والتلبيس والمكياج وغيرها مباشرًا قدر الإمكان.

لم يكن الهدف عرض أكبر عدد من المكونات أو المؤثرات. الهدف كان تقليل عدد الخطوات بين دخول الصفحة وبدء اللعبة.

كل عنصر لا يساعد على اختيار لعبة أو تشغيلها يحتاج إلى سبب قوي للبقاء.

لا تجعل RTL نسخة معكوسة من التصميم الإنجليزي

أفضل واجهة عربية ليست دائمًا التصميم الإنجليزي نفسه بعد قلب الاتجاه.

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

التصميم الجيد يبدأ من المحتوى العربي نفسه:

طول الكلمات؛
اتجاه القراءة؛
طريقة خلط الأسماء الأجنبية؛
أحجام الخطوط؛
استخدام الهاتف؛
ترتيب المعلومات الذي يتوقعه الزائر.

RTL ليس تأثيرًا بصريًا. هو جزء من بنية الصفحة.

الخلاصة

بناء موقع ألعاب عربي جيد لا يتطلب واجهة معقدة، لكنه يتطلب قرارات دقيقة.

استخدم lang="ar" وdir="rtl" من البداية، واعزل النصوص الأجنبية، ولا تقلب الأيقونات والصور بلا سبب. اجعل بطاقة اللعبة تشرح نوعها قبل النقر، واستخدم تصنيفات يفهمها اللاعب، وضع منطقة التشغيل في أعلى صفحة اللعبة.

الأهم من ذلك: اختبر المسار الكامل على الهاتف.

هل يستطيع المستخدم دخول الموقع، فهم نوع اللعبة، فتحها والبدء خلال وقت قصير؟

إذا كانت الإجابة لا، فلن تعالج المشكلة فقرة تسويقية إضافية أو حركة بصرية جديدة. يجب تقليل الخطوات وإزالة العناصر التي تعطل اللعب.

DEV Community: playgames

لماذا لا أحمّل لعبة الـ iframe فور فتح الصفحة؟

لماذا يمثل الـ iframe عبئًا حقيقيًا؟

loading="lazy" مفيد، لكنه ليس الحل الكامل

الحل الذي استخدمته: واجهة غلاف بدل اللعبة

لماذا أفضل هذا على زر يغيّر قيمة src فقط؟

لا تستخدم صورة غلاف عامة

احجز مساحة اللعبة قبل بدء التحميل

لا تؤجل صورة الغلاف الرئيسية

ماذا عن الصفحة التي تعرض عشرات الألعاب؟

استخدم صورًا متعددة المقاسات

لا تجعل الصفحة الرئيسية تحمل الألعاب نفسها

زر التشغيل يجب أن يكون مختلفًا عن الإعلان

أضف حالة تحميل بعد النقر

ضع مهلة وخيار إعادة المحاولة

لا تثق بأي رابط لعبة يدخل قاعدة البيانات

فكر في صلاحيات iframe

ما علاقة ذلك بالبحث عن ألعاب البنات؟

لا تجعل نتيجة Lighthouse هي الهدف الوحيد

قبل الضغط على التشغيل

بعد الضغط على التشغيل

متى أحمّل اللعبة تلقائيًا؟

الخلاصة

ما تعلمته من بناء واجهة RTL لموقع ألعاب عربية تعمل على الهاتف

ابدأ من نية المستخدم، لا من تصميم القالب

استخدام dir="rtl" لا يحل كل شيء

لا تعكس كل شيء لمجرد أن الصفحة RTL

بطاقة اللعبة يجب أن تجيب قبل النقر

اجعل مساحة النقر تشمل البطاقة

الشبكة المرنة أهم من عدد الأعمدة

لا تجعل العنوان الطويل يكسر شكل الصفحة

التصنيفات يجب أن تطابق ما يبحث عنه اللاعب

لا تنشئ عشرات التصنيفات الفارغة

صفحة اللعبة يجب أن تضع اللعب قبل الشرح

لا تستخدم زر تنزيل في موقع ألعاب متصفح

اختبر الصفحة بإبهام واحد

ثبّت أبعاد الصور قبل تحميلها

لا تؤجل الصورة الأولى

ماذا فعلت في المشروع الفعلي؟

لا تجعل RTL نسخة معكوسة من التصميم الإنجليزي

الخلاصة

`loading="lazy"` مفيد، لكنه ليس الحل الكامل

لماذا أفضل هذا على زر يغيّر قيمة `src` فقط؟

استخدام `dir="rtl"` لا يحل كل شيء