مشروع تطبيقي: إنقاذ صفحة هبوط عربية من الاختناق التقني
مشروع تطبيقي متكامل: نفحص صفحة هبوط عربية تعاني بطء التحميل ومشاكل الخطوط، ونطبق تقنيات الطبوغرافيا الرقمية خطوة بخطوة ونقيس القفزة بـ Google Lighthouse.
٢٬٦٠٠ كلمة تقريباً، مدة القراءة: ١٢ دقيقة
تشخيص: دراسة حالة عملية
دليل تطبيقي خطوة بخطوة لتحسين الطبوغرافيا والسيو التقني لصفحة هبوط
من النظرية إلى الميدان
في المقالات الثلاثة السابقة بنينا الإطار النظري: فهمنا لماذا التوطين أعمق من الترجمة، وكيف تُسبب الخطوط العربية اهتزازاً في الصفحة، وكيف تتحول الروابط العربية إلى سلاسل مشفرة تُضر بالزحف. الآن جاء وقت التطبيق.
في هذا المشروع سنأخذ صفحة هبوط عربية افتراضية تعاني من مشاكل أداء نموذجية — وهي المشاكل التي تراها في معظم المواقع العربية القائمة — ونمر بها خطوة بخطوة: التشخيص، ثم التطبيق، ثم القياس.
الهدف ليس الوصول إلى درجة ١٠٠ في Lighthouse. الهدف هو فهم ما يؤثر فعلاً على تجربة المستخدم العربي وعلى سلوك جوجل، وتطبيق الحلول بترتيب يُعطي أكبر عائد بأقل جهد.
صفحة المريض: التشخيص الأولي
لنفترض أن لدينا صفحة هبوط لخدمة عربية. نفتح Google PageSpeed Insights ونُدخل الرابط. التقرير الأول يكشف:
| المؤشر | القيمة الأولية | التقييم | السبب المشتبه |
|---|---|---|---|
| LCP | ٥.٢ ثانية | ❌ ضعيف | خط عربي ثقيل من Google Fonts |
| CLS | ٠.٣٨ | ❌ ضعيف | تمدد الخط عند التحميل |
| INP | ٢٨٠ مللي ثانية | ⚠️ يحتاج تحسين | سكريبتات تحجب الـ main thread |
| FCP | ٣.١ ثانية | ⚠️ يحتاج تحسين | render-blocking resources |
هذه الأرقام ليست افتراضية — هي نموذجية جداً لصفحات هبوط عربية تستخدم خطوطاً من Google Fonts دون تحسين. الترتيب الذي سنعالج به المشاكل مهم: نبدأ بما يؤثر على CLS لأنه الأعلى تأثيراً على تجربة المستخدم وتصنيف جوجل، ثم LCP، ثم الباقي.
الخطوة الأولى: تشخيص مصادر الـ CLS
قبل أن نكتب سطراً من الكود، نحتاج أن نعرف بالضبط أي عناصر تتحرك وماذا يُحركها. نفتح Chrome DevTools (F12) ← Performance ← نضغط Record ثم نُعيد تحميل الصفحة.
في التقرير سنرى خطاً زمنياً يُظهر متى حدث كل انزياح. في حالتنا، الانزياح الأكبر يحدث في الثانية الثانية والنصف — وهذا يتطابق تماماً مع وقت وصول ملف الخط من Google Fonts.
أداة إضافية مفيدة جداً: في نفس لوحة DevTools، تبويب Rendering (افتحه من النقاط الثلاث ← More tools ← Rendering) — فعّل خيار Layout Shift Regions. ستظهر العناصر التي تتحرك باللون الأزرق لحظة حدوث الانزياح — طريقة بصرية ممتازة لتحديد المشكلة بدقة.
في صفحتنا: العنوان الرئيسي H1 والفقرة الأولى هما المصدران الرئيسيان للانزياح. كلاهما يستخدم خط Cairo من Google Fonts — وهو خط عربي جميل لكن ملفه يزن ١٨٠ كيلوبايت، وهو يُحمَّل من خوادم جوجل الخارجية بدون أي تعليمات `font-display`.
الخطوة الثانية: معالجة الخطوط (المشكلة الجذرية)
نبدأ بالمشكلة الأكبر أثراً. لدينا ثلاثة قرارات نتخذها معاً:
أ — الانتقال إلى الاستضافة الذاتية مع WOFF2
نذهب إلى Google Webfonts Helper، نختار Cairo بالأوزان التي نحتاجها (٤٠٠ و٧٠٠)، ونُحمّل ملفات WOFF2. نضعها في مجلد /fonts/ على خادمنا.
/* قبل: تحميل من Google Fonts - بدون font-display */
@import url('https://fonts.googleapis.com/css2?family=Cairo:wght@400;700');
/* بعد: استضافة ذاتية مع font-display:swap */
@font-face {
font-family: 'Cairo';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url('/fonts/cairo-v29-arabic-regular.woff2') format('woff2');
unicode-range: U+0600-06FF, U+200C-200E, U+2010-2011,
U+204F, U+2E41, U+FB50-FDFF, U+FE80-FEFC;
}
@font-face {
font-family: 'Cairo';
font-style: normal;
font-weight: 700;
font-display: swap;
src: url('/fonts/cairo-v29-arabic-700.woff2') format('woff2');
unicode-range: U+0600-06FF, U+200C-200E, U+2010-2011,
U+204F, U+2E41, U+FB50-FDFF, U+FE80-FEFC;
}
ب — معايرة الخط الاحتياطي
font-display: swap وحده يحل مشكلة FOIT لكن لا يزيل الانزياح تماماً. نضيف خطاً احتياطياً مُعاير الأبعاد:
/* خط احتياطي مُعاير ليُشابه Cairo في الأبعاد */
@font-face {
font-family: 'Cairo-Fallback';
src: local('Arial');
ascent-override: 102%;
descent-override: 26%;
line-gap-override: 0%;
size-adjust: 98%;
}
body {
font-family: 'Cairo', 'Cairo-Fallback', sans-serif;
}
ج — preload للخط الأساسي
لخفض LCP، نُخبر المتصفح بتحميل الخط بأولوية عالية قبل بدء معالجة CSS:
<!-- في <head> قبل أي <link> آخر -->
<link rel="preload"
href="/fonts/cairo-v29-arabic-regular.woff2"
as="font"
type="font/woff2"
crossorigin>
هذا السطر وحده يمكن أن يخفض LCP بمقدار ثانية كاملة أو أكثر — لأن المتصفح يبدأ تحميل الخط في أول لحظة ممكنة بدلاً من انتظار معالجة CSS.
الخطوة الثالثة: الانتقال إلى الخطوط المتغيرة (اختياري لكن مثالي)
إذا كان Cairo متاحاً كخط متغير (Variable Font) — وهو كذلك — نستطيع استبدال ملفين منفصلين بملف واحد يغطي جميع الأوزان:
@font-face {
font-family: 'Cairo';
font-style: normal;
font-weight: 200 900; /* نطاق كامل */
font-display: swap;
src: url('/fonts/cairo-variable.woff2') format('woff2-variations');
unicode-range: U+0600-06FF, U+200C-200E, U+2010-2011,
U+204F, U+2E41, U+FB50-FDFF, U+FE80-FEFC;
}
النتيجة: طلب واحد بدلاً من طلبين، وحجم ملف إجمالي أصغر في معظم الحالات. الفائدة تتضاعف كلما زادت أوزان الخطوط المستخدمة في الصفحة.
الخطوة الرابعة: معالجة موارد الـ Render-Blocking
Lighthouse يُظهر مصادر تمنع رسم الصفحة (render-blocking resources). في صفحتنا هناك ثلاثة أنواع:
١ — ملفات CSS الخارجية غير الحيوية
ملفات CSS التي لا تؤثر على ما يُرى فوق الطية (above the fold) يمكن تحميلها بشكل غير متزامن:
<!-- قبل: يحجب الرسم -->
<link rel="stylesheet" href="/css/icons.css">
<!-- بعد: يُحمَّل بدون حجب -->
<link rel="stylesheet" href="/css/icons.css"
media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/css/icons.css"></noscript>
٢ — ملفات JavaScript
أي سكريبت لا يحتاج تنفيذاً فورياً يحصل على defer أو async:
<!-- قبل -->
<script src="/js/analytics.js"></script>
<!-- بعد: لا يحجب تحليل HTML -->
<script src="/js/analytics.js" defer></script>
٣ — Critical CSS مُضمَّن
الأسلوب الأمثل: استخراج CSS الحيوي (ما يؤثر على الثلث الأول من الصفحة) وتضمينه مباشرة في <head> كـ inline style، ثم تحميل باقي CSS بشكل غير متزامن. هذا يُصفّر وقت انتظار CSS الحيوي.
<head>
<!-- CSS الحيوي مُضمَّن مباشرة -->
<style>
body { font-family: 'Cairo', sans-serif; direction: rtl; }
h1 { font-size: 2em; color: #1a3a5c; }
.hero { padding: 60px 20px; background: #f8f9fa; }
</style>
<!-- باقي CSS يُحمَّل بدون حجب -->
<link rel="stylesheet" href="/css/main.css"
media="print" onload="this.media='all'">
</head>
استخراج الـ Critical CSS يدوياً مجهد. أداة criticalcss.com أو إضافة Autoptimize في ووردبريس تتولى ذلك تلقائياً — لكن راجع النتيجة دائماً لأن الأتمتة قد تُخفي عناصر مهمة.
الخطوة الخامسة: تحسين الصور فوق الطية
الصورة الرئيسية (Hero Image) في صفحة الهبوط هي في الغالب عنصر LCP — أي العنصر الأكبر الذي يظهر في الثلث الأول من الشاشة. ثلاثة قرارات سريعة:
١ — تنسيق WebP أو AVIF
<picture>
<source srcset="/hero-ar.avif" type="image/avif">
<source srcset="/hero-ar.webp" type="image/webp">
<img src="/hero-ar.jpg" alt="وصف الصورة بالعربية"
width="1200" height="600">
</picture>
٢ — fetchpriority=”high” للصورة الرئيسية
<img src="/hero-ar.webp"
alt="وصف الصورة"
fetchpriority="high"
loading="eager"
width="1200" height="600">
٣ — تحديد الأبعاد دائماً
غياب width وheight في وسم الصورة يُسبب CLS — المتصفح لا يعرف المساحة المطلوبة قبل تحميل الصورة فيُزحزح ما تحتها. تحديد الأبعاد يحل هذا بالكامل.
الخطوة السادسة: مراجعة بنية الروابط
هذا ما تناولناه في المقال الثالث، لكن في سياق مشروع كامل لا بد من ذكره ضمن قائمة التحقق. نفتح أداة URL Decode ونفحص سلاغ الصفحة:
- هل الـ slug إنكليزي قصير ودلالي؟ ✅ أو عربي مشفَّر؟ ❌
- هل يوجد canonical tag صحيح؟
- هل يوجد hreflang إذا كانت للصفحة نسخة بلغة أخرى؟
- هل البنية الهرمية لا تتجاوز ثلاثة مستويات؟
في صفحة الهبوط التجارية تحديداً، هذه النقاط بالغة الأهمية لأن الصفحة عادةً هي الهدف الأساسي للحملات الإعلانية — وأي تشتت في رصيد الروابط أو ازدواجية في الفهرسة يُقلل من العائد على الإنفاق الإعلاني.
الخطوة السابعة: قياس النتائج بـ Lighthouse
بعد تطبيق التحسينات، نُعيد القياس. لكن ثمة نقطة مهمة: Lighthouse يُعطي نتائج مختلفة في كل تشغيل بسبب التباين في ظروف الشبكة والخادم. القاعدة الصحيحة هي تشغيله ثلاث مرات متتالية وأخذ المتوسط.
كيف نُشغّل Lighthouse بشكل صحيح:
- افتح Chrome في نافذة Incognito (لتجنب تأثير الإضافات والكاش)
- افتح DevTools (F12) ← تبويب Lighthouse
- اختر: Mode = Navigation، Device = Mobile (الأهم لجوجل)
- شغّله ثلاث مرات وسجّل الأرقام
النتائج بعد تطبيق الخطوات السابقة:
| المؤشر | قبل | بعد | التحسن |
|---|---|---|---|
| LCP | ٥.٢ ث | ١.٨ ث | ↓ ٦٥٪ |
| CLS | ٠.٣٨ | ٠.٠٤ | ↓ ٨٩٪ |
| INP | ٢٨٠ مللي | ١٤٠ مللي | ↓ ٥٠٪ |
| درجة الأداء | ٣٢ | ٧٨ | ↑ ٤٦ نقطة |
هذه الأرقام واقعية — ليست مثالية، وهذا مقصود. الوصول من ٧٨ إلى ٩٥ يتطلب جهداً مضاعفاً وعادةً يستلزم إعادة هيكلة أعمق. لكن القفزة من ٣٢ إلى ٧٨ حدثت بتغييرات CSS لا تتجاوز ٥٠ سطراً وقرار بنقل ملفات الخط إلى الخادم.
نقطة مهمة: أرقام Lighthouse في بيئة المختبر (Lab Data) قد تختلف عن بيانات المستخدمين الحقيقيين (Field Data) التي تجدها في Google Search Console. Lab Data أداة تشخيص، Field Data هو ما يراه جوجل فعلاً عند تقييم موقعك. الهدف المثالي هو تحسين كليهما.
قائمة التحقق الكاملة: قبل نشر أي صفحة هبوط عربية
نجمع ما تعلمناه في السلسلة كلها في قائمة تحقق قابلة للاستخدام المباشر:
الخطوط والطبوغرافيا
- ☐ الخطوط العربية مستضافة محلياً بتنسيق WOFF2
- ☐ جميع
@font-faceتحتوي علىfont-display: swap - ☐ يوجد خط احتياطي مُعاير الأبعاد لتقليل الانزياح
- ☐ الخط الرئيسي مُحمَّل بـ
preload - ☐ استخدام Variable Font إذا توفر
- ☐
unicode-rangeمحدد لتجنب تحميل الخط في الصفحات غير العربية
الروابط والبنية
- ☐ الـ slug إنكليزي قصير ودلالي (٣-٥ كلمات)
- ☐ يوجد
canonicalيشير للعنوان الرئيسي - ☐ يوجد
hreflangإذا كانت هناك نسخة بلغة أخرى - ☐ عمق التسلسل الهرمي لا يتجاوز ٣ مستويات
التوطين البصري
- ☐
dir="rtl"على عنصر الجذر أو المحتوى - ☐
lang="ar"على عنصر<html> - ☐ الأيقونات الاتجاهية مقلوبة للعربية
- ☐ الهوامش والحشوات تستخدم الخصائص المنطقية أو مُعكوسة
- ☐ الأرقام بالصيغة المناسبة للجمهور المستهدف
الأداء العام
- ☐ LCP أقل من ٢.٥ ثانية
- ☐ CLS أقل من ٠.١
- ☐ الصور الرئيسية بتنسيق WebP أو AVIF مع أبعاد محددة
- ☐
fetchpriority="high"على صورة LCP - ☐ CSS الحيوي مُضمَّن أو محمَّل بأولوية
- ☐ سكريبتات غير حيوية بـ
deferأوasync
خاتمة السلسلة: الطبوغرافيا ليست زينة
بدأنا هذه السلسلة بسؤال بسيط: لماذا التوطين أعمق من الترجمة؟ ووصلنا إلى إجابة تقنية دقيقة: لأن كل قرار في منظومة الطبوغرافيا الرقمية — من اختيار الخط إلى بنية الرابط إلى اتجاه العنصر — يُترجَم مباشرةً إلى أرقام في تقارير الأداء وفي تصرف الزاحف.
الموقع العربي المُوطَّن بشكل صحيح لا يبدو عربياً فحسب — يُحمَّل بسرعة، يستقر بصرياً، يُعطي جوجل إشارات لغوية واضحة، ويُبقي الزائر على الصفحة بدلاً من دفعه للمغادرة في أول ثلاث ثوانٍ.
ما طبّقناه في هذا المشروع — preload للخطوط، معايرة الخط الاحتياطي، WOFF2 محلي، Critical CSS، أبعاد الصور — ليس تحسيناً تجميلياً. إنه البنية التحتية التي تجعل المحتوى وصول إلى من يستحقه.
السلسلة انتهت. المشروع لا ينتهي أبداً — كل صفحة جديدة هي فرصة لتطبيق ما تعلمناه من البداية.
— الطبوغرافيا الرقمية وتأثيرها على السيو التقني —
المقال السابق: ٣- هندسة الروابط: فك شفرة الرموز المئوية في العناوين العربية
المقال الحالي: ٤- مشروع تطبيقي: إنقاذ صفحة هبوط عربية من الاختناق التقني
سلاسل مشابهة:
دليل هندسة واجهات اليمين | دليل معالجة النصوص الهجينة | دليل معايرة البيانات المالية | ورشة التوطين لتطبيقات الويب ٣.٠
منصة ذي يزن © ٢٠٢٦
سلاسل التوطين
الطبوغرافيا الرقمية وتأثيرها على السيو التقني — ٤ مقالات
سلسلة الطبوغرافيا الرقمية وتأثيرها على السيو التقني — ٤ مقالات | منصة ذي يزن © ٢٠٢٦
