तुमची वेबसाइट जलद कशी बनवायची: व्यावहारिक चेकलिस्ट
वेबसाइट जलद बनवण्यासाठी आधी PageSpeed Insights ने तिचे मोजमाप करा, मग ते दाखवणारे सर्वात मोठे कारण दुरुस्त करा — सहसा खूप मोठ्या इमेजेस, जास्त JavaScript, जड फॉन्ट्स किंवा तृतीय-पक्ष स्क्रिप्ट्स. Google च्या Core Web Vitals चे "चांगले" लक्ष्य गाठा: मुख्य कंटेंट 2.5 सेकंदांत दिसावा, टॅपला 200 मिलिसेकंदांत प्रतिसाद मिळावा, आणि लेआउट जवळजवळ उडू नये. बहुतेक साइट्स हे काही मोजक्या बदलांनी गाठतात, पुनर्लेखनाची गरज नसते.
काहीही बदलण्यापूर्वी मोजा
अंदाज लावणे वेळ वाया घालवते. दोन मोफत साधने जवळजवळ सर्वांसाठी पुरेशी आहेत:
- PageSpeed Insights (pagespeed.web.dev) — एक लाइव्ह URL पेस्ट करा. ते खऱ्या Chrome वापरकर्त्यांचा field data (तुमच्या साइटवर पुरेसा ट्रॅफिक असल्यास) आणि सिम्युलेटेड लोडचा lab data, तसेच विशिष्ट समस्यांची यादी दाखवते.
- Lighthouse Chrome DevTools मध्ये — तोच lab चाचणी, तुम्ही उघडू शकता अशा कोणत्याही पानावर, preview सह. मोबाइल मोडमध्ये चाचणी करा; कमी वेगाच्या नेटवर्कवरील फोन्सवरच समस्या दिसतात.
जे आकडे महत्त्वाचे आहेत ते Google चे Core Web Vitals आहेत. सप्टेंबर 2026 पर्यंत, Google च्या web.dev वरील दस्तऐवजात हे "चांगले" उंबरठे दिलेले आहेत, पेज लोडच्या 75 व्या पर्सेंटाइलवर मोजलेले:
| मेट्रिक | काय मोजते | चांगले |
|---|---|---|
| Largest Contentful Paint (LCP) | मुख्य कंटेंट (हिरो इमेज, मथळा) किती लवकर दिसतो | 2.5 s किंवा कमी |
| Interaction to Next Paint (INP) | क्लिक, टॅप आणि टायपिंगला पान किती लवकर प्रतिसाद देते | 200 ms किंवा कमी |
| Cumulative Layout Shift (CLS) | लोड होताना लेआउट किती उडते | 0.1 किंवा कमी |
INP ने 2024 मध्ये जुन्या First Input Delay मेट्रिकची जागा घेतली. एखादे साधन अजूनही FID नोंदवत असेल, तर ते जुने झाले आहे.
तुमचे सुरुवातीचे आकडे लिहून ठेवा. प्रत्येक दुरुस्तीनंतर पुन्हा चाचणी करा, म्हणजे कोणते उपयोगी पडले ते कळेल.
वेळ कुठे जातो: पर्याय आणि तडजोड
प्रत्येक सामान्य कारणाला एक दुरुस्ती आहे, आणि प्रत्येक दुरुस्तीची किंमत आहे. वरच्या कारणांपासून सुरुवात करा — ती सर्वात स्वस्त आणि सर्वात सामान्य आहेत.
| कारण | सामान्य दुरुस्ती | तडजोड |
|---|---|---|
| मोठ्या इमेजेस | दिसणाऱ्या आकारापर्यंत कमी करा, कॉम्प्रेस करा, WebP किंवा AVIF वापरा | जास्त कॉम्प्रेस केल्यास थोडी गुणवत्ता कमी |
| इमेजेस चुकीच्या क्रमाने लोड होणे | फोल्डखालील इमेजेस lazy-load करा; हिरो इमेजला उच्च प्राधान्य द्या | काही नाही, जर हिरो lazy नसेल तरच |
| खूप जास्त JavaScript | प्रति पान कोड विभाजित करा, न वापरलेल्या लायब्ररी काढा | काही रीफॅक्टरिंग |
| क्लायंट-फक्त रेंडरिंग | सार्वजनिक पाने प्रीरेंडर किंवा सर्व्हर-रेंडर करा | अधिक बिल्ड किंवा सर्व्हर सेटअप |
| वेब फॉन्ट्स | कमी फॅमिली आणि वजने, मुख्य फॉन्ट preload करा, font-display: swap | कमी टायपोग्राफिक विविधता |
| तृतीय-पक्ष स्क्रिप्ट्स | न वापरलेल्या काढा, उरलेल्या पानानंतर लोड करा | एखादे विजेट किंवा ट्रॅकर गमावणे |
| मंद सर्व्हर प्रतिसाद | caching, CDN, कंटेंट पानांसाठी स्टॅटिक होस्टिंग | cache invalidation चा विचार करावा लागतो |
इमेजेस
इमेजेस ही सर्वात सामान्य समस्या आहे आणि दुरुस्त करायला सर्वात सोपीही. 800 pixels मध्ये दाखवलेला 4,000-pixel फोटो प्रत्येक अभ्यागताला त्याने पाहिल्यापेक्षा पाचपट जास्त डाउनलोड करायला लावतो.
- इमेजेस दाखवल्या जाणाऱ्या आकारातच द्या, फोन आणि डेस्कटॉपसाठी प्रतिसादक्षम
srcsetआकारांसह. - आधुनिक फॉरमॅट्स (WebP किंवा AVIF) आणि योग्य कॉम्प्रेशन वापरा.
- प्रत्येक इमेजवर
widthआणिheightसेट करा म्हणजे ब्राउझर जागा राखून ठेवतो. यामुळेच बहुतांश लेआउट शिफ्ट सुटते. - फोल्डखालील इमेजेस
loading="lazy"ने lazy-load करा. - पानाच्या वरची मुख्य इमेज कधीही lazy-load करू नका. Google चे LCP मार्गदर्शन यावर स्पष्ट आहे: LCP इमेजला lazy-load केल्याने ती नेहमी उशिरा येते. त्याऐवजी
fetchpriority="high"द्या.
JavaScript
अनेक AI-बनवलेल्या साइट्स सिंगल-पेज ॲप्स (SPA) असतात: ब्राउझर JavaScript bundle डाउनलोड करतो आणि मग पान रंगवतो. bundle जितका मोठा, तितका रिकामी स्क्रीन जास्त वेळ. दुरुस्ती, प्रयत्नांच्या क्रमाने:
- न वापरलेले काढा. डिपेंडेन्सीजची यादी मागा आणि एकदा जोडून विसरलेल्या लायब्ररी कापा — एका तारखेसाठी एक date लायब्ररी, पाच आयकॉन्ससाठी संपूर्ण आयकॉन पॅक.
- प्रति route विभाजित करा. अॅडमिन डॅशबोर्डचा कोड कोणी तो उघडेपर्यंत लोड करू नका, होम पेजवर नको.
- सार्वजनिक पाने प्रीरेंडर करा. मार्केटिंग पान खरे HTML म्हणून येते, तेव्हा कोणतेही JavaScript चालण्यापूर्वी ते दिसते. यामुळे शोध इंजिनांनाही मदत होते; AI-बनवलेल्या वेबसाइट्ससाठी SEO पहा.
मंद INP सहसा एका लांब टास्कमुळे पान अडवले गेल्याचे लक्षण असते — प्रत्येक कीस्ट्रोकवर मोठी यादी फिल्टर करणे, किंवा एका सेलमध्ये बदल झाल्यावर संपूर्ण टेबल पुन्हा रेंडर करणे. Chrome DevTools चा Performance पॅनल कोणता ते दाखवतो.
फॉन्ट्स
प्रत्येक फॉन्ट फॅमिली आणि वजन ही आणखी एक फाइल असते. दोन फॅमिली आणि तीन-चार वजने सहसा पुरेशी असतात. फोल्डवरील वरच्या भागात वापरलेला फॉन्ट preload करा, font-display: swap वापरा म्हणजे मजकूर लगेच दिसतो, आणि बाह्य फॉन्ट सेवा तुमच्या अभ्यागतांसाठी मंद असल्यास फॉन्ट स्वतः होस्ट करा.
तृतीय-पक्ष स्क्रिप्ट्स
चॅट विजेट्स, analytics, heatmaps, जाहिरात पिक्सेल्स, एम्बेड केलेले व्हिडिओ आणि सोशल फीड्स इतर सर्व्हरवरून कोड लोड करतात. प्रत्येक एक लहान वाटतो; एकत्र ते अनेकदा पानाचा सर्वात मंद भाग असतात. तुम्ही खरोखर पाहता त्या ठेवा. उरलेल्या पानानंतर लोड करा, आणि जड एम्बेड्स (YouTube प्लेअर, नकाशा) क्लिकवर खरा कंटेंट लोड करणाऱ्या हलक्या preview ने बदला.
सर्व्हर प्रतिसाद
Time to first byte (TTFB) — सर्व्हरला उत्तर द्यायला सुरुवात करायला किती वेळ लागतो — इतर सर्व मेट्रिक्सच्या खाली असतो. CDN (तुमच्या अभ्यागतांजवळच्या सर्व्हर्सचे नेटवर्क; CDN म्हणजे काय पहा) वरून दिलेली स्टॅटिक पाने जवळजवळ सर्वत्र जलद असतात. प्रत्येक विनंतीवर सर्व्हरने बांधलेली पाने त्या सर्व्हर आणि त्याच्या डेटाबेसवर अवलंबून असतात. Caching द्वारे वारंवार होणारे काम वाचवणे आणि मंद क्वेरींसाठी डेटाबेस इंडेक्स जोडणे हे नेहमीचे उपाय आहेत.
उपयुक्त प्रॉम्प्ट्स
विशिष्ट रहा: पान, मेट्रिक आणि मर्यादा नाव द्या. तुमच्याकडे PageSpeed Insights चे निष्कर्ष असतील तर ते पेस्ट करा.
PageSpeed Insights नुसार होम पेजचा मोबाइलवर LCP 4.8 s आहे, आणि LCP घटक हिरो इमेज आहे. हिरो इमेज आकार बदला आणि WebP मध्ये रूपांतरित करा, प्रतिसादक्षम आकार द्या, width आणि height सेट करा, तिला fetchpriority="high" द्या आणि ती lazy-load नाही याची खात्री करा. फोल्डखालील प्रत्येक इमेज lazy-load करा. डिझाइन बदलू नका.
या ॲपच्या डिपेंडेन्सीजचे ऑडिट करा. प्रत्येक पॅकेज, ते कोण वापरते आणि bundle मध्ये अंदाजे किती भर घालते ते यादी करा. न वापरलेले काढा, आणि /admin आणि /settings routes ना भेट दिली तेव्हाच लोड होणाऱ्या वेगळ्या chunks मध्ये विभाजित करा.
/products वरील शोध बॉक्स मंद वाटतो. फिल्टर debounce करा, प्रत्येक कीस्ट्रोकवर संपूर्ण यादी पुन्हा रेंडर करणे टाळा, आणि यादीत 200 पेक्षा जास्त आयटम असल्यास ती paginate किंवा virtualise करा.
पायरी-पायरीने
- लाइव्ह पान तपासा मोबाइलवर PageSpeed Insights मध्ये. LCP, INP आणि CLS आणि यादी केलेल्या वरच्या तीन समस्या नोंदवा.
- इमेजेस आधी दुरुस्त करा: आकार, फॉरमॅट, परिमाणे, फोल्डखालील lazy loading, हिरोला प्राधान्य.
- न वापरलेल्या तृतीय-पक्ष स्क्रिप्ट्स कापा, आणि उरलेल्या उशिरा लोड करा.
- फॉन्ट्स कमी करा डिझाइनला जितके हवे तितकेच ठेवा.
- JavaScript लहान करा: न वापरलेले पॅकेज काढा, प्रति route विभाजित करा.
- सार्वजनिक पाने प्रीरेंडर करा जर त्या अजूनही क्लायंट-रेंडर होत असतील आणि LCP अजूनही मंद असेल.
- सर्व्हर तपासा: caching, डेटाबेस इंडेक्स, क्वचित बदलणाऱ्या कंटेंटसाठी स्टॅटिक होस्टिंग.
- पुन्हा प्रकाशित करा आणि पुन्हा तपासा. PageSpeed Insights मधील field data पुढील आठवड्यांत खऱ्या भेटी येतील तसे अद्ययावत होते, म्हणून सुरुवातीच्या निकालांसाठी lab data वर निर्णय घ्या.
सामान्य चुका
- फक्त वेगवान लॅपटॉपवर चाचणी करणे. तुमचे अभ्यागत मध्यम दर्जाच्या फोनवर आणि अडखळत्या मोबाइल डेटावर आहेत. मोबाइल मोडमध्ये चाचणी करा.
- परिपूर्ण 100 चा पाठलाग करणे. lab स्कोअर मार्गदर्शक आहे. एकदा Core Web Vitals चांगल्या श्रेणीत आले की, शेवटचे काही गुण यापेक्षा कंटेंट आणि वापरण्यायोग्यता जास्त महत्त्वाची असते.
- सर्वकाही lazy-load करणे, हिरो इमेजसह. त्याने LCP आणखी वाईट होतो.
- वर आणखी एक speed plugin किंवा लायब्ररी जोडणे. वजन काढणे नेहमी ते व्यवस्थापित करणारा अधिक कोड जोडण्यापेक्षा चांगले असते.
- लाइव्ह साइटऐवजी preview ऑप्टिमाइझ करणे. डेव्हलपमेंट previews ऑप्टिमाइझ न केलेले build चालवतात. प्रकाशित URL मोजा.
- वेग एकदाच दुरुस्त करणे. प्रत्येक नवीन विजेट, इमेज आणि वैशिष्ट्य वजन वाढवते. मोठ्या बदलांनंतर पुन्हा चाचणी करा.
वेग चेकलिस्ट
- मोबाइलवर LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1
- इमेजेस आकार बदललेल्या, कॉम्प्रेस केलेल्या, आधुनिक फॉरमॅटमधील, width आणि height सह
- हिरो इमेज lazy नाही; फोल्डखालील इमेजेस lazy-load
- न वापरलेल्या JavaScript लायब्ररी नाहीत; जड routes वेगळे केलेले
- दोन फॉन्ट फॅमिली किंवा कमी, मुख्य फॉन्ट preload केलेला
- फक्त वापरत असलेल्या तृतीय-पक्ष स्क्रिप्ट्स, उशिरा लोड
- सार्वजनिक पाने शक्य तिथे प्रीरेंडर केलेली किंवा स्टॅटिक
- प्रकाशित केल्यानंतर लाइव्ह URL वर पुन्हा चाचणी
वेग आणि मोबाइल मांडणी एकत्र जातात; वेबसाइट मोबाइल-प्रतिसादक्षम कशी बनवायची पहा. लाँचपूर्वीच्या संपूर्ण पाससाठी, AI प्रोटोटाइप प्रॉडक्शनपर्यंत कसा न्यायचा बाकीचे सांगते.
Mythex वर वेग
Mythex वर हे बदल तुम्ही चॅटमध्ये विचारून करता, किंवा Pro वर कोड एडिटरमध्ये. तपासणी प्रिव्ह्यूवर नव्हे, प्रकाशित URL वर करा, कारण Preview development server चालवते. स्टॅटिक फ्रंट एंड्स प्रकाशित केल्यावर स्टॅटिक साइट्स म्हणून डिप्लॉय होतात (स्टॅटिक वेबसाइट्स), जे कंटेंट पानांसाठी योग्य आहे. सर्व्हर असलेले ॲप्स शून्यावर स्केल होतात: निष्क्रिय असताना झोपतात आणि पुढच्या भेटीवर जागे होतात, त्यामुळे शांत कालावधीनंतरची पहिली विनंती हळू असते, आणि जोडलेला डेटाबेस 5 मिनिटे निष्क्रिय राहिल्यावर झोपतो (होस्टिंग मर्यादा). सार्वजनिक पान फक्त पहिल्या भेटीलाच हळू असेल, तर हेच सहसा कारण असते. सार्वजनिक मार्केटिंग पाने स्टॅटिक ठेवल्याने मदत होते. बदलांनंतर पुन्हा प्रकाशित करा आणि hard-refresh करा.
प्रश्न
चांगला पेज लोड वेळ कोणता?
Google च्या Core Web Vitals मध्ये सर्वात स्पष्ट लक्ष्ये आहेत: मुख्य कंटेंट 2.5 सेकंदात दिसावा (LCP), पानाने इनपुटला 200 मिलिसेकंदांत प्रतिसाद द्यावा (INP), आणि लेआउट शिफ्ट 0.1 किंवा त्याहून कमी असावा (CLS), खऱ्या भेटींच्या 75 व्या पर्सेंटाइलवर मोजून.
वेबसाइटच्या वेगाचा SEO वर परिणाम होतो का?
थोडा, हो. Google Core Web Vitals सह page experience संकेत वापरते, पण संबंधित कंटेंट खूप जास्त महत्त्वाचा आहे. वेगाचा अभ्यागतांवर जास्त परिणाम होतो, कारण ते काहीही वाचण्यापूर्वी मंद पानांवरून निघून जातात.
माझा PageSpeed Insights स्कोअर प्रत्येक वेळी वेगळा का येतो?
लॅब स्कोअर एका सिम्युलेटेड लोडवरून येतो, त्यामुळे प्रत्येक धावेत नेटवर्क आणि सर्व्हरची वेळ बदलते. काही वेळा चालवा आणि कल पहा, आणि खऱ्या Chrome वापरकर्त्यांकडून येणाऱ्या field data विभागाला जास्त महत्त्व द्या.
बहुतेक वेबसाइट्सला सर्वात जास्त काय मंद करते?
सहसा खूप मोठ्या इमेजेस, खूप जास्त JavaScript, वेब फॉन्ट्स आणि चॅट विजेट्स, जाहिरात पिक्सेल्स किंवा एम्बेड्ससारख्या तृतीय-पक्ष स्क्रिप्ट्स. मंद सर्व्हर प्रतिसाद किंवा कोल्ड-स्टार्ट होणारा backend या सर्वात भर घालतो.