पिछले साल एक सोमवार की सुबह एक क्लायंट ने मुझे फोन किया। मैसेज नहीं। फोन कॉल। यह कभी अच्छा नहीं होता। उसने पिछले गुरुवार को Vercel के Pro प्लान पर एक Next.js मार्केटिंग साइट डिप्लॉय की थी, सप्ताहांत पर एक प्रोडक्ट लॉन्च किया, और जागकर अपने इनबॉक्स में $340 का इनवॉइस देखा। साइट शानदार रही थी। ट्रैफिक स्पाइक हुई। और Vercel ने चुपचाप उनके नेटवर्क से निकलने वाले हर गीगाबाइट डेटा को मापा। उसके पास कोई स्पेंडिंग कैप सेट नहीं था। कोई अलर्ट कॉन्फ़िगर नहीं। कुछ नहीं।
वह कॉल ही कारण है कि अब मैं किसी भी प्रोडक्शन-ग्रेड डिप्लॉयमेंट से पहले हर क्लायंट के साथ Vercel बिलिंग हाइजीन पर बीस मिनट खर्च करता हूँ।
यहाँ देखें कि आपको Vercel पर बैंडविड्थ चार्जेस कैसे होते हैं, यह मुद्दा लोगों को आश्चर्यजनक क्यों लगता है, और इसके बारे में वास्तव में क्या करें।
---
Vercel पर "Egress" का असली मतलब क्या है
Egress वह डेटा है जो Vercel के नेटवर्क से बाहर निकलकर अंतिम उपयोगकर्ता तक पहुंचता है। हर इमेज, हर JavaScript बंडल, हर API प्रतिक्रिया, हर फॉन्ट फाइल। अगर यह उनके edge से निकलकर ब्राउज़र तक पहुंचती है, तो गिनी जाती है।
Hobby प्लान पर आपको प्रति माह 100GB बैंडविड्थ मिलता है, शामिल है। Pro पर यह 1TB है। सुनने में बहुत लगता है। लेकिन बात यह है: अगर आप बड़ी इमेजें serve कर रहे हैं, भारी JSON पेलोड वाले पेजों पर सर्वर-साइड रेंडरिंग कर रहे हैं, या आपके ऐप को अचानक ट्रैफिक स्पाइक आता है, तो आप 1TB को जितना सोचते हैं उससे कहीं तेजी से पार कर सकते हैं। Vercel इस लेखन के समय Pro पर overage के लिए $0.15 प्रति GB चार्ज करता है (हमेशा उनके मौजूदा pricing पेज को चेक करें क्योंकि यह बदलता रहता है)।
तो 500GB आपकी limit से ऊपर $75 है। विनाशकारी नहीं। लेकिन एक viral moment, एक गड़बड़ाया गया image optimisation सेटअप, या कोई scraper आपके API routes को hammer कर रहा हो? यह हजारों तक जा सकता है।
यह लोगों को अचंभित क्यों करता है
बात यह है कि local development आपको शून्य संकेत देता है। आप तेजी से बनाते हैं, तेजी से deploy करते हैं, सब कुछ ठीक लगता है। Vercel का dashboard बैंडविड्थ उपयोग दिखाता है लेकिन यह चीखता नहीं है। अगर आपने proactively एक billing alert सेट नहीं किया, तो आप जानते हैं जब invoice आता है।
---
वह Configs जो आपके Bill को तबाह करने की सबसे अधिक संभावना रखते हैं
मैंने Seahawk पर बहुत सारे deployments को audit किया है। मुझे चार culprits बार-बार दिखाई देते हैं।
1. Unoptimised Images जो next/image को Bypass करते हैं
next/image वास्तव में अपने काम में अच्छा है। यह resize करता है, WebP में convert करता है, और cache करता है। लेकिन मैंने ऐसी projects देखी हैं जहां developers सीधे एक <img> tag से इमेजें pull कर रहे थे जो S3 bucket में full-resolution फाइलों की ओर point करता था, Vercel API route के through proxied। हर request एक 4MB JPEG को Vercel के नेटवर्क के through pull कर रहा था बजाय 200KB WebP के एक CDN edge से। इसे 50,000 page views से गुणा करें और गणित करें।
हमेशा next/image का उपयोग करें और सही remotePatterns config के साथ करें। अगर image source बाहरी है, तो सुनिश्चित करें कि वह CDN cache को hit कर रहा है और आपके serverless functions के through कोई round trip नहीं बना रहा है।
2. API Routes जो Fat Payloads Return करते हैं
2021 में मैंने एक UK retailer के लिए एक e-commerce product catalogue बनाया था। उनका API route अपने database से product listing fetch कर रहा था और पूरे product object को return कर रहा था, उन fields सहित जिन्हें front end कभी use ही नहीं करता था। Description, internal SKU notes, variant metadata — सब कुछ। हर response लगभग 80KB था जबकि उसे केवल 12KB की जरूरत थी।
अपने API responses को trim करें। केवल वे fields return करें जिन्हें client वास्तव में consume करता है। अगर आप Prisma जैसी किसी चीज़ का उपयोग कर रहे हैं, तो select का उपयोग करें और जो pull करते हैं उसे सीमित करें। अगर आप किसी third-party API का उपयोग कर रहे हैं, तो payload को transform और slim करें उसे downstream भेजने से पहले।
3. High-Traffic Routes पर Short Revalidation Windows के साथ ISR
Incremental Static Regeneration सिद्धांत में शानदार है। व्यवहार में, अगर आप revalidate: 30 को एक page पर सेट करते हैं जिसे प्रति मिनट 10,000 hits मिलते हैं, तो आप सही तरीके से cache कर रहे हैं। लेकिन अगर आप revalidate: 1 पर सेट करते हैं क्योंकि आप near-real-time updates चाहते थे और इसे change करना भूल गए... तो आप मूलतः SSR कर रहे हैं extra steps के साथ और हर near-miss cache response पर egress के लिए payment कर रहे हैं।
अपने revalidation windows के बारे में जानबूझकर सोचें। अधिकांश content को हर सेकंड revalidate करने की जरूरत नहीं है।
4. No Caching Headers के साथ Serverless Functions
यह एक सूक्ष्म बात है। अगर आपके serverless function response में Cache-Control header नहीं है (या Vercel का s-maxage / stale-while-revalidate combo), तो response edge पर cache नहीं होता है। हर request function को hit करता है और पूरा round trip travel करता है। आप CDN benefit पूरी तरह से खो देते हैं और हर single response पर egress के लिए payment करते हैं।
`` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 ``
उस हेडर ने अकेले ही क्लाइंट्स के लिए असल पैसे बचाए हैं। गंभीरता से। Vercel के अपने ही कैशिंग डॉक्स हेडर बिहेवियर को विस्तार से समझाते हैं। एक बार सही से पढ़ लीजिए।
---
बिलिंग अलर्ट सेटअप कैसे करें (इससे पहले कि आपको जरूरत पड़े)
किसी भी प्रोडक्शन डिप्लॉय से पहले यह पहला स्टेप होना चाहिए। सातवां नहीं।
- अपनी Vercel टीम सेटिंग्स में जाइए।
- Billing के अंतर्गत Spend Management खोजें।
- एक स्पेंड लिमिट सेट करें (हार्ड कैप, जहां Vercel लिमिट के बाद रिक्वेस्ट्स सर्व करना बंद कर देता है) या एक नोटिफिकेशन थ्रेसहोल्ड (सॉफ्ट अलर्ट, जब आप किसी नंबर तक पहुंचें तो आपको ईमेल भेजता है)।
- मैं सुझाव देता हूं कि 50% पर एक नोटिफिकेशन सेट करें — जो आपको दर्दनाक लगता है उसका — और एक हार्ड लिमिट अपने अपेक्षित मासिक बिल के करीब 120% पर रखें।
हार्ड कैप दोधारी चीज है। अगर आप इसे हिट करते हैं, तो आपकी साइट डाउन हो जाती है। तो सोच-समझ कर निर्णय लीजिए। एक मार्केटिंग साइट के लिए? ठीक है, इसे सख्ती से कैप करें। एक SaaS के लिए पेइंग यूजर्स के साथ? उदार नोटिफिकेशन्स सेट करें और डैशबोर्ड पर नजर रखें।
---
भारी काम को कहीं और भेज देना
Vercel एक CDN नहीं है स्टैटिक असेट्स के लिए। मतलब, इसके पास CDN तो है, लेकिन आप इसके लिए प्रति गीगाबाइट पेमेंट कर रहे हैं। बड़ी मात्रा में स्टैटिक असेट्स के लिए, इन्हें कहीं सस्ते में रखें।
मैं लगभग अठारह महीने से Cloudflare R2 के माध्यम से बड़ी मीडिया फाइलें भेज रहा हूँ। R2 के कोई एग्रेस फीस नहीं हैं। आप स्टोरेज और ऑपरेशन्स के लिए पेमेंट करते हैं, डेटा निकालने के लिए नहीं। इमेज-भरी वेबसाइटों के लिए यह गंभीर बचत है। मेरे एक क्लाइंट के पास फोटोग्राफी पोर्टफोलियो प्लेटफॉर्म है और वह Vercel एग्रेस में लगभग $180/माह पेमेंट कर रहा था। हमने सभी फुल-रेज इमेजेज और गैलरी असेट्स को R2 में स्थानांतरित किया, थंबनेल को next/image के माध्यम से रखा, और Vercel का बिल $40 से नीचे गिर गया।
जानने लायक विकल्प:
- Cloudflare Pages स्टैटिक डिप्लॉयमेंट के लिए जहाँ आपको Vercel की edge सुविधाओं की जरूरत नहीं है। उदार फ्री टियर, कोई एग्रेस फीस नहीं।
- AWS CloudFront S3 के सामने अगर आप पहले से AWS इकोसिस्टम में हैं। ट्रांसफर लागत Vercel की ओवरेज दरों से स्केल पर कम है।
- BunnyCDN शुद्ध असेट डिलीवरी के लिए सस्ता और तेज़ है। मैंने इसे कुछ उच्च-ट्रैफिक WordPress-to-Next.js माइग्रेशन्स पर इस्तेमाल किया है जहाँ असेट वॉल्यूम बड़ा था।
मुद्दा यह है: Vercel आपके Next.js एप्लिकेशन लॉजिक चलाने के लिए सही जगह है। यह हमेशा आपके गीगाबाइट्स मीडिया परोसने के लिए सही जगह नहीं है।
---
रीयल टाइम में उपयोग की निगरानी करना
महीने के अंत में अपने डैशबोर्ड को चेक न करें। यही वजह है कि मेरा क्लाइंट सोमवार को मुझे फोन करने के लिए मजबूर हुआ।
कुछ चीजें जो मैं वास्तव में उपयोग करता हूं:
- Vercel Analytics आपको पेज-लेवल डेटा देता है और यह पहचानने के लिए उपयोगी है कि कौन से रूट सबसे ज्यादा ट्रैफिक (और इसलिए सबसे ज्यादा egress) जेनरेट कर रहे हैं।
- Axiom Vercel के log drains के साथ साफ-सुथरे तरीके से इंटीग्रेट करता है और आपको समय के साथ request size को क्वेरी करने देता है। मैंने इसे 2022 के अंत में उपयोग करना शुरू किया और यह बड़े प्रोजेक्ट्स पर ट्रैफिक स्पाइक्स को egress jumps के साथ correlate करने के लिए उपयोगी रहा है।
- एक सरल cron सेट करें (Vercel के पास अब native cron support है) जो उनके API को हिट करे और जब bandwidth एक threshold पार करे तो Slack चैनल पर पोस्ट करे। मैंने Seahawk के अपने infrastructure के लिए इसका एक lightweight version बनाया। दो घंटे लगते हैं, बहुत सारी चिंता बचाता है।
Vercel REST API deployment और usage डेटा को expose करता है। यह दुनिया का सबसे elegant API नहीं है लेकिन यह basic alerting के लिए जो चाहिए वह करता है।
---
आर्किटेक्चर का फैसला जिस पर कोई बात नहीं करता
यहां कुछ ऐसा है जो मुझे पर्याप्त चर्चित नहीं दिख रहा: कभी-कभी Vercel गलत default होता है।
अगर आपका प्रोजेक्ट कोई real dynamic functionality के बिना एक static marketing site है, तो आपको Vercel की जरूरत नहीं है। Cloudflare Pages या Netlify का free tier zero egress concerns के साथ काम कर देगा। आप Vercel को "बर्बाद" नहीं कर रहे, आप बस workload के लिए सही टूल में नहीं हैं।
दूसरी ओर, अगर आप edge middleware, server components और असली काम करने वाले API routes के साथ एक सही Next.js app बना रहे हैं, तो Vercel के लिए पैसे देना काबिले-ग़ौर है। DX सच में शानदार है और edge network तेज़ है। बस शुरुआत से ही इसे सही तरीक़े से डिज़ाइन करो।
मैंने अपने करियर की शुरुआत में (2016 के आस-पास, जब Vercel का अस्तित्व ही नहीं था, जब मैं Heroku और Netlify पर deployment को समझ रहा था) जो ग़लती की वह यह थी कि deployment platform को एक free afterthought मानना। Platform का चुनाव आपके cost profile को उतना ही shape करता है जितना आपके database का चुनाव करता है। इसे गंभीरता से लो।
---
FAQ
अगर मैं 100GB से ज़्यादा चली जाऊँ तो Hobby plan पर egress charges लगते हैं?
नहीं। Hobby plan पर Vercel overage का charge नहीं करता; जब तुम limit तक पहुँचो तो वह deployment को throttle या suspend कर देता है। किसी भी तरीक़े से बहुत अच्छा नहीं है, लेकिन तुम्हें कोई आश्चर्य वाला बिल नहीं आएगा। आश्चर्य वाले बिल Pro और Enterprise पर होते हैं जहाँ included amount के ऊपर usage metered होता है।
क्या Vercel का image optimisation egress में count होता है?
हाँ। next/image के ज़रिए serve किए गए optimised images भी egress में count होते हैं। बचत file size में है: तुम 3MB वाली JPEG की जगह 180KB WebP serve कर रहे हो, तो image के लिए egress बहुत कम है। Optimisation वही चीज़ है जो cost को कम करती है, कोई special exemption नहीं।
क्या मैं egress कम करने के लिए Vercel के सामने एक custom CDN use कर सकता हूँ?
तुम Cloudflare का proxy अपनी Vercel deployment के सामने रख सकते हो। Cloudflare अपने edge पर responses को cache करता है, जिसका मतलब वह requests जो Cloudflare के cache में hit होती हैं वह Vercel तक पहुँचती ही नहीं। यह egress और function invocations दोनों को significantly कम कर सकता है। Preview deployments और header handling के साथ कुछ caveats हैं, लेकिन production के लिए यह एक common और legitimate approach है। Cloudflare की proxying के बारे की documentation में setup है।
Vercel के बिलों में अचानक बढ़ोतरी का सबसे बड़ा एकल कारण क्या है?
मेरे अनुभव में: इमेज हैंडलिंग। या तो पूरी रेजोल्यूशन की इमेजें बिना ऑप्टिमाइजेशन के सर्व की जा रही हैं, या फिर इमेज ऑप्टिमाइजेशन रूट्स हर रिक्वेस्ट पर बिना सही कैशिंग के कॉल हो रहे हैं। पहले अपनी इमेज पाइपलाइन को ठीक करो, बाकी सब कुछ दूसरे नंबर पर।
क्या Vercel आपको अपने आप नोटिफाई करता है अगर उपयोग में स्पाइक आए?
डिफ़ॉल्ट रूप से नहीं। आपको इसे कॉन्फ़िगर करना होगा। कोई बिल्ट-इन अलर्ट नहीं है जो कहे "आपने 80% बैंडविड्थ का उपयोग कर लिया है।" यही खामी है। अपनी प्रोडक्शन डिप्लॉयमेंट सेट अप करने के उसी दिन अपनी स्पेंड मैनेजमेंट थ्रेशोल्ड सेट करो। बाद में नहीं।
---
Vercel एक शानदार प्लेटफॉर्म है। मैं इसे इस्तेमाल करता हूँ, Seahawk भी इसे इस्तेमाल करता है, और सही प्रोजेक्ट्स के लिए मैं इसकी सिफारिश करते रहूँगा। लेकिन यह एक मीटर्ड सर्विस है जो असली इंफ्रास्ट्रक्चर पर चल रही है, और कीमत उसी के अनुसार है। जो डेवलपर्स अचानक बिलों से परेशान होते हैं वे लगभग हमेशा वही होते हैं जिन्होंने इसे एक फ्री CDN की तरह ट्रीट किया और कभी बिलिंग सेटिंग्स पर नजर नहीं डाली। डिप्लॉय करते समय पाँच मिनट की कॉन्फ़िगरेशन आपको एक बहुत ही अनचाहे सोमवार की सुबह की फोन कॉल से बचा लेगी।
संबंधित पढ़ना: Luxury Jewelry Sites That Load in Under 1.5 Seconds, Core Web Vitals, और WordPress speed.