खास जानकारी
Google+ पूरी तरह से प्रतिक्रियाशील होता है.
रिस्पॉन्सिव विज्ञापन बनाना
Google+ वह जगह है जहां लोग ज़ॉम्बी कैट से लेकर विंटेज कैलकुलेटर तक, एक जैसी रुचि वाले लोगों के साथ मिलकर काम करते हैं. अभी हाल तक, Google+ के पास उनकी वेबसाइट के दो अलग-अलग वर्शन थे - एक डेस्कटॉप के लिए और दूसरा मोबाइल वेब के लिए जिसे पुराने ब्राउज़र के लिए डिज़ाइन किया गया था.
चैलेंज
दो साइटों का रखरखाव करने के साथ ही, कई तरह की चुनौतियों का सामना करना पड़ता है. साइट के अलग-अलग वर्शन होने का मतलब था कि हर सुविधा को दो बार लागू करना पड़ता था. इसकी वजह से बहुत सारे डुप्लीकेट कोड मिले और डेस्कटॉप और मोबाइल वेब के दो अनुभवों को ऑप्टिमाइज़ करने में ज़्यादा मेहनत करनी पड़ी. जैसे-जैसे डिवाइस के बीच की दूरी बेहद धुंधली होती गई - पहले से बड़ी स्क्रीन पर टच और शक्तिशाली मोबाइल डिवाइसों को चलाने की सुविधा देने वाले डेस्कटॉप का इस्तेमाल करना कम जगह बना हुआ था.
जैसे-जैसे हमने सुविधाएं जोड़ी, हमारी पुरानी डेस्कटॉप साइट भी धीमी हो गई और फूल गई. इस साल की शुरुआत में हमारे होम पेज का वज़न करीब 5 एमबी था और हमने करीब 250 एचटीटीपी अनुरोध तैयार किए थे. हालांकि, यह अच्छा परफ़ॉर्म नहीं कर रहा था. साइट पर मौजूद इमेज भारी और ऑप्टिमाइज़ नहीं की गई थीं. इस वजह से पेज और धीमा हो गया. इसका नतीजा यह हुआ कि धीमे और ठीक से काम न करने वाले नेटवर्क पर हमारी स्ट्रीम को करीब-करीब ऐक्सेस नहीं किया जा सका. साथ ही, इन लोगों का अनुभव भी अच्छा नहीं रहा. साथ ही, मोबाइल वेब पर लेगसी ब्राउज़र के साथ काम करने की वजह से हम पूरी साइट के लिए JavaScript पर निर्भर नहीं रहे. इस वजह से हम ज़्यादा इंटरैक्टिव सुविधाएं लागू नहीं कर पाए. हम मोबाइल वेब ब्राउज़र के डेवलपमेंट पर भरोसा नहीं कर सकते थे.
समस्या का हल
हमने रिस्पॉन्सिव डिज़ाइन पर फ़ोकस करने के साथ शुरुआत की थी: इसे लागू करने का एक तरीका जो मोबाइल, टैबलेट, डेस्कटॉप, और दूसरे प्लैटफ़ॉर्म पर काम करेगा. हमने हर एक सुविधा, पेज, JavaScript लाइब्रेरी, और सीएसएस क्लास की अच्छी तरह से जांच की. हम एक ऐसा सिस्टम बनाना चाहते थे, जिससे यह पक्का हो सके कि साइट सिर्फ़ वही डाउनलोड करे जो उसके काम करने के लिए ज़रूरी था और जब तक उपयोगकर्ता ने ज़्यादा अनुरोध न किया हो. चुनौती थी ऐसी वेबसाइट बनाना जो सेल्युलर कनेक्शन के साथ धीमे मोबाइल फ़ोन पर भी ठीक से काम करती हो, लेकिन तेज़ स्पीड वाले ब्राउज़र और बड़ी स्क्रीन पर शानदार अनुभव देती हो.
शर्तों के इस सेट का मतलब था कि हमें आने वाले समय में, हर कोड की जांच करनी होगी. इस लक्ष्य को हासिल करने के लिए हमने 6^5 नियम बनाया है, ताकि यह पक्का किया जा सके कि पेज लोड होने के शुरुआती समय पर हम 60K से ज़्यादा एचटीएमएल, JavaScript 60K से 60K सीएसएस, और हमारे ऐनिमेशन हमेशा 60 FPS (फ़्रेम प्रति सेकंड) थे. साथ ही, लोड होने में औसतन 0.6 सेकंड लगे.
इसके लिए, हमने JavaScript और सीएसएस फ़्रेमवर्क को चुना, जिन्होंने शुरुआत से ही मॉड्यूलरिटी और लेज़ी लोडिंग की सुविधा को ध्यान में रखा. इसलिए, हम यह पक्का करते हैं कि उपयोगकर्ता सिर्फ़ JavaScript और सीएसएस को तभी डाउनलोड करें, जब वे असल में उस सुविधा का इस्तेमाल करें जिसमें उसकी ज़रूरत है. ऐसा टेंप्लेट पर आधारित तरीके से किया जाता है. यह हमारे बिल्ड और मॉड्यूल सिस्टम के साथ मिलकर काम करता है. इससे डेवलपर को आसानी से काम करने में कोई परेशानी नहीं होती.
इस नए फ़्रेमवर्क के साथ, हमने वेब पर Google+ को फिर से लागू करने का प्रोटोटाइप बनाना शुरू किया. हमने “बुरी” चीज़ों को अस्वीकार करना शुरू कर दिया और विकास के लिए सख्त नियम सेट करने शुरू कर दिए. हमारा एक बड़ा नियम यह था कि हमारे सभी पेज, सर्वर-साइड और क्लाइंट-साइड, दोनों रेंडर होने चाहिए. सर्वर-साइड रेंडरिंग की मदद से हम यह पक्का करते हैं कि एचटीएमएल लोड होते ही उपयोगकर्ता पढ़ना शुरू कर सके. साथ ही, पेज के कॉन्टेंट को अपडेट करने के लिए JavaScript को चलाने की ज़रूरत न हो. एक बार पेज लोड होने और उपयोगकर्ता के किसी लिंक पर क्लिक करने के बाद, हम हर चीज़ को फिर से रेंडर करने के लिए, पूरी राउंड-ट्रिप नहीं करना चाहते. ऐसे में क्लाइंट-साइड रेंडरिंग काफ़ी अहम हो जाती है - हमें सिर्फ़ डेटा और टेंप्लेट को फ़ेच करना होता है, और क्लाइंट पर नया पेज रेंडर करना होता है. इसमें कई मुश्किलें शामिल होती हैं. इसलिए, हमने सर्वर-साइड और क्लाइंट-साइड रेंडरिंग को आसान बना दिया है. इसके लिए, सर्वर या क्लाइंट, दोनों को दो बार लागू करने की ज़रूरत नहीं पड़ती.
अन्य नियमों में लंबाई और चौड़ाई वाले ऐनिमेशन की अनुमति नहीं है. इससे ब्राउज़र के फिर से लेआउट का इस्तेमाल हो सकता है और परफ़ॉर्मेंस पर बुरा असर पड़ सकता है. DOM हेर-फेर और ऐनिमेशन के लिए हमने टास्क को ब्राउज़र की रेंडर रीफ़्रेश दर के साथ सिंक होने के लिए शेड्यूल किया. हम सभी मेज़र टास्क को एक साथ ग्रुप करते हैं, ताकि हम बार-बार होने वाले स्टाइल कैलकुलेशन से बच सकें. हमने Chrome प्रोफ़ाइलर टूल पर भी बहुत ज़्यादा भरोसा किया, ताकि यह पक्का किया जा सके कि सब कुछ आपकी उम्मीद के मुताबिक काम कर रहा हो. इसके अलावा, हमने ऐसे टूल बनाए हैं जो JS-फ़ुटप्रिंट पर कोड में होने वाले बदलावों के असर की गणना करते हैं, ताकि यह पक्का किया जा सके कि हम अपने पेज का साइज़ बहुत ज़्यादा न बढ़ाएं.
इसमें कुछ समय लगा, लेकिन अगर हम इस प्रक्रिया के दौरान समस्याओं को पहचानकर उन्हें ठीक न कर पाते, तो यह और भी मुश्किल हो जाता.
हमने फ़रवरी 2015 में इस प्रतिक्रियाशील लागू किए गए मोबाइल-वेब वर्शन को लॉन्च किया था. इससे हमें नए डिज़ाइन और नई प्रोसेस की जांच करने में मदद मिली. हमने इस लॉन्च से मिले डेटा का इस्तेमाल करके, इस बात की पुष्टि की है कि कौनसी चीज़ काम कर रही थी और कौनसी नहीं. हमने इस डिज़ाइन पर फिर से काम किया और इसे ज़्यादा से ज़्यादा डिवाइसों पर उपलब्ध कराने की शुरुआत की. हमने नवंबर 2015 में, सभी डिवाइसों पर इस नई सुविधा को लॉन्च किया था.
नतीजे
प्रदर्शन से समझौता किए बिना, Google+ एक समृद्ध यूज़र इंटरफ़ेस (यूआई) वाला जटिल वेब ऐप्लिकेशन बना पाया. साइट अब पहले से ज़्यादा तेज़ और कम लोड हुई है.
| पहला हिस्सा | बाद में | |
|---|---|---|
| होम पेज का कुल वज़न, gzip (इमेज के साथ) | 22,600 केबी | 327 केबी |
| अनुरोधों की गिनती | 251 | 45 |
| एचटीएमएल (gzip नहीं किया गया) | 1,100 केबी | 362 केबी |
| JavaScript और CSS (gzip) | 2,768 केबी | 111 केबी |
| पेज लोड होने में लगने वाला औसत समय (इंतज़ार का समय) | 12 सेकंड 0.7 सेकंड पहले बाइट के लिए |
3 सेकंड 0.1 सेकंड पहले बाइट के लिए |