طراحی وب پایدار؛ سنجش انرژی، کربن و بودجه عملکرد

اگر یک ابزار آنلاین بگوید صفحه اصلی شما «سبز» است، هنوز نمی‌دانید جست‌وجو، Checkout، ویدئو، API، Botها یا پردازش پس‌زمینه چه مصرفی دارند. برعکس، کوچک‌کردن چند تصویر هم لزوماً اثر Hosting، Database، AI و عمر دستگاه کاربر را پوشش نمی‌دهد. طراحی وب پایدار یک نمره تزئینی نیست؛ مدیریت تقاضا، انرژی، کربن و عمر سیستم در یک مرز شفاف است.

پاسخ کوتاه: ابتدا Workflow و Functional unit تعریف کنید؛ Transfer، Request، زمان پردازش Client/Server و داده Provider را Baseline بگیرید؛ سپس Feature و محتوای غیرضروری را حذف، Media/Code/Query/Cache را بهینه و زیرساخت را با Evidence انتخاب کنید. اگر CO₂ را با مدل تخمین می‌زنید، مدل، نسخه، Grid factor و فرض‌هایش را کنار عدد بنویسید. سرعت، Dark mode، CDN یا «هاست سبز» به‌تنهایی اثبات پایداری نیستند.

Snapshot راهنما: این مقاله در ۶ اوت ۲۰۲۶ بازبینی شده است. Web Sustainability Guidelines در این تاریخ W3C Group Note Draft است و خود سند می‌گوید Draft به‌معنای تأیید W3C نیست. از آن به‌عنوان چارچوب در حال تکامل استفاده کنید، نه گواهی یا ادعای Conformance قطعی.

طراحی وب پایدار چیست؟

طراحی وب پایدار یعنی محصول دیجیتال در طول عمر خود با منابع کمتر، ارزش لازم را برای کاربران واقعی ایجاد کند و اثر منفی را بدون انتقال پنهان به گروه یا لایه دیگر کاهش دهد. «پایدار» فقط محیط‌زیست نیست؛ WSG ابعاد Planet، People و Prosperity را کنار هم می‌گذارد.

یک صفحه فوق‌سبک که کاربر را مجبور می‌کند چند بار تلاش کند یا برای کار ضروری تماس بگیرد، لزوماً پایدار نیست. Task success، امنیت، دسترس‌پذیری و تاب‌آوری Gate هستند.

مرز سیستم را قبل از عدد مشخص کنید

ردپای یک وب‌سایت می‌تواند چند بخش داشته باشد:

برای همه سازمان‌ها اندازه‌گیری کامل ممکن نیست. مهم این است که Scope، حذف‌ها و عدم‌قطعیت را صریح کنید و عدد یک صفحه را «ردپای کل کسب‌وکار» ننامید.

Functional unit؛ به ازای چه چیزی؟

«CO₂ هر Page view» می‌تواند مفید باشد، اما ارزش محصول را نمی‌سنجد. Functional unit را به Outcome نزدیک کنید:

• به‌ازای یک مقاله خوانده‌شده تا ۷۵٪؛
• به‌ازای جست‌وجوی موفق محصول؛
• به‌ازای سفارش تکمیل‌شده؛
• به‌ازای Ticket پشتیبانی حل‌شده؛
• به‌ازای ۱٬۰۰۰ کاربر فعال ماهانه؛
• به‌ازای Build یا Inference موفق.

اگر کاهش Bytes باعث افزایش خطا و تکرار Journey شود، Metric به‌ازای Page view ممکن است بهبود کاذب نشان دهد.

اندازه‌گیری، تخصیص و تخمین را یکی نگیرید

هرچه از Meter دور می‌شوید، Label و Uncertainty مهم‌تر می‌شود. Proxy فنی خوب می‌تواند تصمیم را هدایت کند، اما نباید با «گرم CO₂ اندازه‌گیری‌شده» اشتباه شود.

مدل SCI چه چیزی یاد می‌دهد؟

Software Carbon Intensity Specification شدت کربن نرم‌افزار را با مؤلفه‌های انرژی، شدت کربن برق، انتشار نهفته سخت‌افزار و Functional unit مدل می‌کند:

SCI = ((E × I) + M) per R

E = انرژی مصرف‌شده
I = شدت کربن منطقه/زمان
M = سهم انتشار نهفته سخت‌افزار
R = واحد عملکردی

هدف عملی فرمول این است که فقط Total growth را نبینید؛ شدت به‌ازای Outcome را کاهش دهید. در عین حال، بهبود Intensity با رشد تقاضا ممکن است Total emissions را همچنان بالا ببرد. هر دو را گزارش کنید.

ماشین‌حساب کربن وب چه محدودیتی دارد؟

ابزارهایی مانند CO2.js انتقال داده و فرض‌های عمومی را به تخمین تبدیل می‌کنند. Green Web Foundation اعلام کرده CO2.js از Sustainable Web Design Model v4 استفاده می‌کند. تغییر نسخه مدل می‌تواند نتیجه را به‌طور معنادار تغییر دهد؛ بنابراین:

• نام Model، Version، تاریخ، URL و نوع Visit را ثبت کنید؛
• Cache گرم/سرد، Returning/New visitor و Device را تفکیک کنید؛
• نتیجه را «تخمین مدل» بنامید؛
• از مقایسه عددهای تولیدشده با دو مدل متفاوت خودداری کنید؛
• Homepage را نماینده کل Product ندانید؛
• عدم‌قطعیت Grid، Network، Device و Embodied را توضیح دهید.

بهتر است ابتدا Proxyهای قابل‌کنترل مانند Bytes، request، CPU و cache hit را در CI/RUM پایدار کنید و سپس Model carbon را روی همان Dataset اجرا کنید.

Baseline را بر Route و Journey بسازید

برای هر Journey تعداد Step، نرخ موفقیت، تکرار، Transfer، Server time و Third party را ثبت کنید. مشکل ممکن است «صفحه سنگین» نباشد؛ Search ضعیف کاربر را مجبور به بازدید ده صفحه می‌کند.

بزرگ‌ترین صرفه‌جویی: تقاضای غیرضروری را نسازید

بهینه‌کردن Feature بی‌ارزش، Waste را کارآمد می‌کند؛ حذف آن اثر بیشتری دارد. در Discovery بپرسید:

• این Feature کدام نیاز کاربر یا Outcome را حل می‌کند؟
• چند درصد کاربر آن را استفاده و با موفقیت تمام می‌کنند؟
• آیا راه ساده‌تر یا Async وجود دارد؟
• داده/AI real-time واقعاً لازم است یا Batch/Cache کافی است؟
• آیا Notification، Autoplay، Infinite scroll یا Personalization ارزش اثبات‌شده دارد؟
• هزینه نگهداری و پایان عمر چیست؟

حذف Carousel بی‌استفاده، Tracker تکراری یا Report روزانه‌ای که هیچ‌کس نمی‌خواند اغلب از Minify کردن همان‌ها مؤثرتر است.

محتوا و Information architecture

محتوای تکراری و Navigation مبهم هم Transfer را زیاد می‌کند و هم زمان کاربر را می‌گیرد.

• Intent و Owner هر صفحه مشخص باشد؛
• صفحه‌های هم‌پوشان Merge و Redirect شوند؛
• Content lifecycle شامل Review، Archive و Delete باشد؛
• عنوان، Summary و Anchor کاربر را سریع به پاسخ برسانند؛
• Search داخلی با فارسی، نیم‌فاصله و مترادف تست شود؛
• دانلود PDF فقط وقتی ارزش مستقل دارد؛ HTML قابل‌دسترس جایگزین باشد؛
• محتوای تولیدی AI بدون تقاضا و Governance انبوه نشود.

تصویر؛ نه فقط فرمت مدرن

AVIF/WebP در بسیاری سناریوها مفیدند، اما Quality، Decode cost، Alpha، عکس/Illustration و پشتیبانی Pipeline را تست کنید. «حجم کمتر» تنها Gate نیست؛ تصویر باید معنا و Accessibility خود را حفظ کند.

ویدئو و صدا

• Autoplay با صدا نداشته باشید و Autoplay خاموش را Default ارزیابی کنید؛
• Poster سبک و Play آگاهانه ارائه دهید؛
• Adaptive bitrate و Resolution متناسب با Viewport/Network؛
• Transcript و Caption برای دسترسی و انتخاب کم‌مصرف؛
• Preload را محدود و Embed ثالث را پس از Consent/Interaction Load کنید؛
• ویدئوی قدیمی و Variant بی‌استفاده را از Storage/CDN پاک کنید؛
• Watch completion را بسنجید؛ محتوای ترک‌شده کاندید بازطراحی است.

فونت فارسی

فونت System می‌تواند Download را حذف کند، اما هویت و خوانایی فارسی نیز مهم است. تصمیم صفر و یک نیست:

• یک Family و Weightهای واقعاً استفاده‌شده؛
• WOFF2 و Subset فارسی/لاتین بر اساس نیاز؛
• Self-host برای کنترل Cache و دسترسی؛
• font-display مناسب و Fallback با Metric نزدیک؛
• Preload فقط Font بحرانی؛
• حذف Icon font و استفاده از SVG محدود؛
• بررسی License و Update.

Subset تهاجمی ممکن است اعداد، علائم یا حروف زبان دیگر را حذف کند. Corpus واقعی محتوا و فرم را Test کنید.

JavaScript؛ Bytes، CPU و عمر دستگاه

یک فایل فشرده کوچک ممکن است Parse/Execute سنگینی داشته باشد. هزینه Client فقط Network نیست.

• JavaScript را فقط برای Interaction لازم ارسال کنید؛
• Server-render/HTML را برای محتوای ساده ارزیابی کنید؛
• Code split بر Route/Feature، نه Chunkهای ریز بی‌قاعده؛
• Dependency graph، نسخه تکراری و Polyfill غیرضروری را ممیزی کنید؛
• Hydration و re-render را با Profiler بسنجید؛
• Long task، INP، Memory و Crash دستگاه میان‌رده را Guardrail کنید؛
• Worker و Animation را هنگام Hidden/Idle متوقف کنید؛
• Fallback بدون JS برای عمل‌های حیاتی در صورت امکان.

سایت سنگین می‌تواند باتری را مصرف و کاربر را به تعویض زودتر Device سوق دهد؛ رابطه دقیق نیازمند پژوهش است، اما Compatibility با دستگاه قدیمی‌تر یک راهبرد هم‌زمان برای عدالت دسترسی و طول عمر سخت‌افزار است.

Third partyها را خارج از Budget نگذارید

هر Script باید Owner، Purpose، Expiry، Data flow و Budget داشته باشد. Tagهای بدون Owner را به‌مرور حذف کنید.

Server، API و Database

• Query count/time و N+۱ را روی Flow واقعی اندازه بگیرید؛
• Index و Data model را با Write/Storage trade-off بهینه کنید؛
• Response field و Pagination را حداقلی کنید؛
• Cache نتیجه با Freshness و Invalidation درست؛
• Batch/Queue برای کار غیرهم‌زمان؛
• Timeout، Retry محدود و جلوگیری از Retry storm؛
• Autoscaling با Scale-to-zero فقط اگر Latency/SLO اجازه می‌دهد؛
• Log، Trace و Metric با Sampling/Retention متناسب؛
• داده قدیمی را طبق Retention و نیاز حقوقی حذف/Archive کنید.

ذخیره بی‌پایان Event، Log و Backup هم هزینه و هم ریسک Privacy می‌سازد. Retention باید Purpose، Restore و Incident را متعادل کند.

Cache؛ کاهش پردازش یا تکثیر بی‌هدف؟

Cache می‌تواند Compute و Transfer تکراری را کم کند، اما Key اشتباه، TTL بیش‌ازحد و Purge سراسری Waste و داده کهنه می‌سازد.

• Cache key فقط Dimensionهای واقعاً متفاوت؛
• TTL بر Freshness و Update frequency؛
• Revalidation و Stale policy آگاهانه؛
• عدم Cache محتوای شخصی در Shared layer؛
• Purge هدفمند به‌جای پاک‌سازی کل سایت؛
• Cache hit ratio کنار Correctness و Staleness؛
• جلوگیری از Stampede هنگام انقضا.

مبانی Layer، TTL و Invalidation در راهنمای معماری Cache آمده است.

CDN همیشه کم‌کربن‌تر نیست

CDN می‌تواند فاصله، Origin load و تکرار Transfer را کم کند؛ اما PoP بیشتر، Replication، Cache miss و Purge نیز هزینه دارند. نزدیک‌ترین Network path الزاماً کم‌کربن‌ترین Grid یا کم‌مصرف‌ترین مسیر نیست.

انتخاب و PoC برای کاربران ایرانی در راهنمای CDN توضیح داده شده است.

Protocol و Compression

Brotli/Gzip، HTTP/۲ یا HTTP/۳ می‌توانند Transfer/Latency را بهتر کنند، اما هرکدام CPU، Compatibility و Operational cost دارند. فایل از قبل فشرده را دوباره فشرده نکنید و Compression level بسیار سنگین را بدون Benchmark انتخاب نکنید.

برای QUIC، ۰-RTT، UDP و Fallback به راهنمای HTTP/۳ رجوع کنید. Sustainability از Outcome اندازه‌گیری‌شده می‌آید، نه صرف فعال‌کردن Protocol جدید.

انتخاب Hosting با Evidence

عبارت «۱۰۰٪ Renewable» می‌تواند به برق فیزیکی هم‌زمان، قرارداد سالانه، گواهی انرژی یا Offset اشاره کند. این‌ها معادل نیستند. پرسش‌های Due diligence:

• Data center و Region واقعی Workload کجاست؟
• مصرف برق و Carbon factor با چه Method و Scope گزارش می‌شود؟
• Location-based و Market-based هر دو ارائه می‌شوند؟
• Renewable procurement از چه نوع، دوره و منطقه‌ای است؟
• PUE/WUE و Utilization در Scope سرویس چیست؟
• Embodied hardware و عمر/بازیافت چگونه تخصیص می‌یابد؟
• Multi-tenant allocation بر چه مبناست؟
• گزارش مستقل و تاریخ‌دار وجود دارد؟
• SLA، Residency، Security و Exit plan چه وضعی دارند؟

Green Web Foundation برای فهرست‌کردن Providerها Evidence مشخصی برای Green power درخواست می‌کند و معیارهایش نیز ممکن است تغییر کند. Directory را نقطه شروع Due diligence بدانید، نه اثبات کامل اثر Workload خود.

شدت کربن برق و زمان/مکان پردازش

اگر Workload انعطاف‌پذیر و داده معتبر دارید، Job غیرضروری Real-time را می‌توان به زمان یا منطقه با Carbon intensity پایین‌تر منتقل کرد. اما:

• Data residency، Privacy و قانون اولویت دارند؛
• انتقال بین Region خود Data/Replication می‌سازد؛
• Latency و Availability نباید Task حیاتی را خراب کند؛
• Carbon data باید زمان/مکان و Method روشن داشته باشد؛
• Location-based reduction با خرید Offset یکی نیست؛
• کاربر ایرانی نباید برای Claim سبز مسیر کندتر یا ناپایدار بگیرد.

Data center؛ عددهای اغراق‌آمیز را کنار بگذاریم

تشبیه «اینترنت اگر کشور بود…» معمولاً Scope، سال و Method نامعلوم دارد. گزارش IEA درباره تقاضای انرژی Data center مصرف برق مراکز داده در ۲۰۲۴ را حدود ۱٫۵٪ برق جهانی برآورد می‌کند و تفاوت زیاد میان نوع مرکز و اجزای آن را نشان می‌دهد. این عدد مربوط به کل Data center است، نه صفحه شما؛ برای ترساندن کاربر یا نسبت‌دادن مستقیم به هر Click مناسب نیست.

Dark mode؛ انتخاب کاربر، نه ادعای نجات

نمایش Pixel تیره در بعضی OLEDها می‌تواند مصرف Display را کم کند، اما اثر به Device، Brightness، محتوا و زمان استفاده بستگی دارد. LCD رفتار دیگری دارد و Dark palette نامناسب Accessibility را خراب می‌کند.

• ترجیح System را رعایت و Toggle پایدار بدهید؛
• Contrast را در هر دو Theme تست کنید؛
• Dark mode را با کاهش Bytes/CPU اشتباه نگیرید؛
• عدد صرفه‌جویی عمومی بدون Device lab منتشر نکنید؛
• اجبار Dark mode را راهکار Sustainability ندانید.

Accessibility، Low bandwidth و دوام دستگاه

سایت سبک‌تر اغلب روی شبکه و سخت‌افزار ضعیف بهتر است، اما Minification یا حذف محتوا نباید Semantics و Alternativeها را بشکند.

• HTML Semantic و Progressive enhancement؛
• Keyboard، Focus، Contrast و Reduced motion؛
• Caption/Transcript و متن جایگزین Media؛
• فرم کوتاه، Save draft و جلوگیری از ارسال تکراری؛
• Offline/Retry آگاهانه برای شبکه ناپایدار؛
• Fallback برای API/JS و Error page راهنما؛
• پشتیبانی از Browser/Device قدیمی بر اساس کاربران واقعی؛
• عدم اجبار Update سخت‌افزار برای Feature غیرضروری.

راهنمای جامع UX Sustainability را با Task success و Accessibility متعادل می‌کند.

PWA و Offline؛ Cache بی‌حد پایدار نیست

Service Worker می‌تواند تکرار Download و دسترسی در اختلال را بهتر کند، اما Precache بزرگ، Sync دائم و نسخه قدیمی هزینه می‌سازد. Strategy را بر نوع داده، Frequency و نیاز Offline انتخاب کنید؛ Update/eviction/rollback را Test کنید. جزئیات در راهنمای PWA، Render و Cache آمده است.

AI و قابلیت‌های محاسباتی سنگین

افزودن Chatbot، Generation یا Recommendation فقط به دلیل Trend با Sustainability سازگار نیست. پیش از AI:

• نیاز و Baseline روش ساده را تعریف کنید؛
• Model/Context/Output را به حد لازم محدود کنید؛
• Cache، Batch و Retrieval را ارزیابی کنید؛
• Fallback و Human escalation داشته باشید؛
• Quality، Harm، Cost و Energy proxy را Guardrail کنید؛
• استفاده Spam/Bot را Rate limit کنید؛
• Feature بی‌اثر را Kill کنید.

IEA نشان می‌دهد Data center و AI تقاضای رو‌به‌رشد دارند، اما عدد انرژی هر Task به Model، Hardware، Region و Utilization وابسته است؛ ادعای عمومی بدون داده Provider قابل‌اتکا نیست.

Performance budget به‌عنوان کنترل اجرایی

عددها را از Baseline و نیاز خود تعیین کنید؛ Budget نمونه در مقاله نسخه همگانی نیست. CI باید Regression را Flag کند و Exception، Owner و تاریخ انقضا داشته باشد.

Dashboard و Telemetry

• p75 LCP/INP/CLS و Task success؛
• Transfer/Request/CPU بر Route و Device؛
• Server CPU/memory/query و autoscale؛
• CDN cache hit/origin offload/egress؛
• Storage growth، Backup size و Retention؛
• Third-party bytes/time و Consent rate؛
• Functional unit volume و Total activity؛
• Energy/Carbon measured، allocated یا estimated با Label؛
• Release annotation و Regression alert.

High-cardinality Telemetry خودش هزینه می‌سازد. Sampling و Retention را با Incident/Privacy متعادل کنید؛ راهنمای Observability برای این طراحی کاربرد دارد.

سنجش پیش و پس از تغییر

1. Scope، Route cohort، Device، Cache state و Functional unit را ثابت کنید.
2. Baseline را در Lab و Field ثبت کنید.
3. فقط یک دسته تغییر یا Release قابل‌ردیابی اجرا کنید.
4. Performance، Task success، Error و Resource proxy را بسنجید.
5. Carbon model را با همان Version دوباره اجرا کنید.
6. Jevons/rebound را ببینید: آیا مصرف یا Traffic بیشتر شد؟
7. نتیجه، Uncertainty و Trade-off را ثبت کنید.

مثلاً کاهش ۴۰٪ Bytes صفحه محصول خوب است؛ اما اگر Infinite scroll باعث دو برابر‌شدن Page consumption شود، Total transfer ممکن است افزایش یابد.

ادعای پایداری و Greenwashing

• از Absolute claim بدون Scope پرهیز کنید؛
• Reduction واقعی را پیش از Offset گزارش کنید؛
• سال و Data source را کنار Claim بگذارید؛
• تعارض منافع Tool/Vendor را افشا کنید؛
• Trade-off Accessibility، Privacy و Reliability را پنهان نکنید؛
• Claim را با تغییر Provider/Model بازبینی کنید.

ملاحظات ایران

داده Carbon intensity محدود

ممکن است Grid factor زمانی/منطقه‌ای دقیق یا داده Provider داخلی در دسترس نباشد. به‌جای ساختن عدد ظاهراً دقیق، Proxyهای قابل‌اندازه‌گیری و Relative improvement را گزارش کنید و Carbon estimate را با Range/فرض نشان دهید.

مسیر داخل/خارج و تاب‌آوری

Region کم‌کربن روی کاغذ اگر برای کاربر ایرانی Timeout، Retry یا VPN اضافه بسازد ممکن است Outcome بدتری دهد. Latency، Availability، Data residency، Support و Carbon را با Scorecard بسنجید.

موبایل و شبکه

بودجه را با موبایل میان‌رده، Data محدود و چند ISP/VPN تست کنید. فونت فارسی، تصویر و Script ثالث اغلب فرصت‌های ملموس‌تری از تغییر رنگ UI دارند.

Hosting claim

از Provider داخلی/خارجی درباره محل Data center، PUE/WUE، نوع انرژی، روش تخصیص و گزارش تاریخ‌دار سؤال کنید. نبود پاسخ را به‌عنوان Unknown در Scorecard ثبت کنید؛ «سبز» را از صفحه Marketing کپی نکنید.

کسب‌وکار و استمرار

حذف Backup، Redundancy یا Security برای کاهش Storage پایدار نیست. Retention و Replica را بر RPO/RTO و ریسک تعیین کنید. Sustainability باید سرویس قابل‌اعتماد بسازد، نه شکننده.

Scorecard اولویت اقدام

اولویت معمولاً با اقدام پرتکرار، پرمصرف، قابل‌اندازه‌گیری و کم‌ریسک است؛ نه پروژه‌ای که فقط Claim رسانه‌ای جذاب دارد.

برنامه ۹۰روزه

روز ۱ تا ۱۵: Scope و Baseline

• Functional unit و پنج Journey اصلی؛
• Transfer/CPU/Request/Server/Third-party baseline؛
• Data source و Carbon model version؛
• Inventory Hosting/CDN/Storage/AI؛
• Claimهای موجود و Risk سبزشویی.

روز ۱۶ تا ۴۵: Quick win با Gate

• حذف Feature/Script/Content بی‌استفاده؛
• تصویر، ویدئو، فونت و Cache؛
• Query/API و Log retention؛
• Budget در CI و RUM؛
• Accessibility و Task success guardrail.

روز ۴۶ تا ۷۵: زیرساخت و تأمین‌کننده

• Hosting/CDN evidence و Region PoC؛
• Storage/Backup lifecycle؛
• Carbon/energy allocation در قرارداد؛
• Exit plan و Supplier standard؛
• Experiment زمان/مکان برای Workload انعطاف‌پذیر.

روز ۷۶ تا ۹۰: گزارش و چرخه بهبود

• قبل/بعد با Scope و Uncertainty؛
• Total و Intensity کنار هم؛
• Trade-off و Regression؛
• Backlog، Owner و Review فصلی؛
• Claim عمومی قابل‌راستی‌آزمایی.

اشتباه‌های رایج

• نمره Homepage را ردپای کل می‌نامند: Journey، Server و Third party جا می‌ماند.
• Bytes را مستقیماً CO₂ می‌دانند: تبدیل نیازمند Model و فرض است.
• Performance را مساوی Sustainability می‌دانند: Embodied، Grid، Task و Growth نادیده می‌ماند.
• Dark mode را نسخه عمومی می‌دانند: Device و Accessibility متفاوت است.
• CDN را همیشه سبزتر می‌دانند: Cache، Replication، Route و Grid مهم‌اند.
• Offset را جای Reduction می‌گذارند: اثر عملی Workload پنهان می‌شود.
• Security/Backup را حذف می‌کنند: Incident و Rework اثر بزرگ‌تری می‌سازد.
• فقط Intensity را نشان می‌دهند: Total با رشد Usage ممکن است بالا برود.

سوالات متداول طراحی وب پایدار

طراحی وب پایدار یعنی فقط سبک‌کردن سایت؟

خیر. سبک‌کردن Media و Code مهم است، اما Scope شامل Server، Network، Device، Third party، Hosting، داده، عمر سخت‌افزار، Accessibility و ارزش واقعی Journey نیز می‌شود.

آیا می‌توان CO₂ یک صفحه وب را دقیق اندازه گرفت؟

معمولاً ابزار عمومی آن را تخمین می‌زند، نه مستقیم اندازه‌گیری. باید Model/version، Cache state، Grid و فرض Device/Network را ثبت و نتیجه را با برچسب Estimate گزارش کنید.

آیا سایت سریع‌تر همیشه کربن کمتری دارد؟

نه لزوماً. Performance اغلب Co-benefit دارد، اما Prefetch، Server overprovisioning یا مسیر کم‌تاخیر با برق پرکربن می‌تواند Trade-off بسازد. Energy/Resource و Outcome را جدا بسنجید.

آیا Dark mode مصرف انرژی را کاهش می‌دهد؟

روی بعضی نمایشگرهای OLED و شرایط مشخص ممکن است، اما اثر به Device، Brightness و محتوا وابسته است. Dark mode را ترجیح کاربر با Contrast درست ارائه و عدد عمومی بدون Device lab اعلام نکنید.

از کدام اقدام شروع کنیم؟

پنج Journey پرترافیک را Baseline بگیرید و Feature/Third-party/Media بی‌استفاده را حذف کنید. سپس تصویر، فونت، JS، Query و Cache را با Budget و Task-success guardrail اصلاح کنید.

جمع‌بندی

وب پایدار با صداقت اندازه‌گیری آغاز می‌شود: Scope، Functional unit و عدم‌قطعیت را روشن کنید؛ تقاضای بی‌ارزش را حذف و Resource را در Client، Network و Server کاهش دهید؛ سپس Hosting و Carbon را با Evidence بسنجید. پایداری یک Release نیست، Budget و چرخه تصمیم محصول است. برای Baseline، معماری بهینه و برنامه کاهش قابل‌راستی‌آزمایی، درخواست مشاوره عملکرد و پایداری وب را ثبت کنید.