ऐसे प्रोग्रेसिव वेब ऐप्लिकेशन बनाना जिन्हें इंंडेक्स किया जा सके

बुधवार, 09 नवंबर, 2016

प्रोग्रेसिव वेब ऐप्लिकेशन (PWA), उपयोगकर्ताओं को मोबाइल साइटों और नेटिव ऐप्लिकेशन का बेहतरीन अनुभव देने के लिए, नई टेक्नोलॉजी का इस्तेमाल कर रहे हैं. वेब पर सबसे मज़ेदार नए आइडिया इनसे ही मिलते हैं. लेकिन बड़े स्तर पर असर डालने के लिए, यह ज़रूरी है कि उन्हें इंंडेक्स किया जा सके और लिंक किया जा सके. इस लेख में दिया गया हर सुझाव, पेज को इंडेक्स करने के सबसे सही तरीकों में पहले से शामिल है. भले ही, प्रोग्रेसिव वेब ऐप्लिकेशन बनाया जा रहा हो या एक सामान्य स्टैटिक वेबसाइट. फिर भी, आपको गाइड करने के लिए यहां सबसे सही तरीकों की एक चेकलिस्ट दी गई है:

अपने कॉन्टेंट को क्रॉल करने के लायक बनाना

क्यों? वेबसाइटें हमेशा से, सर्वर पर अपना एचटीएमएल जनरेट या रेंडर किया करती हैं जो यह सुनिश्चित करने का सबसे आसान तरीका है कि आपका कॉन्टेंट, सीधे लिंक किए जाने लायक है या नहीं. वेब ऐप्लिकेशनों की मदद से क्लाइंट-साइड रेंडरिंग को लोकप्रियता मिली जिसमें पेज अपने-आप डाइनैमिक तरीके से अपडेट हो जाता है और इसके लिए उपयोगकर्ता के ज़रिए पेज को रीलोड करने की ज़रूरत नहीं होती.

हाइब्रिड रेंडरिंग आधुनिक तरीका है जिसमें उपयोगकर्ता के ज़रिए सीधे यूआरएल पर नेविगेट किए जाने पर, सर्वर-साइड रेंडरिंग का इस्तेमाल होता है और शुरुआती पेज लोड होने के बाद, आगे के नेविगेशन और एसिंक्रोनस रिक्वेस्ट के लिए क्लाइंट-साइड रेंडरिंग का इस्तेमाल होता है.

हमारे सर्वर साइड PWA नमूने से पूरी तरह सर्वर साइड रेंडरिंग और हाइब्रिड PWA नमूने से मिले-जुले तरीके का पता चलता है.

अगर आपको सर्वर साइड और क्लाइंट-साइड रेंडरिंग टर्मिनोलॉजी के बारे में पता नहीं है, तो क्लाइंट और सर्वर साइड रेंडरिंग, और प्रतिक्रिया और node.js में सर्वर साइड रेंडरिंग के बारे में ये लेख पढ़ें.

सबसे सही तरीके:

सर्वर-साइड या हाइब्रिड रेंडरिंग का इस्तेमाल करें, ताकि उपयोगकर्ताओं को अपने वेब अनुरोध के शुरुआती पेलोड में ही कॉन्टेंट मिल जाए.

यह हमेशा पक्का कर लें कि आपके यूआरएल, अलग से ऐक्सेस किए जा सकें:

https://www.example.com/product/25/

इस यूआरएल को उस विशेष संसाधन से डीप लिंक होना चाहिए.

अगर आपके प्रोग्रेसिव वेब ऐप्लिकेशन के लिए, सर्वर-साइड या हाइब्रिड रेंडरिंग की सुविधा काम नहीं करती और आपने क्लाइंट-साइड रेंडरिंग का इस्तेमाल करने का फ़ैसला लिया है, तो हमारा सुझाव है कि Google Search Console "Fetch as Google टूल" का इस्तेमाल किया जाए, ताकि इस बात की पुष्टि की जा सके कि आपका कॉन्टेंट, हमारे सर्च क्रॉलर के लिए सफलतापूर्वक रेंडर हो.

डीप लिंक ऐक्सेस करने वाले उपयोगकर्ताओं को वापस अपने वेब ऐप्लिकेशन के होम पेज पर रीडायरेक्ट न करें.

इसके अलावा, उपयोगकर्ताओं को डीप लिंकिंग के बजाय गड़बड़ी वाला पेज दिखाने से भी बचना चाहिए.

बिना गड़बड़ी वाले यूआरएल दें

क्यों? फ़्रैगमेंट आइडेंटिफ़ायर (#user/24601/ या #!user/24601/), पेज को फिर से लोड किए बिना, किसी सर्वर से नए कॉन्टेंट पर AJAX करने का कारगर तरीका था जिसका इस्तेमाल ब्राउज़र किया करते थे. इस डिज़ाइन को क्लाइंट-साइड रेंडरिंग कहा जाता है.

हालांकि, फ़्रैगमेंट आइडेंटिफ़ायर सिंटैक्स Facebook के ओपन ग्राफ़ प्रोटोकॉल जैसे कुछ वेब टूल, फ़्रेमवर्क, और प्रोटोकॉल के साथ काम नहीं करता है.

History API की मदद से, हम संसाधनों को एसिंक्रोनस तरीके से फ़ेच करना जारी रखते हुए, फ़्रैगमेंट आइडेंटिफ़ायर के बिना यूआरएल को अपडेट कर पाते हैं. इस तरह, पेज को फिर से लोड नहीं करना पड़ता है—यह दोनों तरह से फ़ायदेमंद है. क्रॉल करने की AJAX स्कीम (अपने #! / एस्केप किए गए फ़्रैगमेंट यूआरएल के साथ) अपने समय के अनुसार बहुत आधुनिक थी, लेकिन अब इसे इस्तेमाल करने का सुझाव नहीं दिया जाता है.

हमारे हाइब्रिड PWA और क्लाइंट-साइड PWA नमूने History API के बारे में बताते हैं.

सबसे सही तरीके:

बिना फ़्रैगमेंट आइडेंटिफ़ायर वाले (# या #!) ऐसे यूआरएल दें जिनमें गड़बड़ी न हो, जैसे कि:

    https://www.example.com/product/25/
  

क्लाइंट-साइड या हाइब्रिड रेंडरिंग का इस्तेमाल करते समय यह पक्का कर लें कि History API, ब्राउज़र नेविगेशन के साथ काम करता हो.

ऐसा करने से बचें:

यूनीक यूआरएल पाने के लिए, #! यूआरएल स्ट्रक्चर को इस्तेमाल करने की सलाह नहीं दी जाती है:

    https://www.example.com/#!product/25/

यह History API के आने से पहले काम को आसान बनाने के लिए लाया गया था. इसे पूरी तरह # यूआरएल संरचना से एक बिलकुल अलग पैटर्न माना जाता है.

! चिह्न के बिना # यूआरएल स्ट्रक्चर सपोर्ट नहीं करता है:

https://www.example.com/#product/25/

वेब में ऐसे यूआरएल स्ट्रक्चर, पहले से मौजूद हैं और चुनिंदा पेज पर कॉन्टेंट में डीप लिंकिंग से संबंधित है.

कैननिकल यूआरएल के बारे में बताना

क्यों? जब एक ही कॉन्टेंट, कई यूआरएल (चाहे एक ही डोमेन से या अलग-अलग) पर मौजूद हो, तो ऐसे में इंडेक्स करते समय भ्रम की स्थिति से बचने के लिए, किसी एक पेज को कैननिकल के तौर पर मार्क कर दिया जाए और उस कॉन्टेंट वाले दूसरे सभी पेजों को डुप्लीकेट के तौर पर मार्क कर दिया जाए.

सबसे सही तरीके:

किसी कॉन्टेंट को मिरर करने वाले सभी पेजों पर ये टैग शामिल करें:

<link rel="canonical"  href="https://www.example.com/your-url/" />

अगर आपकी साइट, Accelerated Mobile Pages पर काम करती है, तो इसके मिलते-जुलते rel="amphtml" निर्देश का भी इस्तेमाल करें.

ऐसा करने से बचें:

कई यूआरएल में जान-बूझकर डुप्लीकेट कॉन्टेंट शामिल करने और rel="canonical" लिंक एलिमेंट का इस्तेमाल नहीं करने से बचें.

उदाहरण के लिए, ट्रैकिंग पैरामीटर की मदद से, rel="canonical" लिंक एलिमेंट यूआरएल की अस्पष्टता को कम कर सकता है.

अपने पेजों के बीच कैननिकल रेफ़रंस बनाने से बचें.

एक से ज़्यादा डिवाइस के लिए डिज़ाइन करना

क्यों? यह ज़रूरी है कि आपकी वेबसाइट देखने के दौरान आपके सभी उपयोगकर्ताओं को बेहतरीन अनुभव मिले. चाहे वे कोई भी डिवाइस इस्तेमाल कर रहे हों.

अपनी साइट को डिज़ाइन में रिस्पॉन्सिव बनाएं. इसके लिए, साइट के फ़ॉन्ट, मार्जिन, पैडिंग, बटन, और साइट के सामान्य डिज़ाइन को स्क्रीन रिज़ॉल्यूशन और डिवाइस के व्यूपोर्ट के हिसाब से, डाइनैमिक तौर पर बड़े या छोटे होने चाहिए.

मूल रूप से छोटे आकार की इमेज को डेस्कटॉप या टैबलेट के लिए बड़ी करने से, उपयोगकर्ताओं को खराब अनुभव मिलता है. इसके उलट, हाई रिज़ॉल्यूशन वाली इमेज को मोबाइल फ़ोन पर डाउनलोड होने में ज़्यादा समय लगता है. इससे, मोबाइल स्क्रोल की परफ़ॉर्मेंस पर असर पड़ सकता है.

PWA के लिए UX के बारे में ज़्यादा पढ़ें.

सबसे सही तरीके:

अलग-अलग डेंसिटी वाली स्क्रीन पर अलग रिज़ॉल्यूशन वाली इमेज फ़ेच करने के लिए, srcset एट्रिब्यूट का इस्तेमाल करें. इससे ऐसी इमेज डाउनलोड करने से बचा जा सकेगा जो डिवाइस की स्क्रीन के साइज़ से बड़ी हैं.

यह पक्का करने के लिए कि आपका टेक्स्ट पढ़ने लायक हो, अपने टेक्स्ट के फ़ॉन्ट का साइज़ और लाइन की ऊंचाई तय करें. इसी तरह, यह पक्का करें कि एलिमेंट की पैडिंग और मार्जिन भी सही तरीके से स्केल की गई हो.

Chrome डेवलपर टूल की डिवाइस मोड सुविधा और मोबाइल-फ़्रेंडली जांच टूल का इस्तेमाल करके अलग-अलग स्क्रीन रिज़ॉल्यूशन की जांच करें.

उपयोगकर्ताओं को Google से अलग कोई भी कॉन्टेंट न दिखाएं. अगर अलग-अलग डिवाइसों के लिए साइट का डिज़ाइन बदलने के लिए रीडायरेक्ट या उपयोगकर्ता एजेंट की पहचान करने (यानी ब्राउज़र के आंकड़े देखना या डाइनैमिक तरीके से दिखाना) का इस्तेमाल किया जाता है, तो ज़रूरी है कि कॉन्टेंट में कोई बदलाव न हो.

Search Console "Fetch as Google" टूल का इस्तेमाल करके इस बात की पुष्टि करें कि Google ने वही कॉन्टेंट फ़ेच किया है जो उपयोगकर्ता को दिखाई दे रहा है.

उपयोगिता की वजहों से, तय साइज़ वाले फ़ॉन्ट का इस्तेमाल करने से बचें.

फिर से डेवलप करें

क्यों? किसी वेब ऐप्लिकेशन में सुविधाएं जोड़ते समय सबसे सुरक्षित तरीका है लगातार बदलाव करना. एक-एक करके सुविधाएं जोड़ने पर, हर बदलाव का असर देखा जा सकता है.

वैकल्पिक रूप से, कई डेवलपर प्रोग्रेसिव वेब ऐप्लिकेशन को अपनी मोबाइल साइट को एक झटके में जांचने व सुधारने के अवसर के तौर पर देखना पसंद करते हैं — एक आइसोलेटेड माहौल में किसी नए वेब ऐप्लिकेशन को डेवलप करना और तैयार हो जाने पर इसे इसकी मौजूदा मोबाइल साइट से बदल देना.

जब डेवलप की जा रही सुविधाएं बार-बार बदलावों को अलग-अलग हिस्सों में बांटने की कोशिश करती हैं. उदाहरण के लिए, अगर आपको सर्वर-साइड रेंडरिंग से हाइब्रिड रेंडरिंग पर जाना है, तो इसे एक बार फिर से होने के तौर पर टैकल करें — न कि अन्य सुविधाओं के साथ मिलकर.

दोनों ही तरीकों के अपने फ़ायदे व नुकसान हैं. फिर से करने से, Search को इंडेक्स करने की जटिलता कम हो जाती है क्योंकि यह लगातार होने वाला बदलाव है. हालांकि, फिर से होने की वजह से डेवलप होने की प्रोसेस में देरी हो सकती है और डेवलपमेंट, शुरू से न किए जाने पर हो सकता है कि कम सुधार हो.

दोनों ही मामलों में, कैननिकल यूआरएल और आपकी साइट के robots.txt कॉन्फ़िगरेशन सबसे संवेदनशील हिस्से हैं जिन पर गौर किए जाने की ज़रूरत है.

सबसे सही तरीके:

नई सुविधाओं को एक-एक हिस्से के रूप में जोड़कर अपनी वेबसाइट पर को बढ़ाएं.

उदाहरण के लिए, अगर आपकी साइट अब तक एचटीटीपीएस की सुविधा नहीं देती, तो किसी सुरक्षित साइट पर माइग्रेशन के साथ शुरुआत करें.

ऐसा करने से बचें:

अगर आपने अपने प्रोग्रेसिव वेब ऐप्लिकेशन को किसी आइसोलेटेड जगह पर डेवलप किया है, तो इस बात की जांच किए बिना उसे लॉन्च न करें कि rel-canonical यूआरएल के लिंक और robots.txt सही तरीके से सेट अप हों.

पक्का करें कि आपके rel-canonical लिंक, असल साइट पर ले जाते हों और आपके robots.txt कॉन्फ़िगरेशन से, क्रॉलर आपकी नई साइट को क्रॉल कर सकें.

लॉन्च से पहले, डेवलप हो रही अपनी साइट पर क्रॉलर को इंडेक्स करने से रोकना पूरी तरह सही है, लेकिन लॉन्च करने पर इन क्रॉलर को अपनी साइट ऐक्सेस करने से अनब्लॉक करना न भूलें.

परतदार वृद्धि का इस्तेमाल करना

क्यों? जहां भी संभव हो, इस्तेमाल से पहले ब्राउज़र की सुविधाओं की पहचान ज़रूर करनी चाहिए. उन ब्राउज़र के लिए सुविधा की पहचान, परीक्षण से बेहतर होती है, जिनके लिए आपको भरोसा हो कि वे किसी ख़ास सुविधा से लैस हैं.

पहले इससे जुड़ी एक गलत प्रोसेस का पालन किया जाता था जिसमें उपयोगकर्ता के ब्राउज़र की पहचान करके सुविधाओं को चालू या बंद कर दिया जाता था. हालांकि, ब्राउज़र में लगातार नई सुविधाएं जुड़ती रहती हैं, इसलिए इस तकनीक का पूरी तरह विरोध किया जाता है.

इसके मुकाबले सर्विस वर्कर एक नई टेक्नोलॉजी है. यह ज़रूरी है कि काम करते समय किसी भी तरह की रुकावट न आए, इसलिए यह परतदार वृद्धि का एक बेहतरीन उदाहरण है.

सबसे सही तरीके:

किसी सर्विस वर्कर को रजिस्टर करने से पहले उसके एपीआई की उपलब्धता जांच लें:

if ('serviceWorker' in navigator) {
...

अपनी वेबसाइट की सभी सुविधाओं के लिए, प्रति एपीआई पहचान का तरीका इस्तेमाल करें.

अपने वेब ऐप्लिकेशन में सुविधाओं को चालू या बंद करने के लिए, कभी भी ब्राउज़र के उपयोगकर्ता एजेंट का इस्तेमाल न करें. हमेशा जांच लें कि सुविधा का एपीआई उपलब्ध है या नहीं. अगर उपलब्ध नहीं है, तो कृपया अनुकूल तरीके से गिरावट करें.

एक से ज़्यादा ब्राउज़र पर टेस्ट किए बिना अपनी साइट को अपडेट या लॉन्च करने से बचें! आपके उपयोगकर्ता आधार के बीच कौनसा ब्राउज़र ज़्यादा लोकप्रिय है यह जानने के लिए अपने साइट का विश्लेषण देखें.

Search Console के साथ टेस्ट करना

क्यों? यह समझना ज़रूरी है कि Google खोज आपकी साइट के कॉन्टेंट को कैसे देखता है. Search Console का इस्तेमाल, अपनी साइट से अलग-अलग यूआरएल फ़ेच करने के लिए किया जा सकता है और "क्रॉल > Fetch as Google" सुविधा का इस्तेमाल करके देखें कि Google Search उन्हें किस तरह देखता है. Search Console आपकी JavaScript को प्रोसेस करेगा और विकल्प चुने जाने पर पेज को रेंडर करेगा नहीं तो सिर्फ़ मूल एचटीएमएल प्रतिक्रिया दिखाई जाएगी.

Google Search Console कई तरीकों से आपके पेज के कॉन्टेंट का विश्लेषण भी करता है जिसमें स्ट्रक्चर्ड डेटा, रिच कार्ड, साइटलिंक, और Accelerated Mobile Pages की मौजूदगी का पता करना शामिल हैं.

सबसे सही तरीके:

Search Console का इस्तेमाल करके अपनी साइट को मॉनिटर करें और “Fetch as Google” सहित इसकी अन्य सुविधाओं को एक्सप्लोर करें.

Search Console क्रॉल >साइटमैप के ज़रिए साइटमैप उपलब्ध कराएं. यह इस बात की पुष्टि करने का आसान तरीका हो सकता है कि Google Search को आपकी साइट के सभी पेज के बारे में पता है.

Schema.org स्ट्रक्चर्ड डेटा के साथ व्याख्या करना

क्यों? Schema.org स्ट्रक्चर्ड डेटा, आपके पेज के सबसे ज़रूरी हिस्सों को मशीन में प्रोसेस किए जा सकने वाले डेटा की खास जानकारी देने के लिए आसान शब्दकोष है. यह किसी पेज को NewsArticle कहने जितना सामान्य है या किसी टूरिंग बैंड की जगह, बैंड का नाम, परफ़ॉर्म करने की जगह ,और टिकट विक्रेता बताने जितना या फिर किसी व्यंजन की पूरी विधि बताने जितना विस्तृत हो सकता है.

हो सकता है कि आपके वेब ऐप्लिकेशन के हर पेज के लिए, इस मेटाडेटा का कोई काम न हो लकिन जहां इसकी ज़रूरत है वहां इसके इस्तेमाल का सुझाव दिया जाता है. पेज को रेंडर करने के बाद, Google इसे निकाल लेता है.

डेटा टाइप कई तरह के होते हैं. NewsArticle, Recipe, और Product इनके कुछ उदाहरण हैं. इस्तेमाल किए जा सकने वाले सभी डेटा टाइप को यहां एक्सप्लोर किया जा सकता है.

सबसे सही तरीके:

Google के स्ट्रक्चर्ड डेटा टेस्टिंग टूल का इस्तेमाल करके, पुष्टि करें कि आपके Schema.org का मेटा डेटा सही है.

यह जांचें कि आपने जो डेटा दिया है, वह दिखाया जा रहा है और उसमें कोई भी गड़बड़ी नहीं है.

ऐसे डेटा टाइप इस्तेमाल करने से बचें जो आपके पेज के असल कॉन्टेंट से मेल नहीं खाता हो. उदाहरण के लिए, बेची जा रही टी-शर्ट के लिए, Recipe के बजाय Product का इस्तेमाल करें.

Open Graph और Twitter कार्ड के साथ व्याख्या करना

क्यों? Schema.org के मेटाडेटा के अलावा, यह Facebook के Open Graph प्रोटोकॉल और Twitter के रिच कार्ड जोड़ने में भी मददगार हो सकता है.

जब आपका कॉन्टेंट, उनसे जुड़े सोशल नेटवर्क पर शेयर किया जाता है तो ये मेटाडेटा फ़ॉर्मैट, उपयोगकर्ता अनुभव को बेहतर बनाते हैं.

अगर आपकी मौजूदा साइट या वेब ऐप्लिकेशन, इन फ़ॉर्मैट का इस्तेमाल करते हैं तो यह पक्का करना ज़रूरी है कि वे आपके प्रोग्रेसिव वेब ऐप्लिकेशन के साथ ऑप्टिमल वायरलिटी में शामिल हों.

सबसे सही तरीके:

Facebook ऑब्जेक्ट डीबगर टूल की मदद से, अपने ओपन ग्राफ़ मार्कअप की जांच करें.

Twitter के मेटाडेटा फ़ॉर्मैट के बारे में जानें.

अगर आपकी मौजूदा साइट पर इसका सपोर्ट मौजूद है, तो इन फ़ॉर्मैट को शामिल करना न भूलें.

एक से ज़्यादा ब्राउज़र के साथ टेस्ट करना

क्यों? एक उपयोगकर्ता के नज़रिए से यह साफ़ तौर पर ज़रूरी है कि कोई भी वेबसाइट सभी ब्राउज़र पर एक जैसा परफ़ॉर्म करे. हालांकि अलग-अलग साइज़ की स्क्रीन के लिए उनके अनुसार अनुभव मिल सकते हैं पर हम सबकी यही उम्मीद करते हैं कि कोई भी मोबाइल साइट उसी साइज़ के दूसरे डिवाइस पर भी बिलकुल एक जैसा काम करे, फिर चाहे वह iPhone हो या कोई Android मोबाइल फ़ोन.

जहां एक तरफ़ दुनिया भर में इस्तेमाल किए जा रहे कई ब्राउज़र की वजह से वेब को फ़्रैगमेंट किया गया माना जा सकता है, यह वैरायटी और कॉम्पिटीशन उन खूबियों में शामिल हैं जो वेब को ऐसा शानदार प्लेटफ़ॉर्म बनाती है. अच्छी बात यह है कि वेब स्टैंडर्ड पहले इतने गंभीर नहीं थे, जितने अब हैं और आधुनिक टूल, डेवलपर को पूरे आत्मविश्वास के साथ रिच, सभी ब्राउज़र के साथ काम करने वाली वेबसाइट बनाने की सुविधा देते हैं.

सबसे सही तरीके:

यह पक्का करने के लिए कि आपका PWA, अलग-अलग ब्राउज़र के साथ काम करता है, BrowserStack.com, Browserling.com या BrowserShots.org जैसे क्रॉस ब्राउज़र टेस्टिंग टूल का इस्तेमाल करें.

पेज लोड परफ़ॉर्मेंस मापना

क्यों? कोई वेबसाइट उपयोगकर्ता के लिए जितनी जल्दी लोड होगी, उपयोगकर्ता का अनुभव उतना ही बेहतर माना जाएगा. वेब डेवलपमेंट में पेज स्पीड को ऑप्टिमाइज़ करना, पहले से ही लोकप्रिय तरीका है, लेकिन कभी-कभी किसी साइट के नए वर्शन के डेवलपमेंट के दौरान ज़रूरी ऑप्टिमाइज़ेशन को सबसे ज़रूरी नहीं माना जाता है.

प्रोग्रेसिव वेब ऐप्लिकेशन डेवलप करने के दौरान हम सुझाव देते हैं कि आप अपने पेज लोड होने की गति के प्रदर्शन को मापें और बेहतरीन नतीजे के लिए, लॉन्च से पहले ऑप्टिमाइज़ेशन करें.

सबसे सही तरीके:

अपनी साइट की पेज लोड परफ़ॉर्मेंस की जांच करने के लिए, पेज स्पीड से जुड़े इनसाइट और वेब पेज टेस्ट जैसे टूल का इस्तेमाल करें. एक तरफ़ Googlebot, रेंडरिंग में थोड़ा ज़्यादा धैर्य से काम करता है. दूसरी तरफ़ रिसर्च से पता चला है कि 40% उपभोक्ता ऐसे पेज को छोड़कर चले जाते हैं जिसे लोड होने में तीन सेकंड से ज़्यादा लगते हैं.

वेब पेज की परफ़ॉर्मेंस से जुड़े सुझावों और रेंडर करने के ज़रूरी पाथ के बारे में यहां ज़्यादा जानें.

ऑप्टिमाइज़ेशन को लॉन्च के बाद के लिए न छोड़ें. अगर आपकी वेबसाइट का कॉन्टेंट, नए प्रोग्रेसिव वेब ऐप्लिकेशन पर माइग्रेट होने से पहले तुरंत लोड हो जाता है, तो यह ज़रूरी है कि आपके ऑप्टिमाइज़ेशन में कोई कमी न रहे.

हम आशा करते हैं कि ऊपर दी गई चेकलिस्ट आपके काम की है और आपको इंडेक्स किए जाने की सुविधा को ध्यान में रखते हुए, प्रोग्रेसिव वेब ऐप्लिकेशन डेवलप करने में मदद करने का सही तरीका बताती है.

जब आप शुरू करें, तो पक्का करें कि हमारे प्रोग्रेसिव वेब ऐप्लिकेशन इंडेक्स किया जा सकने वाले नमूनों को देखना न भूलें जो क्लाइंट-साइड, सर्वर-साइड और हाइब्रिड रेंडरिंग का प्रदर्शन करते हैं. अगर आपका कोई सवाल है, तो कृपया हमारे वेबमास्टर फ़ोरम पर हमसे संपर्क करें.

इसे डेवलपर एडवोकेट, टॉम ग्रीनअवे ने पोस्ट किया