برمجة المواقع والتطبيقات

موقع سريع بلا خادم: لماذا بنينا ميقات كموقع ثابت على Cloudflare Pages

بقلم أحمد قطف · · 3 دقائق قراءة

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

ما هو الموقع الثابت؟

الموقع الديناميكي التقليدي (مثل ووردبريس) يبني الصفحة عند كل زيارة: يستقبل الطلب، ويستعلم من قاعدة البيانات، ويركب القالب، ثم يرسل النتيجة. الموقع الثابت يبني كل الصفحات مسبقاً كملفات HTML جاهزة، ويضعها على شبكة توزيع محتوى ترسلها كما هي. لا قاعدة بيانات تُخترق، ولا خادم يحتاج تحديثات أمنية، ولا تباطؤ عند كثرة الزوار، لأن إرسال ملف جاهز من أقرب نقطة جغرافية للزائر أسرع شيء ممكن على الإنترنت.

لكن المواقيت تتغير يومياً!

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

مولّد الصفحات

كتبنا المولّد بلغة بايثون مع محرك القوالب Jinja2. يقرأ قائمة المدن من قاعدة بيانات جغرافية مفتوحة (geonamescache)، ويختار لكل بلد طريقة الحساب الرسمية، ويحسب المواقيت، ثم يولّد صفحات كل لغة في مجلد منفصل مع خرائط الموقع وملف llms.txt المخصص لمحركات الذكاء الاصطناعي. البناء الكامل للنسخ الثلاث يستغرق أقل من دقيقة على جهاز عادي. وأي تحسين في قالب واحد ينعكس فوراً على كل الصفحات، وهذه ميزة كبيرة على تعديل آلاف الصفحات يدوياً.

لماذا Cloudflare Pages؟

الحدود التي اصطدمنا بها

عدد الملفات في الرفع من المتصفح: الرفع المباشر عبر لوحة التحكم محدود بألف ملف للنشر الواحد. عندما تجاوزت النسخة الإنجليزية هذا الرقم اضطررنا إلى تقليل المدن الصغيرة جداً، مع إعادة توجيه دائمة (301) لروابطها القديمة إلى صفحة الدولة حتى لا تظهر للزوار صفحات خطأ. أداة سطر الأوامر Wrangler تسمح بعدد أكبر بكثير، وهي الطريق الأنسب عندما يكبر المشروع.

حجم التحديثات: Cloudflare يرفع فقط الملفات التي تغيرت (يقارن بصمة كل ملف). لكن تعديلاً بسيطاً في التذييل يغيّر كل الصفحات، فيصبح الرفع ثقيلاً على اتصال إنترنت ضعيف. تعلمنا أن نصمم التحديثات بحيث تمس أقل عدد ممكن من الصفحات، وأن نضع العناصر المشتركة المتغيرة في ملفات CSS وجافاسكربت منفصلة.

التخزين المؤقت والسرعة

نضع أرقام إصدار في روابط ملفات CSS وجافاسكربت (مثل style.css?v=8f3a2c1d) تتغير تلقائياً عند تعديل الملف، ونطلب من المتصفح تخزين هذه الملفات سنة كاملة. هكذا لا يُعاد تحميلها في كل زيارة، ولا يرى أحد نسخة قديمة بعد التحديث. وصفحات HTML نفسها صغيرة، والخط العربي يُحمّل من Google Fonts مع خيار العرض الفوري للنص بخط النظام إلى أن يكتمل تحميل الخط. النتيجة أن الصفحة تظهر في جزء من الثانية حتى على شبكات الجوال البطيئة.

تطبيق يعمل دون إنترنت

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

التكلفة الشهرية الفعلية

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

الأمان مجاناً

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

سير العمل اليومي

عند إضافة مقال جديد أو تحسين صفحة: نعدّل ملف المحتوى، ونشغّل المولّد، ونراجع الصفحات الناتجة محلياً في المتصفح، ثم نرفع الملفات. بعد النشر نبلغ محركات البحث بالروابط الجديدة عبر IndexNow ونطلب الفهرسة في Google Search Console. العملية كلها تستغرق دقائق، ولا تحتاج تسجيل دخول إلى خادم أو تحديث إضافات.

متى لا يناسبك الموقع الثابت؟

إذا كان المحتوى يعتمد على المستخدم (حسابات، سلة شراء، لوحة تحكم)، أو يتغير بقرارات بشرية كل دقيقة، فستحتاج إلى خادم أو خدمات خلفية. لكن حتى في هذه الحالات يمكن الجمع: صفحات المحتوى ثابتة وسريعة، والأجزاء التفاعلية تتصل بواجهات برمجية صغيرة. لمواقع المحتوى والأدلة والأدوات الحسابية يبقى الموقع الثابت في رأينا الخيار الأسرع والأرخص والأكثر أماناً. وللجانب الآخر من الموضوع، أي جعل هذه الصفحات تظهر في محركات البحث بكل اللغات، اقرأ أساسيات SEO للمواقع العربية متعددة اللغات.

اقرأ أيضاً