headless-wordpress-astro-setup.html
< BACK गर्म सुनहरे घंटे की रोशनी में पांडुलिपि पृष्ठों और टेप मशीन वाली विंटेज डेस्क

Headless WordPress + Astro: सामग्री-प्रधान साइटों के लिए एक कार्यशील सेटअप

—

एक क्लाइंट ने मुझसे 2023 की शुरुआत में संपर्क किया — एक मीडिया प्रकाशक जो WordPress पर लगभग 14,000 पोस्ट चला रहा था, एक थीम जो छह साल में चार डेवलपर्स द्वारा इकट्ठा किया गया था, और Core Web Vitals स्कोर जो वास्तव में शर्मनाक था। उनका LCP मोबाइल पर 7.2 सेकंड में पहुँच रहा था। उन्होंने WP Rocket आजमाया, उन्होंने CDN आजमाया, उन्होंने अपने आधे प्लगइन भी हटा दिए। फिर भी धीमा। समस्या WordPress ही नहीं थी। यह थी कि हर एक पेज रेंडर PHP के माध्यम से जा रहा था, एक फूली हुई थीम, और एक डेटाबेस क्वेरी चेन जिसे 2018 के बाद से देखा ही नहीं गया था।

यह वह क्षण था जब मैंने Astro को फ्रंटएंड के रूप में लेकर एक headless सेटअप के लिए सही मायने में प्रतिबद्ध हुआ। इसलिए नहीं कि यह फैशनेबल है — इसलिए कि हजारों पोस्ट के साथ एक साइट के लिए जिसमें भारी संपादकीय सामग्री है, यह एकमात्र आर्किटेक्चर था जिसका अर्थ था।Astro as the frontend. Not because it's fashionable — because for a site pushing thousands of posts with heavy editorial content, it was the only architecture that made sense.

यहाँ बताया गया है कि मैंने इसे सटीक रूप से कैसे सेटअप किया। ट्रेडऑफ़, वास्तविक कॉन्फ़िगरेशन, वे बिट जिन्होंने मुझे परेशान किया।

---

Astro और Next.js नहीं क्यों

मुझसे यह सवाल काफी बार पूछा जाता है। अगर आपके पास पहले से React-heavy टीम है या आपको complex client-side interactivity की जरूरत है तो Next.js स्पষ्ट जवाब है। लेकिन content-heavy sites के लिए? Astro जीतता है, और यह बहुत करीब नहीं है।

Astro डिफ़ॉल्ट रूप से zero JavaScript भेजता है। एक ब्लॉग, news site या documentation portal के लिए, यह सही डिफ़ॉल्ट है। आप JavaScript को वहीं use करते हैं जहाँ आपको इसकी जरूरत है, इसके बजाय कि आप 200kb React bundle से opt out करें जिसकी आपको ज्यादातर चाहत नहीं है। Astro docs में partial hydration के बारे में — वे इसे Islands architecture कहते हैं — यह एक वाक्य में मुझ से ज्यादा अच्छी तरह समझाता है, लेकिन short version है: केवल interactive bits को ही JS मिलता है। article body, header, sidebar? Static HTML।zero JavaScript by default. For a blog, a news site, or a documentation portal, that's the correct default. You opt into JavaScript where you need it, rather than opting out of a 200kb React bundle you mostly don't want. The Astro docs on partial hydration — they call it the Islands architecture — explain it better than I can in a sentence, but the short version is: only the interactive bits get JS. The article body, the header, the sidebar? Static HTML.

मैंने late 2022 में Next.js और WordPress के साथ एक legal content site बनाया। काफी fast था, लेकिन client बार-बार पूछता रहता था कि जब "अब यह fast होना चाहिए" तो उनका Lighthouse score mobile पर 74 क्यों है। Hydration overhead। Astro के साथ, वही type की site अब routinely 95–98 को hit करती है। bragging नहीं कर रहा — यह सिर्फ वही है जो architecture आपको free में देता है।

Astro किस चीज़ में अच्छा नहीं है

सच कहना काबिलेतारीफ है। अगर आपकी site को real-time personalisation, heavy shopping cart, या कुछ ऐसा चाहिए जो वाकई client-side state पर कई components में निर्भर हो, तो Astro awkward महसूस करने लगता है। यह एक React app नहीं है। Islands pattern शक्तिशाली है, लेकिन यह SPAs बनाने से एक अलग mental model है। मैंने mid-2023 में एक client dashboard को Astro project में shoehorn करने की कोशिश की और दो हफ़्तों में Next.js पर वापस चला गया। जान लीजिए कि आप क्या बना रहे हैं।

---

WordPress को Headless CMS के रूप में Set Up करना

WordPress एक genuinely अच्छा headless backend है। WP REST API core में ships करता है, यह well-documented है, और आपकी editorial team को कुछ नया सीखना नहीं पड़ता। यह आखिरी बात developers के लिए आमतौर पर माना जाता है उससे ज्यादा मायने रखती है।WP REST API ships in core, it's well-documented, and your editorial team doesn't have to learn anything new. That last point matters more than developers usually admit.

यह वह setup है जो मैं use करता हूँ:

  1. WordPress को एक subdomain पर install करें — मैं cms.yourdomain.com या api.yourdomain.com use करता हूँ। इसे basic auth के पीछे रखें या कम से कम direct public traffic को restrict करें। frontend yourdomain.com है। दो अलग deployments। — I use cms.yourdomain.com or api.yourdomain.com. Keep it behind basic auth or at minimum restrict direct public traffic. The frontend is yourdomain.com. Two separate deployments.
  2. [WPGraphQL plugin](https://www.wpgraphql.com/) को इंस्टॉल करें — मैं REST की जगह GraphQL को कंटेंट साइट्स के लिए पसंद करता हूँ क्योंकि आप अपनी queries को अपने components के साथ co-locate कर सकते हैं और बिल्कुल वही fields fetch कर सकते हैं जो आपको चाहिए। कोई over-fetching नहीं। REST API ठीक है, लेकिन एक बार जब आपके पास प्रति post type 15+ custom fields हो जाएं, तो GraphQL approach स्पष्ट रूप से ज्यादा साफ है। — I prefer GraphQL over REST for content sites because you can co-locate your queries with your components and fetch exactly the fields you need. No over-fetching. The REST API is fine, but once you've got 15+ custom fields per post type, the GraphQL approach is noticeably cleaner.
  3. Advanced Custom Fields (ACF) और WPGraphQL for ACF extension को इंस्टॉल करें। यह combination WordPress को headless content model के रूप में सच में flexible बनाता है — आप प्रति post type structured data define कर सकते हैं, इसे GraphQL के जरिए expose कर सकते हैं, और Astro इसे cleanly consume करता है। and the WPGraphQL for ACF extension. This combo is what makes WordPress genuinely flexible as a headless content model — you can define structured data per post type, expose it through GraphQL, and Astro consumes it cleanly.
  4. Comments, emojis और default XML-RPC को disable करें अगर आपने पहले से नहीं किया है। ये overhead जोड़ते हैं और attack surface बढ़ाते हैं जो आपको चाहिए ही नहीं। if you haven't already. These add overhead and attack surface you don't need.
  5. Building शुरू करने से पहले permalinks को कुछ sensible में set करें। अगर आपके Astro routes पहले से set हैं तो mid-project में उन्हें बदलना सच में दर्दनाक है। to something sensible before you start building. Changing them mid-project when your Astro routes are already set is a genuine pain.

एक चीज जो लोगों को confuse करती है: CORS। Default में, WordPress अपने Astro dev server (localhost:4321 पर चलने वाले) को आपके WP install को requests करने नहीं देगा। Development के दौरान यह अपने theme के functions.php या एक छोटे utility plugin में डालें:localhost:4321) make requests to your WP install. Drop this into your theme's functions.php or a small utility plugin during development:

`` add_action('init', function() { header("Access-Control-Allow-Origin: *"); }); `` add_action('init', function() { header("Access-Control-Allow-Origin: *"); }); ``

Production में उसे specific origins तक tight करें। obviously।

---

Astro Project Structure

मैं इसे projects के across opinionated और consistent रखता हूँ। एक दर्जन या उससे ज्यादा headless builds के बाद, यह है जो काम करता है:

`` src/ components/ layouts/ pages/ index.astro blog/ [slug].astro lib/ wpgraphql.ts ← सभी WP query लॉजिक यहाँ रहता है styles/ `` src/ components/ layouts/ pages/ index.astro blog/ [slug].astro lib/ wpgraphql.ts ← all WP query logic lives here styles/ ``

lib/wpgraphql.ts फ़ाइल वह जगह है जहाँ मैं हर GraphQL fetch को एक जगह पर रखता हूँ। कोई inline fetch calls page फ़ाइलों में बिखरे हुए नहीं। हर query एक नाम वाला, exported async function है। जब 14,000 posts में से किसी एक चीज़ में 2am को कोई समस्या आए तो इसे debug करना — आप अपने आप को बाद में धन्यवाद देंगे।lib/wpgraphql.ts file is where I centralise every GraphQL fetch. No inline fetch calls scattered across page files. Every query is a named, exported async function. Debugging this across 14,000 posts when something breaks at 2am — you'll thank yourself later.

Build Time पर Posts को Fetch करना

Astro का getStaticPaths यहाँ आपका मुख्य औज़ार है। हज़ारों posts वाले blog के लिए:getStaticPaths is your bread and butter here. For a blog with thousands of posts:

`` export async function getStaticPaths() { const posts = await getAllPostSlugs(); // WPGraphQL को कॉल करता है return posts.map(post => ({ params: { slug: post.slug }, })); } `` export async function getStaticPaths() { const posts = await getAllPostSlugs(); // calls WPGraphQL return posts.map(post => ({ params: { slug: post.slug }, })); } ``

getAllPostSlugs WPGraphQL के ज़रिये after cursors का उपयोग करके pages में विभाजित होता है — WordPress का GraphQL layer डिफ़ॉल्ट रूप से 100 posts प्रति request रिटर्न करता है, इसलिए 14,000 posts के लिए आप build time पर 140 requests बना रहे हैं। यह डरावना लगता है। व्यवहार में, एक अच्छे server पर, पूरी build लगभग 4–5 मिनट में चलती है। एक site के लिए बिल्कुल स्वीकार्य जो दिन में कुछ बार rebuild होती है। paginates through WPGraphQL using after cursors — WordPress's GraphQL layer returns 100 posts per request by default, so for 14,000 posts you're making 140 requests at build time. That sounds scary. In practice, on a decent server, the full build runs in about 4–5 minutes. Perfectly acceptable for a site that rebuilds a few times per day.

---

Images को संभालना बिना अपना दिमाग खोए

यह वह हिस्सा है जिसके बारे में कोई काफ़ी नहीं बोलता। WordPress image URLs को आपके CMS subdomain की ओर इशारा करते हुए store करता है। जब Astro statically build करता है, तो वे images अभी भी cms.yourdomain.com पर रहती हैं — जिसका मतलब है कि आपके आगंतुकों के browsers आपके WordPress server से images fetch कर रहे हैं, संभवतः आपके CDN को bypass कर रहे हैं।cms.yourdomain.com — which means your visitors' browsers are fetching images from your WordPress server, potentially bypassing your CDN.

मैं इसे कुछ तरीकों से संभालता हूँ:

  • दोनों डोमेन के सामने Cloudflare रखें। सबसे आसान विकल्प। yourdomain.com और cms.yourdomain.com दोनों को Cloudflare के माध्यम से प्रॉक्सी करें, /wp-content/uploads/* पर आक्रामक कैशिंग कॉन्फ़िगर करें, और आप ज्यादातर ठीक हैं। Simplest option. Proxy both yourdomain.com and cms.yourdomain.com through Cloudflare, configure aggressive caching on /wp-content/uploads/*, and you're mostly fine.
  • मीडिया ऑफलोड प्लगइन का उपयोग करें। मुझे WP Offload Media पसंद है — यह अपलोड को S3 (या संगत स्टोरेज) में ले जाता है और URL को स्वचालित रूप से फिर से लिखता है। यह वह दृष्टिकोण है जो मैं किसी भी साइट के लिए उपयोग करता हूँ जो गंभीर ट्रैफिक की उम्मीद करता है। आपका WordPress सर्वर पूरी तरह से छवियों की सेवा देना बंद कर देता है। I like WP Offload Media — it moves uploads to S3 (or compatible storage) and rewrites URLs automatically. This is the approach I use for any site expecting serious traffic. Your WordPress server stops serving images entirely.
  • Astro का Image घटक। उन छवियों के लिए जिन्हें आप बिल्ड समय पर नियंत्रित करते हैं (GraphQL के माध्यम से खींची गई फीचर्ड छवियां), आप रिमोट URL को Astro के <Image> घटक में पास कर सकते हैं और यह उन्हें अनुकूलित, आकार बदल देगा, और आपके बिल्ड आउटपुट से सेवा देगा। शानदार तरीके से काम करता है। पोस्ट बॉडी HTML में एम्बेड की गई छवियों के लिए काम नहीं करता — इसके लिए एक अलग पास की आवश्यकता है। For images you control at build time (featured images pulled via GraphQL), you can pass the remote URL into Astro's <Image> component and it'll optimise, resize, and serve them from your build output. Works brilliantly. Does not work for images embedded in post body HTML — that requires a different pass.

Seahawk के पास पिछले साल एक ट्रैवल कंटेंट क्लाइंट था — लगभग 8,000 पोस्ट, अत्यंत छवि-भारी, प्रति लेख औसतन 12 छवियां। उनका WordPress सर्वर केवल छवि अनुरोधों से हथौड़े से पीटा जा रहा था, भले ही हेडलेस सेटअप के साथ। S3 + CloudFront में जाने से उनके ऑरिजिन बैंडविड्थ में 94% की गिरावट आई। उनके होस्टिंग बिल के लिए वास्तव में रूपांतरकारी।

---

इंक्रिमेंटल बिल्ड्स और रीबिल्ड समस्या

स्टेटिक जेनरेशन को स्केल पर एक वास्तविक समस्या है: आपका संपादक 3 बजे एक पोस्ट सुधार प्रकाशित करता है और 5 मिनट के लिए पूर्ण रीबिल्ड की प्रतीक्षा करना पड़ता है। यह न्यूजरूम में स्वीकार्य नहीं है।

कुछ दृष्टिकोण जो मैंने उपयोग किए हैं:

विकल्प 1: Netlify या Vercel with ऑन-डिमांड ISR। Astro एडेप्टर के साथ सर्वर-साइड रेंडरिंग का समर्थन करता है — आप Astro को हाइब्रिड मोड में चला सकते हैं जहां अधिकांश पृष्ठ स्टेटिक हैं लेकिन विशिष्ट रूट ऑन-डिमांड पर रेंडर किए जाते हैं। एक समाचार साइट के लिए, मैं अक्सर पिछले 30 दिनों की पोस्ट को स्टेटिकली प्री-रेंडर करूँगा (उच्च ट्रैफिक, गति की आवश्यकता) और पुरानी आर्काइव पेजों को ऑन-डिमांड पर सर्वर-रेंडर करने के लिए सेट करूँगा। दोनों दुनियाओं का सर्वश्रेष्ठ। Astro supports server-side rendering with adapters — you can run Astro in hybrid mode where most pages are static but specific routes are rendered on-demand. For a news site, I'll often statically pre-render the last 30 days of posts (high traffic, needs speed) and set older archive pages to server-render on demand. Best of both worlds.

विकल्प 2: वेबहुक-ट्रिगर्ड आंशिक बिल्ड्स। WordPress पोस्ट सेव पर एक वेबहुक फायर करता है (WP Webhooks प्लगइन के साथ आसान)। वह वेबहुक Netlify या Vercel डिप्लॉय हुक को हिट करता है। बिल्ड चलता है, यह केवल वह लाता है जो बदल गया है। यह सच में आंशिक नहीं है — Astro अभी भी सब कुछ रीबिल्ड करता है — लेकिन अगर आप अपनी बिल्ड को तेज़ रखते हैं, तो 4 मिनट व्यावहारिक है। WordPress fires a webhook on post save (easy with the WP Webhooks plugin). That webhook hits a Netlify or Vercel deploy hook. The build runs, it fetches only what's changed. It's not truly partial — Astro still rebuilds everything — but if you keep your build fast, 4 minutes is workable.

विकल्प 3: पूरी चीज़ के लिए बस SSR का इस्तेमाल करें। Astro को Node adapter के साथ एक VPS पर deploy करें (मैं इसके लिए Hetzner इस्तेमाल करता हूँ — सस्ता, तेज़, भरोसेमंद)। हर पेज request पर render होता है, आप Nginx या Cloudflare level पर aggressively cache करते हैं, और आपके पास तुरंत post updates होते हैं। यह वही है जो मैं 50,000 से ज़्यादा posts वाले एक proper publishing operation के लिए करूँगा। Deploy Astro with the Node adapter to a VPS (I use Hetzner for this — cheap, fast, reliable). Every page renders on request, you cache aggressively at the Nginx or Cloudflare level, and you have instant post updates. This is what I'd do for a proper publishing operation over 50,000 posts.

ईमानदारी से कहूँ तो? ज़्यादातर sites को Option 1 या 3 की complexity की ज़रूरत नहीं है। 90% content sites के लिए 4-minute का rebuild जो webhook से trigger हो, काफ़ी है।

---

Performance: आपको असल में क्या मिलता है

शुरुआत वाले publisher project पर — Astro migration के बाद यह हुआ:

  • LCP mobile पर 7.2s से 1.1s पर गिरा (London node से WebPageTest के साथ tested)1.1s on mobile (tested with WebPageTest from a London node)
  • Total Blocking Time ~800ms से 0ms पर गई (default से zero JS, याद है न)0ms (zero JS by default, remember)
  • उनकी Google Search Console Core Web Vitals report 3% "Good" URLs से 91% "Good" हो गई deployment के छः हफ़्तों में91% "Good" within six weeks of deployment
  • Hosting costs गिरे क्योंकि उनका WordPress server अब pages serve नहीं कर रहा था, सिर्फ़ API responses दे रहा था

इसमें कोई जादू नहीं है। यह बस यही होता है जब आप PHP rendering को critical path से निकाल देते हैं और हर reader को 400kb theme JavaScript bundle भेजना बंद कर देते हैं।

---

जो चीजें आपको फंसा देंगी

सच कहूं — ऐसी चीजें जिन्हें मुझे असली प्रोजेक्ट्स पर ठीक करना पड़ा है:

  • ड्राफ्ट पोस्ट प्रीव्यू। यह हेडलेस सेटअप में सचमुच खीझ देने वाली चीज है। WordPress का नेटिव प्रीव्यू फ्रंट-एंड रेंडरिंग पर निर्भर करता है। आपको Astro में एक कस्टम प्रीव्यू एंडपॉइंट बनाना होगा जो WordPress प्रीव्यू नॉन्स स्वीकार करे और WPGraphQL के जरिए ड्राफ्ट फेच करे। मुश्किल नहीं है, लेकिन इसे सही तरीके से करने में एक दिन लग जाता है। This is genuinely annoying in a headless setup. WordPress's native preview relies on front-end rendering. You need to build a custom preview endpoint in Astro that accepts a WordPress preview nonce and fetches the draft via WPGraphQL. Not hard, but it takes a day to do properly.
  • रीडायरेक्ट्स। अगर पुरानी साइट के पास .htaccess में सैकड़ों रीडायरेक्ट्स थे, तो वे अब WordPress सर्वर पर लाइव हैं। आपको या तो उन्हें Astro के कॉन्फिग में दोहराना होगा, या WordPress को सुलभ रखना होगा और विशिष्ट पाथ्स को प्रॉक्सी करना होगा। मैंने दोनों किए हैं। Astro में दोहराना लंबी अवधि में ज्यादा साफ है। If the old site had hundreds of redirects in .htaccess, those live on the WordPress server now. You need to either replicate them in Astro's config, or keep WordPress accessible and proxy specific paths. I've done both. Replicating in Astro is cleaner long-term.
  • सर्च। WordPress का बिल्ट-इन सर्च हेडलेस सेटअप में बेकार है। मैं Algolia के साथ WP Search with Algolia प्लगइन का उपयोग करता हूं। WP में अपनी पोस्ट्स को इंडेक्स करें, Astro Island कंपोनेंट से Algolia को क्वेरी करें। यह अच्छी तरह काम करता है। WordPress's built-in search is useless in a headless setup. I use Algolia with the WP Search with Algolia plugin. Index your posts in WP, query Algolia from an Astro Island component. Works well.
  • मेनू और नेविगेशन। WordPress मेनू WPGraphQL के जरिए एक्सपोज करने के लिए अजीब तरह से गड़बड़ाने वाले होते हैं। wpgraphql-acf रूट अक्सर ज्यादा साफ निकलता है — बस अपने नेव को ACF रिपीटर के तौर पर मॉडल करें और काम पूरा समझो। WordPress menus are weirdly fiddly to expose through WPGraphQL. The wpgraphql-acf route often ends up being cleaner — just model your nav as an ACF repeater and call it done.

---

FAQ

क्या मुझे WPGraphQL की जरूरत है या मैं बस REST API का उपयोग कर सकता हूं?

आप बिल्कुल REST API का उपयोग कर सकते हैं — यह WordPress कोर में बनाया हुआ है और किसी अतिरिक्त प्लगइन की आवश्यकता नहीं है। साधारण साइटों के लिए जिनमें स्टैंडर्ड पोस्ट टाइप और न्यूनतम कस्टम फील्ड हैं, यह ठीक है। जहां GraphQL अपनी जगह बनाता है वह तब है जब आपके पास कई कस्टम फील्ड के साथ जटिल कंटेंट मॉडल हो। एक ही रिक्वेस्ट में केवल वह फील्ड फेच करने में सक्षम होना जिनकी आपको जरूरत है, _embed पैरामीटर और नेस्टेड REST कॉल के साथ संघर्ष किए बिना, हर क्वेरी पर समय बचाता है। आपके ऊपर है। मुझे बस एक निश्चित जटिलता सीमा से आगे GraphQL ज्यादा स्वच्छ लगता है।_embed parameters and nested REST calls, saves time on every query you write. Up to you. I just find GraphQL cleaner past a certain complexity threshold.

मैं सदस्यों के लिए ही उपलब्ध कंटेंट के लिए WordPress प्रमाणीकरण कैसे संभालूं?

JWT प्रमाणीकरण मानक दृष्टिकोण है। JWT Authentication for WP REST API प्लगइन इंस्टॉल करें, लॉगिन पर टोकन जारी करें, उन्हें अपने GraphQL रिक्वेस्ट हेडर में पास करें। Astro की ओर से, आप इसे एक SSR रूट के साथ हैंडल करेंगे (स्टैटिक नहीं) ताकि यूजर-स्पेसिफिक कंटेंट हर रिक्वेस्ट के लिए सर्वर-साइड फेच किया जाए। इसे स्टैटिकली करने की कोशिश न करें — वह पागलपन की ओर जाता है।JWT Authentication for WP REST API plugin, issue tokens on login, pass them in your GraphQL request headers. On the Astro side, you'd handle this with an SSR route (not static) so the user-specific content is fetched server-side per request. Don't try to do this statically — that way lies madness.

क्या यह एक छोटे ब्लॉग के लिए बहुत ज्यादा है?

हां, संभवतः। अगर आपके पास 500 से कम पोस्ट और एक एडिटर है, तो हेडलेस सेटअप को बनाए रखने का ओवरहेड इसके लायक नहीं है। बस एक अच्छा WordPress थीम उपयोग करें, अपनी इमेज को ऑप्टिमाइज़ करें, और जीवन चलाते रहें। यह आर्किटेक्चर तब फायदेमंद होता है जब आपके पास वॉल्यूम, एडिटोरियल जटिलता, या ट्रैफिक लेवल हो जहां परफॉर्मेंस सच में राजस्व पर फर्क डालता है।

उत्पादन में होस्टिंग सेटअप कैसा दिखता है?

WordPress (केवल CMS) एक छोटे VPS या मैनेज्ड WordPress होस्ट पर — मैं Kinsta या Cloudways उपयोग करता हूँ। Astro फ्रंटएंड Vercel, Netlify, या प्रोजेक्ट के आधार पर Nginx के साथ एक Hetzner VPS पर। हर चीज के सामने Cloudflare। एक मध्यम आकार की कंटेंट साइट के लिए कुल मासिक लागत आमतौर पर £60–£120 है, जो अक्सर उससे कम है जो क्लायंट एक ऑल-इन-वन WordPress होस्ट के लिए भुगतान कर रहे थे जो लोड के तहत संघर्ष कर रहा था।less than what clients were paying for an all-in-one WordPress host that was struggling under the load.

---

ईमानदारी से कहूँ तो: headless WordPress with Astro कंटेंट साइटों के लिए हाल के समय में बेहतरीन चीजों में से एक है। इसलिए नहीं कि यह नया है, बल्कि इसलिए कि टूलिंग आखिरकार इस विचार के अनुरूप हो गई है। WPGraphQL स्थिर है, Astro की बिल्ड सिस्टम तेज़ है, और परफॉर्मेंस लाभ वास्तविक और मापने योग्य हैं।

आर्किटेक्चर को जल्दी सही करें — विशेष रूप से आपकी इमेज स्ट्रेटेजी और आपके रीबिल्ड दृष्टिकोण — और आप बाद में बहुत कम समय समस्या निवारण में बिताएंगे। यही सब कुछ है।

< BACK