تستهلك مراكز البيانات وشبكات نقل البيانات قرابة ١.٥–٢٪ من الكهرباء العالمية وفقاً لوكالة الطاقة الدولية — ومن المتوقع أن تتضاعف هذه الحصة بحلول ٢٠٣٠. كل طلب HTTP، كل صورة غير مضغوطة، كل حزمة JavaScript تُعيد عرض فقرة ثابتة تُساهم في هذا الرقم. معظم المطورين لا يفكرون في هذا. مع يوم الأرض هذا الأسبوع، يستحق الأمر أن نسأل: ما التكلفة الحقيقية لموقعك على الكوكب؟

أمضينا السنة الماضية في بناء موقع الشيخ ميديا ومواقع منتجاتنا على بنية تقنية تُعطي الأولوية للأداء والحد الأدنى من استهلاك الموارد. لم نبدأ بهدف أن نكون “خُضر” — بدأنا بهدف أن نكون سريعين. لكن اتضح أن الموقع الأسرع هو أيضًا الأخف، والموقع الأخف هو أيضًا الأكثر استدامة.

التكلفة الكربونية لصفحة الويب

متوسط حجم صفحة الويب في ٢٠٢٦ حوالي ٢.٥ ميغابايت. يبدو رقمًا صغيرًا حتى تضربه بمليارات التحميلات يوميًا. يتتبع HTTP Archive هذا الرقم، وخط الاتجاه ذهب في اتجاه واحد منذ عشرين سنة: للأعلى.

معظم هذا الوزن يأتي من ثلاثة مصادر:

١. JavaScript. الصفحة الوسطية تشحن أكثر من ٥٠٠ كيلوبايت من JavaScript المضغوط. كثير منه عبء إطار العمل الذي لا يتفاعل معه المستخدم أبدًا — منطق الإماهة (hydration)، إدارة الحالة لمحتوى ثابت، حزم التحليلات التي تنطلق مع كل حدث تمرير.

٢. الصور. ملفات PNG وJPEG غير المُحسّنة لا تزال تمثل نصف الوزن الإجمالي تقريبًا. كثير من المواقع تُرسل صورًا بدقة سطح المكتب إلى الهواتف. قليل منها يستخدم صيغًا حديثة مثل AVIF أو WebP مع خاصية srcset المناسبة.

٣. السكربتات الخارجية. أدوات الدردشة، التحليلات، أدوات اختبار A/B، لافتات موافقة ملفات تعريف الارتباط، التضمينات الاجتماعية. كل واحدة تضيف استعلامات DNS واتصالات TCP وتنفيذ JavaScript. موقع تسويقي نموذجي يحمّل ١٥–٣٠ سكربت خارجي.

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

البنية الثابتة أولًا

أهم قرار اتخذناه كان اختيار Astro كإطار عمل — نفس الذي يُشغّل تطبيقاتنا ثنائية اللغة. ليس لأنه رائج — بل لأنه لا يشحن أي JavaScript افتراضيًا.

هذه الجملة تستحق التكرار. عندما تبني صفحة في Astro، المخرج هو HTML وCSS خالصان. لا وقت تشغيل. لا إماهة. لا حزمة إطار عمل. إذا لم تحتج الصفحة تفاعلية، فلا تدفع تكلفة التفاعلية.

---
// هذا المكوّن يُحوّل إلى HTML خالص وقت البناء
// لا JavaScript يصل إلى المتصفح
const posts = await getCollection('blog');
---
<ul>
  {posts.map(post => (
    <li><a href={post.slug}>{post.data.title}</a></li>
  ))}
</ul>

عندما يحتاج مكوّن فعلًا إلى تفاعلية — قائمة الهاتف، مُبدّل اللغة — بنية الجزر في Astro تُحمّل JavaScript لذلك المكوّن فقط، وفقط عند الحاجة. باقي الصفحة يبقى ثابتًا.

قارن هذا بإعداد Next.js أو Nuxt النموذجي حيث تُماه الصفحة بالكامل عند التحميل، شاحنةً شجرة المكوّنات كاملة كـ JavaScript حتى عندما يكون كل عنصر ثابتًا. الفرق ليس هامشيًا. في صفحات مدونتنا، نشحن أقل من ١٥ كيلوبايت من إجمالي JavaScript. مدونة مبنية بـ React مماثلة ستشحن ٨٠–١٥٠ كيلوبايت من كود الإطار قبل سطر واحد من منطق التطبيق.

التوصيل الحافي يلغي الرحلات الطويلة

ننشر على Cloudflare Pages، مما يعني أن HTML الثابت مُخبّأ في أكثر من ٣٠٠ موقع حافي حول العالم. مستخدم في دبي لا ينتظر رحلة ذهاب وإياب إلى خادم في فرجينيا. الصفحة تُقدّم من أقرب عقدة حافية، غالبًا في أقل من ٥٠ مللي ثانية.

هذا مهم للاستدامة لأن وقت استجابة الشبكة ليس فقط عن تجربة المستخدم — إنه عن المدة التي تبقى فيها البنية التحتية للشبكة نشطة لكل طلب. استجابة ٢٠٠ مللي ثانية تُبقي الموجّهات والمبدّلات ومعدات الراديو مشغولة أربع مرات أطول من استجابة ٥٠ مللي ثانية. على النطاق الواسع، هذا يتراكم.

التوصيل الحافي يعني أيضًا أننا لا نُشغّل خوادم أصل لمعظم الطلبات. لا عملية Node.js تعمل دائمًا. لا حاوية خاملة في الثالثة فجرًا تنتظر حركة مرور. الذاكرة المؤقتة الحافية تتعامل معها، والعقد الحافية تخدم آلاف المواقع في وقت واحد، موزّعةً تكلفة الطاقة عليها جميعًا.

تحسين الصور كسياسة بيئية

الصور هي المكسب الأسهل والأكثر إهمالًا. نهجنا:

التحسين وقت البناء. كل صورة تُعالج وقت البناء إلى صيغ متعددة (WebP، AVIF) وأحجام متعددة. المتصفح يختار أصغر صيغة يدعمها بالدقة التي يحتاجها العرض فعلًا.

<picture>
  <source srcset="/images/hero-400.avif 400w, /images/hero-800.avif 800w"
          type="image/avif" />
  <source srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w"
          type="image/webp" />
  <img src="/images/hero-800.jpg" alt="..." loading="lazy"
       width="800" height="450" />
</picture>

التحميل الكسول لكل شيء أسفل الطية. خاصية loading="lazy" هي أداء مجاني. الصور التي لم يصل إليها المستخدم بالتمرير لا تستهلك عرض النطاق. هذا وحده يمكن أن يقلل وزن الصفحة بنسبة ٤٠–٦٠٪ في الصفحات الغنية بالصور.

لا فيديوهات بطل في صفحات الهبوط. فيديوهات الخلفية التلقائية جميلة ومكلفة. فيديو بطل مدته ١٠ ثوانٍ بدقة 1080p يزن ٥–١٥ ميغابايت — أكثر من بقية الصفحة مجتمعة. نستخدم صورًا ثابتة مع حركات CSS للاهتمام البصري. فرق الطاقة كبير.

CSS بدلًا من JavaScript

نمط تبنّيناه: إذا أمكنك فعله بـ CSS، لا تفعله بـ JavaScript. حركات CSS تعمل على خيط المُركّب وهي مُسرّعة بالـ GPU. حركات JavaScript تعمل على الخيط الرئيسي وتحجب العرض.

سلوك إخفاء شريط التنقل عند التمرير لدينا يستخدم position: sticky مع انتقالات CSS ومستمع تمرير بسيط — ليس تحديث حالة React يُعيد عرض الرأس مع كل حدث تمرير. مُبدّل الوضع الداكن هو تبديل خاصية CSS مخصصة، ليس مزوّد سياق يُعيد عرض شجرة المكوّنات بالكامل.

/* تبديل السمة بدون أي إعادة عرض JavaScript */
:root {
  --bg: #ffffff;
  --text: #1a1a1a;
}

[data-theme="dark"] {
  --bg: #0a0a0a;
  --text: #e5e5e5;
}

body {
  background: var(--bg);
  color: var(--text);
  transition: background 200ms ease, color 200ms ease;
}

كل تحديث DOM يُتجنّب هو دورات CPU تُوفّر. كل دورة CPU تُوفّر هي طاقة تُوفّر. الحساب بسيط حتى لو كانت الأرقام صغيرة لكل صفحة — إنها تتراكم عبر ملايين مرات المشاهدة.

قياس البصمة الكربونية لموقعك

توجد عدة أدوات لتقدير الأثر البيئي لصفحة الويب:

  • Website Carbon Calculator يُقدّر CO₂ لكل مشاهدة صفحة بناءً على نقل البيانات. صفحتنا الرئيسية تحقق نتيجة ضمن أفضل ١٠٪ من الصفحات المُختبرة.
  • نتيجة أداء Lighthouse هي مؤشر معقول. نتيجة فوق ٩٥ تعني عمومًا هدرًا أدنى — حزم صغيرة، أصول مُحسّنة، عرض سريع.
  • Core Web Vitals تتوافق تمامًا تقريبًا مع الاستدامة. LCP منخفض يعني بيانات أقل مُنقلة. CLS منخفض يعني إعادات عرض أقل. INP منخفض يعني عمل CPU أقل.

التوافق ليس صدفة. ما هو جيد للمستخدم هو جيد للكوكب. مقاييس أداء Google هي، بشكل غير مقصود، مقاييس بيئية.

الحالة التجارية

الاستدامة ليست فقط أخلاقيات — إنها اقتصاديات هندسية.

تكاليف الاستضافة تتناسب مع الحوسبة وعرض النطاق. موقع ثابت على CDN حافي يكلف جزءًا بسيطًا من تطبيق يُعرض من الخادم. نحن لا ندفع شيئًا فعليًا لاستضافة هذا الموقع. موقع ديناميكي مكافئ مع عرض من جانب الخادم سيكلف ٢٠–٥٠ دولارًا شهريًا ويتطلب مراقبة وتوسيعًا وصيانة.

الأداء يُحوّل. كل ١٠٠ مللي ثانية تحسين في وقت التحميل تزيد معدلات التحويل. قاست أمازون انخفاضًا بنسبة ١٪ في الإيرادات لكل ١٠٠ مللي ثانية إضافية من التأخير. المواقع الأسرع تفوز في ترتيب البحث وتفاعل المستخدمين معًا.

طول العمر. ملف HTML ثابت من ٢٠٠٥ لا يزال يعمل بشكل مثالي اليوم. تطبيق React من ٢٠٢٠ غالبًا لن يُبنى بدون تحديثات تبعيات كبيرة. البنية الأبسط تدوم أطول، مما يعني إعادة بناء أقل، إعادة نشر أقل، وطاقة تراكمية أقل مُستهلكة على مدار عمر المشروع.

ما يمكنك فعله هذا الأسبوع

لست بحاجة لإعادة كتابة بنيتك التقنية. ابدأ بالتغييرات الأعلى تأثيرًا:

١. شغّل موقعك عبر WebPageTest. انظر إلى الحجم الإجمالي المُنقل. إذا تجاوز ١ ميغابايت، لديك مكاسب سهلة متاحة.

٢. دقّق في السكربتات الخارجية. احذف أي شيء لا تستخدمه فعليًا. أداة التحليلات التي ثبّتها قبل ستة أشهر ولم تتحقق منها أبدًا؟ إنها تُحمّل في كل مشاهدة صفحة لكل زائر.

٣. حوّل الصور إلى WebP أو AVIF. أمر واحد مع sharp أو squoosh يمكن أن يقلل أحجام الصور بنسبة ٥٠–٧٠٪ بدون خسارة جودة مرئية.

٤. أضف loading="lazy" للصور أسفل الطية. خمس دقائق عمل، توفير فوري في عرض النطاق.

٥. اسأل نفسك عن اختيار إطار العمل لمشروعك القادم. إذا كانت الصفحة محتوى في الغالب، هل تحتاج وقت تشغيل على جانب العميل؟ Astro وEleventy وHugo جميعها تُنتج مخرجات ثابتة بدون أو بأقل JavaScript. الأداة الصحيحة لمواقع المحتوى هي التي تشحن أقل كود.

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

ابنِ بسرعة. اشحن بخفة. الكوكب واحد من مستخدميك أيضًا.