TTSWP आपके पेजों पर ऑडियो जोड़ता है, बिना परफॉर्मेंस को नुकसान पहुंचाए। प्लेयर lazy-loaded है, assets ऑप्टिमाइज़ हैं, और जब तक जरूरी न हो, पेज लोड पर कुछ भी नहीं चलता। यहां बताया गया है कि हम Core Web Vitals को कैसे सुरक्षित रखते हैं।
Core Web Vitals पर प्रभाव
LCP (Largest Contentful Paint)
प्रभाव: शून्य
ऑडियो प्लेयर lazy-loaded है। जब तक विजिटर उसके करीब स्क्रॉल नहीं करता, तब तक यह JavaScript रेंडर या लोड नहीं करता। LCP, जो above-the-fold मुख्य कंटेंट रेंडर होने का समय मापता है, इससे अप्रभावित रहता है।
टेस्ट: पहले और बाद में Lighthouse ऑडिट करें। LCP स्कोर सामान्य सीमा के भीतर रहते हैं।
CLS (Cumulative Layout Shift)
प्रभाव: शून्य
प्लेयर placeholder के dimensions बिल्कुल पूरी तरह लोड हुए प्लेयर जैसे ही होते हैं। जब lazy load placeholder से पूरे प्लेयर में अपग्रेड करता है, तो कोई layout shift नहीं होती।
INP (Interaction to Next Paint)
प्रभाव: नगण्य
प्लेयर का JavaScript एक छोटी सी फाइल (लगभग 15 KB gzipped) में चलता है। Click handlers debounced हैं और जहां supported हो, requestIdleCallback पर चलते हैं। सामान्य INP योगदान: प्रति इंटरेक्शन 5 ms से कम।
FID (First Input Delay, 2024 में INP से बदला गया)
प्रभाव: शून्य
शुरुआती पेज लोड पर main thread को कुछ भी block नहीं करता, क्योंकि प्लेयर lazily लोड होता है।
Asset साइज़
जब प्लेयर उपयोग में हो तो प्रति पेज लोड लागत:
| Asset | साइज़ (gzipped) | कब लोड होता है |
|---|---|---|
| Public player CSS | 3 KB | जब प्लेयर दिखे |
| Public player JS | 15 KB | जब प्लेयर दिखे |
| Waveform helper (PRO) | 4 KB | जब waveform सक्षम हो |
| Sticky footer JS (PRO) | 2 KB | जब sticky सक्षम हो |
| Admin bar menu icon | 0.5 KB | केवल admin users के लिए |
विजिटर्स पर पहले लोड का कुल प्रभाव: जब तक वे प्लेयर तक स्क्रॉल नहीं करते, 0 bytes।
Cache plugin संगतता
TTSWP हर प्रमुख cache plugin (WP Rocket, LiteSpeed, W3 Total Cache, WP Super Cache, Cache Enabler) के साथ काम करता है। प्लगइन अपने assets को सही caching व्यवहार के लिए auto-register करता है।
ऑडियो फाइलें (MP3) के अपने cache headers होते हैं और storage से मांग पर लोड होती हैं। ये page caches को नहीं रोकतीं।
देखें Caching plugins।
CDN डिलीवरी
Paid plans पर, ऑडियो फाइलें Amazon CloudFront से serve की जाती हैं। इसका मतलब है:
- Play क्लिक करने के milliseconds के भीतर ऑडियो चलता है, चाहे विजिटर आपके सर्वर से कितनी भी दूर हो
- आपके WordPress सर्वर की बैंडविड्थ HTML के लिए मुक्त रहती है
Free plans पर, ऑडियो आपके WordPress सर्वर से आता है। अधिकांश blogs के लिए यह ठीक है। ज्यादा ट्रैफिक वाली साइटें ऑडियो-heavy पेजों पर बैंडविड्थ उपयोग देख सकती हैं।
Database प्रभाव
TTSWP कुछ database tables और rows जोड़ता है:
- Audio cache table (प्रत्येक generated फाइल के लिए एक row)
- Statistics tables (प्रत्येक play event के लिए एक row - छोटा integer data)
- Settings rows (कुछ दर्जन options)
Database का आकार ऑडियो वाले posts की संख्या के साथ रैखिक रूप से बढ़ता है। 500 posts वाली साइट के लिए, कुल database footprint आमतौर पर 200 KB से कम होती है।
Memory और CPU
- प्रति admin पेज लोड PHP memory overhead: ~2 MB
- प्लेयर वाले public पेज पर PHP memory overhead: नगण्य (केवल CSS + JS, hot paths पर कोई PHP processing नहीं)
- Background processes: कोई नहीं (हर request पर कोई cron jobs नहीं चलते)
अपनी साइट टेस्ट करना
यह verify करने के लिए इन tools का उपयोग करें कि TTSWP आपकी परफॉर्मेंस को नुकसान नहीं पहुंचाता:
- PageSpeed Insights - Google का आधिकारिक Core Web Vitals टेस्ट
- WebPageTest - विस्तृत waterfall breakdown
- GTmetrix - परफॉर्मेंस ग्रेड और सिफारिशें
एक बार TTSWP enabled के साथ चलाएं, एक बार अस्थायी रूप से disabled के साथ। नंबरों की तुलना करें।
अगर आप परफॉर्मेंस में गिरावट देखते हैं
हमें बताएं। हम परफॉर्मेंस में गिरावट को bugs की तरह मानते हैं:
- नोट करें कि कौन सा पेज धीमा है
- PageSpeed Insights चलाएं और URL साझा करें
- PRO Support से संपर्क करें या WordPress.org forum पर पोस्ट करें
हम diagnose और ठीक करने में मदद करेंगे।