विकास पाइपलाइन के हिस्से के रूप में तेजी से साइट का काम प्रदान करना

वेबसाइट का प्रदर्शन केवल वेबसाइट पेजों को तेजी से लोड करने के बारे में नहीं है। डेवलपर्स और अन्य परियोजना प्रतिभागियों के लिए प्रभावी वेब संसाधनों के महत्व को व्यक्त करना भी आवश्यक है। कार्यक्षमता कार्यक्षमता का एक ही हिस्सा है क्योंकि बाकी सब, इसलिए इसका कार्यान्वयन "किसी दिन" नहीं किया जा सकता है।



लंबे समय तक मेरे प्रदर्शन का विषय। मुझे याद है कि यह सब "लालची" और "एल्गोरिदम को विभाजित और जीतना" जानने के साथ शुरू हुआ था। कोड लेने के बारे में कुछ विशेष रूप से सुखद था, जिसे पूरा करने में कई मिनट लगे, इसे फिर से पाना और कुछ सेकंड में कार्य पूरा करना।

यदि हम नेटवर्क के बारे में बात करते हैं, तो प्रदर्शन समस्याएं अलग हैं: आमतौर पर यह कम्प्यूटेशनल जटिलता नहीं है, लेकिन सही तरीके से आवश्यक कार्यों को सर्वोत्तम तरीके से करने के लिए। पहली नज़र में, यह कार्य प्राथमिक लग सकता है, लेकिन वास्तव में यह बहुत अधिक जटिल है।

Alconost में अनुवादित

स्टीव सुडर पहले से ही यह विश्लेषण करने में रुचि रखने वाले थे कि ब्राउज़र वेब संसाधनों का अनुरोध कैसे करते हैं और एक प्रतिक्रिया की प्रतीक्षा करते हैं: कौन से संसाधन काम को रोकते हैं, जिन्हें स्थगित किया जा सकता है, प्रतिक्रिया हेडर के साथ क्या होता है? अपने शोध के परिणामों के आधार पर, उन्होंने एक वेबसाइट को जल्दी से लोड करने के लिए 14 नियमों की एक सूची बनाई। उदाहरण के लिए, यहां प्रदर्शन नियम हैं जो YSlow टूल में लागू होते हैं (आप पहले से ही इससे परिचित हो सकते हैं) ।


14 स्टीव सूडर्स नियम ( स्रोत )

आज उत्पादकता को नियंत्रित करने के लिए अधिक से अधिक नए उपकरण हैं: कुछ को अलग से लॉन्च करने की आवश्यकता है, जबकि अन्य को विकास और तैनाती पाइपलाइन में बनाया गया है। उनमें से एक Google का लाइटहाउस है : यह PWA संकेतकों (प्रगतिशील वेब अनुप्रयोगों), एसईओ, आदि पर डेटा प्रदर्शित करता है।


Google I / O 2018 सम्मेलन ( स्रोत ) में दिखाए गए लाइटहाउस 3.0 का स्क्रीनशॉट

ऐसे उपकरण यह तय करने में मदद करते हैं कि साइट को अंतिम रूप देते समय क्या विशेष ध्यान देना है, और साथ ही, उन्होंने बहुत सी अवधारणाएं लागू की हैं, जिनमें से यह पता लगाना इतना आसान नहीं है: पीआरपीएल, रेल, पेंट टाइमिंग एपीआई, टीटीआई, एचटीटीपी: 2, गति सूचकांक, प्राथमिकता संकेत और अधिक ...

परफॉर्मेंस पर्दे के पीछे क्यों है

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

इसलिए, मैं यह समझाने की कोशिश नहीं कर रहा हूं कि वेबसाइट का प्रदर्शन महत्वपूर्ण क्यों है।

अन्य संसाधन इस बारे में बेहतर तरीके से बात करते हैं, वास्तविक परियोजनाओं के लिए वास्तविक संख्या के साथ। मैं विकास संस्कृति के बारे में बात करना चाहता हूं और यह कैसे प्राथमिकताओं को परिभाषित करता है । केवल उत्पादकता को परियोजना के एक और "कार्य" के रूप में मानते हुए, हम सीखते हैं कि इस पर कैसे ध्यान दिया जाए।

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

रोजमर्रा के कार्यों को हल करते समय, आपको कई तकनीकी क्षेत्रों में काम करना होगा: नए कार्य विकसित करना, अन्य विभागों के साथ सहभागिता करना (एनालिटिक्स, विज्ञापन, रीमार्केटिंग, ए / बी परीक्षण के लिए स्क्रिप्ट जोड़ना), निरंतर एकीकरण और वितरण (सीआई / सीडी) व्यवस्थित करना, सुरक्षा सुनिश्चित करना एक अच्छी लग रही बनाने और इंटरफ़ेस का उपयोग करने के लिए आसान। लेकिन आपको अभी भी परीक्षणों के साथ रियर को कवर करने की आवश्यकता है!

किसी और चीज़ पर ध्यान देना लगभग असंभव है: समय सीमित है, और बकाया काम की मात्रा बढ़ने लगती है। इसलिए, आपको प्राथमिकता देनी होगी।



प्राथमिकता औसत दर्जे का परिकल्पना पर आधारित होना चाहिए। उदाहरण के लिए: "हम मानते हैं कि फ़ंक्शन एक्स के कार्यान्वयन के साथ, उपयोगकर्ता प्रतिधारण वाई% तक बढ़ जाएगा," हालांकि, व्यवहार में यह अधिक जटिल दिखता है। उन कार्यों पर एक नज़र डालें जिनसे हमें निपटना है और उन पर ध्यान देना है जो उन्हें सेट करते हैं:

• कार्यों का कार्यान्वयन । आमतौर पर, नए कार्यों को स्वामी या उत्पाद प्रबंधक द्वारा उनकी दृष्टि और टीम के लक्ष्य के अनुसार निर्धारित किया जाता है। एक फ़ंक्शन के लिए अनुरोध उन लोगों से आ सकता है जो हमारे काम पर निर्भर करते हैं (उदाहरण के लिए, ट्रैकिंग या ए / बी परीक्षण के लिए एक तृतीय-पक्ष स्क्रिप्ट जोड़ना)।
  
• संगठन CI / सीडी । डेवलपर्स विधानसभा और तैनाती के लिए अपनी खुद की पाइपलाइन बना सकते हैं, लेकिन सबसे अधिक संभावना है कि वे दूसरों द्वारा तैयार किए गए बुनियादी ढांचे का उपयोग करेंगे (उदाहरण के लिए, बुनियादी ढांचा विभाग)।
  
• सुरक्षा । यह बहुत अच्छा है अगर परियोजना में सुरक्षा में विशेषज्ञता वाला एक विभाग (या कम से कम एक व्यक्ति) है, जो सिस्टम की संरचना, कार्यों के कार्यान्वयन की जांच करने में मदद करता है, हमें सुरक्षा रिपोर्ट भेजता है और सुधारों के बारे में सूचित करता है।
  
• उपयोगकर्ता इंटरफ़ेस आमतौर पर, एक परियोजना में एक डिजाइनर और / या एक उपयोगकर्ता इंटरैक्शन विशेषज्ञ होता है जो उपस्थिति, प्रयोज्य और सूचना वास्तुकला के लिए जिम्मेदार होता है।
  
• परीक्षण । हम परीक्षण के बिना कहाँ हैं, है ना?
  

यदि कोई व्यक्ति किसी कार्य के लिए जिम्मेदार है, तो यह संभवतः कार्य मंडल पर पाया जाएगा। अधिकांश कार्य वर्कफ़्लो की कुछ भूमिकाओं के साथ सहसंबद्ध होते हैं, लेकिन कुछ ऐसे होते हैं, जो स्पष्ट रूप से डेवलपर्स को सौंपे जाते हैं - उदाहरण के लिए, परीक्षण: एक संपूर्ण के रूप में विकास विभाग इसके लिए ज़िम्मेदार होता है, और इसलिए कुछ घटकों का परीक्षण दूसरों की तुलना में बेहतर होता है।

शायद कोई भी यह तर्क नहीं देगा कि स्वचालित परीक्षण उपयोगी है। आमतौर पर, विकास विभाग खुद तय करता है कि परीक्षणों द्वारा कोड को बड़े पैमाने पर कैसे कवर किया जाता है - यह महत्वपूर्ण है कि टीम के सभी डेवलपर्स परीक्षण लिखने में सक्षम हों। इसी तरह की स्थिति प्रदर्शन के मुद्दों के साथ है: यह आमतौर पर माना जाता है कि डेवलपर्स को इससे निपटना चाहिए। मैंने देखा कि कोड के लिए परीक्षण लिखना और उसी समय के परिणामों को समझना जो एक टुकड़े के गलत संचालन को बढ़ावा देगा, उन सभी तत्वों को ध्यान में रखना आसान है जो वेब संसाधन को धीमा कर सकते हैं ।

वेब संसाधन प्रदर्शन के महत्व को लागू करने के लिए छह कदम

हमारे पास प्रदर्शन का विश्लेषण करने के लिए उपकरण हैं, लेकिन उनका उपयोग खुद डेवलपर्स पर निर्भर करता है। कंपनी में यह विचार कैसे लाया जाए कि उत्पादकता को कार्यों में से एक माना जाना चाहिए?

मैंने एक छह-बिंदु सूची तैयार की है जो इस मामले में मदद करनी चाहिए।

1. विकास पर्यावरण Development उपयोगकर्ता पर्यावरण

आसान काम , एमिल पेरोन द्वारा शूट किया गया

वेबसाइट के विकास के लिए, मैं एक मैकबुक प्रो का उपयोग करता हूं। मेरे पास एक फोन के रूप में एक iPhone X है, और मेरे पास एक अलग परीक्षण उपकरण है। इसके अलावा, मेरे पास बहुत तेज़ इंटरनेट कनेक्शन है, और मैं स्टॉकहोम और लंदन में डेटा केंद्रों के पास बैठा हूं। काम के बाद, मैं मेट्रो में जाता हूं, जहां 4 जी है (और कोई अंतराल नहीं है)। आमतौर पर, यह स्टॉकहोम में था कि 4 जी पहली बार दिखाई दिया - 2009 में वापस ।

उपयोगकर्ताओं के पास शायद ही कभी ऐसी सुरुचिपूर्ण परिस्थितियां होंगी (दुर्लभ अपवादों के साथ)।

यदि हमें स्वयं कोई प्रदर्शन समस्या नहीं है - तो अनुकूलन कार्य को प्राथमिकता कैसे दें? यह कीबोर्ड नियंत्रण, स्क्रीन रीडर का उपयोग किए बिना विकलांग लोगों के लिए एक इंटरफ़ेस को लागू करने और विपरीत रंगों की जांच करने की कोशिश करने जैसा है - यह एक बुरा काम है।

और आपको यहां परिवर्तनों के लिए इंतजार नहीं करना होगा: पश्चिमी वेब डेवलपर्स लैपटॉप और अन्य उपकरणों से नवीनतम चुनना पसंद करते हैं। वही लगभग सभी के बारे में कहा जा सकता है जो परियोजना और कंपनी के लिए लक्ष्य निर्धारित करने के लिए जिम्मेदार हैं। इसके अलावा, कुछ मामलों में, हम उपकरणों के ऊपरी खंड पर ध्यान केंद्रित करते हैं - क्योंकि उनका उपयोग उन लोगों द्वारा किया जाता है जो हमारे उत्पाद के लिए भुगतान करने के इच्छुक होने की अधिक संभावना रखते हैं। ब्रूस लॉसन ने इस विषय पर कहा कि हमें "दुनिया भर में नेटवर्क बनाना चाहिए, न कि अमीर पश्चिम के लिए नेटवर्क।"

सोचें कि क्या बेहतर है: अधिक उपयोगकर्ताओं को आकर्षित करने के लिए, भले ही वे कम विलायक हों , या कम हों, लेकिन अधिक विलायक।

दिलचस्प है, वास्तविक उपकरणों पर उपयोगकर्ताओं के काम को ध्यान में नहीं रखते हुए, हम गलत धारणा बनाते हैं । मान लीजिए कि हमने विकास को सुविधाजनक बनाने और उन प्लेटफार्मों को छोड़ने का फैसला किया, जिन पर सांख्यिकीय रूप से कम उपयोगकर्ता या कम उपयोग (उदाहरण के लिए, प्रति सत्र कम पृष्ठ दृश्य)। यह पुराने ब्राउज़र का समर्थन करने के लिए कोई मतलब नहीं है जो लगभग कभी भी किसी के द्वारा उपयोग नहीं किया जाता है । और कोई कह सकता है कि यह निर्णय ठोस आंकड़ों पर आधारित है।

लेकिन चलो जल्दी मत करो। लेकिन क्या होगा अगर किसी मंच पर कम प्रदर्शन इस तथ्य का परिणाम है कि उस पर हमारा उत्पाद असुविधाजनक या अप्रभावी है? यह परिकल्पना साबित करना मुश्किल है, क्योंकि डेवलपर्स कहेंगे कि उनके साथ सब कुछ ठीक है - उनके कंप्यूटर पर और एक विशिष्ट ब्राउज़र में (मान लीजिए कि यह Google क्रोम होगा)। हम अनजाने में हमारे द्वारा उपयोग किए जाने वाले ब्राउज़र पर अधिक ध्यान देते हैं, और परिणामस्वरूप, हम अक्सर अधिक आधुनिक कामकाजी वातावरण के पक्ष में समझौता करते हैं। ओह, मुझे मॉनिटर के दूसरी तरफ से दर्द का रोना सुनाई देता है: “फिर भी इस ब्राउज़र का उपयोग कर रहे हैं? उन्हें अपडेट किया जाए! ”

मुझे हाल ही में एक उद्धरण आया जो मुझे बहुत पसंद आया:

“जब मैंने Google में काम किया, तो किसी ने मुझे एक कहानी सुनाई कि कैसे उन्होंने कुछ बेहतरीन अनुकूलन पूरे किए, और अचानक यह पता चला कि पेज लोड होने का समय केवल बढ़ गया है। डेटा में देरी के बाद, हमने एक कारण खोजा: अनुकूलन के बाद, अफ्रीका से बहुत अधिक ट्रैफ़िक आना शुरू हुआ। पहले धीमी इंटरनेट के साथ उत्पाद का उपयोग करना असंभव था, और अनुकूलन के बाद यह संभव हो गया, और कमजोर कनेक्शन वाले उपयोगकर्ताओं की एक बड़ी संख्या दिखाई दी, जिससे औसत डाउनलोड समय में वृद्धि हुई। ”
- डैन लू, "सूजन इंटरनेट"

मैं दोहराता हूं: खराब प्रदर्शन और खराब आंकड़े देने वाले उपयोगकर्ताओं को छोड़कर उत्पादकता वृद्धि का अनुकरण करना आसान है। लेकिन यह अनुकूलन नहीं है, बल्कि संख्याओं के साथ एक गेम है ।

इसे स्वयं लें और परियोजना, पुराने उपकरणों पर काम करने वाले अपने सहयोगियों को वितरित करें। खराब कनेक्शन की स्थिति, धीमे प्रोसेसरों का अनुकरण करें - और अपने उत्पाद को इसके लिए अनुकूलित करें। पता लगाएं कि उपयोगकर्ताओं के पास क्या उपकरण हैं, और उन उपकरणों को प्राथमिकता दे रहे हैं जो वास्तव में आपकी साइट तक पहुंच रखते हैं, विशेष रूप से सतर्क रहें।

2. विशिष्ट पुस्तकालयों के बजाय प्रौद्योगिकी की मूल बातें सीखना बेहतर है

अब तक, कई रोजगार आवश्यकताओं और नौकरी के साक्षात्कार के सवालों ने अंतर्निहित प्रौद्योगिकियों के बजाय पुस्तकालयों पर ध्यान केंद्रित किया है। हालांकि यह पूछना अधिक सही होगा: “जब कोई ब्राउज़र किसी वेबसाइट को लोड करने की कोशिश करता है तो क्या होता है? किन कारणों से साइट बहुत देर तक लोड हो सकती है? आप गैर-तुच्छ आकार (क्लाइंट, सर्वर, डेटाबेस, कैशिंग) की एक वेब परियोजना की वास्तुकला को कैसे व्यवस्थित करेंगे? ”

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

शायद, परिणामस्वरूप, विभाग को एक विशेषज्ञ को नियुक्त करने की आवश्यकता होगी जो रिएक्ट या वीयू को जानता है, और तुरंत उसे काम में शामिल करता है और परियोजना को आगे बढ़ाता है। और साथ ही, नए कर्मचारियों के लिए कंपनी में लंबे समय तक रहना, मौजूदा तकनीकी समाधान पर सवाल उठाना और बेहतर विकल्प पेश करना अच्छा होगा।

वहाँ दो स्थिरांक हैं जो किसी डेवलपर के रूप में अपने कौशल को लागू करने पर मैं नहीं बदलते हैं:

1. किसी की अपनी कंपनी के निर्णयों पर सवाल उठाना आवश्यक है, अन्यथा एक प्रतियोगी ऐसा करेगा - और आगे आएगा। परियोजना के प्रतिभागियों से प्रतिक्रिया को प्रोत्साहित करें और उन्हें नवीन प्रोटोटाइप और पायलट संस्करणों को विकसित करने का समय दें।
   
2. आज अपनाया गया तकनीकी समाधान लंबे समय तक नहीं रहेगा। प्रतिरूपकता पर झुकना, घटकों को हटाने और तेजी से वितरण की संभावना।
   

यदि आप उपरोक्त से सहमत हैं, तो आप ऐसे लोगों के विचारों के लिए खुले हैं जो किसी विशेष तकनीक के लिए प्रतिबद्ध नहीं हैं और विभिन्न तकनीकी समाधानों के फायदे और नुकसान को सही ठहरा सकते हैं।

साक्षात्कार में भाग लें। एक तरफ समय निर्धारित करने की पेशकश करें जिसके दौरान कर्मचारी कुछ सीख सकते हैं (उदाहरण के लिए, आप नियमित रूप से दोपहर के भोजन के दौरान छोटी प्रस्तुतियां दे सकते हैं) और उन विचारों का पता लगा सकते हैं जो परियोजनाओं को लाभ पहुंचा सकते हैं।

3. प्रयोग और परीक्षण के लिए समय निकालें।

पहले, मैंने Google I / O जैसे सम्मेलनों में भाषणों के सहयोगियों को लिंक भेजा और सभी तरह की नई चीजों के बारे में बताने वाले लेख। यह मुझे मेरे और उनके लिए नवीनतम घटनाओं के बारे में पता लग रहा था।

आपके साथ दिलचस्प लिंक साझा करते हुए, आप अक्सर अपने सहयोगियों को और भी अधिक लोड करते हैं: उन्हें न केवल अपना काम करना पड़ता है, बल्कि यह भी पढ़ें कि आपने क्या भेजा है। यह माना जाता है कि अभ्यास में सीखना बेहतर है, जिससे उन्हें इस नए पुस्तकालय, तकनीक, विचार आदि को लागू करने की कोशिश करने की आवश्यकता होगी।

उन्हें एक एहसान करो - परियोजना में नवीनता को स्वयं लागू करें। "नया ब्राउज़र एपीआई शांत दिखता है" - मूल्यांकन के लिए गलत दृष्टिकोण। इस तरह से बहस करना बेहतर है: "यदि आप इस तरह से एक्स का उपयोग करते हैं, तो हमारी परियोजना बेहतर हो जाएगी ।" दूसरा, ज़ाहिर है, अधिक कठिन है, लेकिन इस मामले में वापसी अधिक है - और बॉस को समझाने में बहुत आसान होगा।

नेटवर्क पर कई केस स्टडी हैं कि प्रदर्शन अनुकूलन कैसे प्रमुख मैट्रिक्स में सुधार करता है। इस बारे में लेखों का एक अच्छा स्रोत - उदाहरण के लिए, डब्ल्यूपीओ आँकड़े की तरह।


कई केस स्टडीज जिसमें उत्पादकता में वृद्धि हुई है, प्रमुख प्रदर्शन संकेतकों में सुधार हुआ है।

कभी-कभी, किसी कंपनी को किसी वेब प्रोजेक्ट की गति पर अधिक ध्यान देने के लिए, किसी का व्यावहारिक शोध साक्ष्य के रूप में पर्याप्त नहीं होता है।

एक प्रोटोटाइप की आवश्यकता है। लेकिन ऐसा लग सकता है कि इसके निर्माण के लिए कोई समय नहीं है और कभी नहीं होगा: सब कुछ त्रुटियों को ठीक करने और नए कार्यों को जोड़ने पर खर्च किया जाता है।

मेरी राय में, हर समारोह को तीन चरणों से गुजरना चाहिए:



विचार मालिक या उत्पाद के प्रबंधक से आ सकता है, लेकिन यह डेवलपर से भी आ सकता है । यह परीक्षण करना और यह दिखाना आवश्यक है कि यह काम करता है - इसके लिए हमें एक प्रोटोटाइप की आवश्यकता है। इसके बाद ही फंक्शन को साकार किया जा सकेगा। इसके अलावा, इसका मतलब है कि विचार के कार्यान्वयन से पहले किसी न किसी रूप में परीक्षण किया जाना चाहिए। यह साबित करना आवश्यक होगा कि साइट के प्रदर्शन को बेहतर बनाने से प्रदर्शन में सुधार होता है - लेकिन यह अन्य कार्यों पर भी लागू होता है।

जब त्वरित किया जा सकता है, तो खोज करें कि उपयोगकर्ता क्या अनुभव कर सकते हैं। ताकि उपयोगकर्ता समय की स्वीकार्य अवधि में अंतर को नोटिस कर सकें, साइट की गति कम से कम 20% बढ़नी चाहिए , और बेहतर - सभी 30% तक ।

4. ट्रेन के सहकर्मी

क्या आपके साथ कभी ऐसा हुआ है कि आपको किसी कोड को हटाना या बदलना पड़ा क्योंकि किसी को समझ नहीं आया कि यह कैसे काम करता है? शायद यह कटोरा किसी ने पास नहीं किया। यदि कोड को केवल उसके लेखक द्वारा समझा और समर्थित किया जाता है, तो यह क्या होगा यदि यह व्यक्ति छुट्टी पर जाता है, बीमार हो जाता है, कंपनी छोड़ देता है ..?


हम जॉन की अनुपस्थिति का लाभ उठाते हैं - हमें अनावश्यक जटिलता से छुटकारा मिलता है।

हम में से अधिकांश एक टीम के रूप में काम करते हैं, इसलिए समाधान चुनते समय आपको उन लोगों पर ध्यान केंद्रित करने की आवश्यकता होती है जिन्हें अधिकांश सहयोगियों द्वारा समझा जाएगा। टीम में "सबसे छोटे सामान्य एकाधिक" को परिभाषित करें और कोशिश करें कि अधिक जटिल समाधानों का उपयोग न करें क्योंकि यह गड़बड़ करने के लिए मजेदार है । प्रदर्शन अनुकूलन में, कभी-कभी जटिलता में अत्यधिक वृद्धि से एक छोटा लाभ प्राप्त होता है।

कुछ महीने पहले मैंने छवि अनुकूलन के बारे में लिखा था और स्पष्ट डाउनलोड गति में सुधार कैसे किया जाए । मैंने स्पष्ट: कम प्रश्नों के साथ शुरुआत की, सही प्रारूप चुनें, छवियों का अनुकूलन करें। हालांकि, अधिकांश को केवल प्लेसहोल्डर छवियों का उपयोग याद है, जो आपको वांछित तस्वीर को एक चिकनी संक्रमण बनाने की अनुमति देता है।


छवि अपलोड करने से पहले आप जो दिखा सकते हैं उसके लिए विकल्प।

यह सबसे दिलचस्प और अभिनव हिस्सा है! सच तो यह है? अब अपने सहकर्मियों को यह बताने का प्रयास करें कि आप एक बैकएंड सेवा बनाने जा रहे हैं, जो कतारबद्ध चित्रों को संसाधित करेगी और एक छोटा स्केच संग्रहित करेगी, जो रेंडर करते समय पृष्ठ में एम्बेड किया जाएगा। कब होगी आग? इसमें कितना समय लगेगा? रेखाचित्र कहाँ संग्रहीत करें? विभिन्न सर्वरों पर इस सेवा को कैसे बढ़ाया जाए?

यह छवि वितरण से बचने और उन लोगों को अनुकूलित करने के लिए सबसे प्रभावी है जिन्हें अभी भी वितरित किया जाना है - यही वह है जिसके लिए आपको प्रयास करना चाहिए।

अधिकांश सहयोगियों के लिए समझ में आने वाले "अच्छे पर्याप्त" समाधानों को चुनने के अलावा, आपको विभाग में ज्ञान का स्तर बढ़ाने के बारे में सोचना चाहिए । क्या आपको एक विशिष्ट क्षेत्र में डॉक माना जाता है? अपने सहयोगियों के सामने एक प्रस्तुति दें और उन्हें एक नए विचार के साथ प्रेरित करें।

आखिरकार, यदि आप केवल एक निश्चित विचार को बढ़ावा देते हैं, तो यह लंबे समय तक नहीं रहेगा।

5. शेयर सफलता की कहानियां (और असफलताएं)

कंपनी में सोचने के तरीके को बदलने के लिए, आपको पहले नए दृष्टिकोण के अपने सहयोगियों को समझाना होगा। लेकिन आपको अपने विभाग के बाहर अपने प्रयोगों के परिणामों को साझा करने की आवश्यकता है।

कंपनी-व्यापी आधार पर, यह अन्य कर्मचारियों को प्रेरित करने और अधिक महत्वाकांक्षी उपक्रमों के लिए रास्ता खोलने में मदद करेगा । और सही सेवाओं और बुनियादी ढांचे के लिए समर्थन प्राप्त करना आसान होगा यदि कई विभाग आवश्यक पाते हैं।

- , .

-, Etsy. :

« « », , : , , , ».
— , « »

.

, , , .


Etsy

, , . Vox Media — , The Verge . 2015 . Vox Media , .

« . — . ».
— Vox Media, « » ( )

SpeedCurve , The Verge Vox Media ( )

Vox Media ( , ) , .


Vox Media .

: ( ), . , , .

6.

— ́ , -.

, : WebPagetest , Pagespeed Insights , Audits Chrome . .


WebPagetest — .

, , , .

, , . — .

— . . , ( , , . .).

RUM-, . , , , - , .

, , — Google Analytics , — : , Calibre , SpeedCurve SiteSpeed .

, .

— . (, SiteSpeed) , . , .

- Caliber . « », - . :

• . , ( , ) .
  
• . , , , , . , , , , .
  
• . , , : « - », « Caliber», «», «» « ». , , — : .
  

? , .

1. , .
   
2. . — .
   
3. — , , .
   
4. , , , .
   
5. उपकरण प्रदर्शन संकेतकों की कल्पना करने और उनके परिवर्तन को दिखाने में सक्षम था, जो तब काम आया जब हमने कंपनी के अन्य वेब डेवलपर्स के साथ अपने अनुभव को साझा करने का फैसला किया। इस तरह के उपकरण प्रदर्शन संकेतक पर प्रतिबंध लगाना आवश्यक बनाते हैं, जिससे अधिक कोड अस्वीकार किए जाने के परिवर्तनों के अनुरोधों का कारण होगा (या केवल सूचनाएं आएंगी)।
   
6. प्रस्तावित टूल को वर्कफ़्लो में शामिल किया गया था और यह हमारी ओर से प्रयास किए बिना काम कर सकता था - अन्य कार्यों से संसाधन लेना आवश्यक नहीं था।
   

निष्कर्ष

मैंने और अधिक संवेदनशील साइट बनाने के बारे में कुछ सुझाव देने की कोशिश की - मुझे आशा है कि मैं सफल रहा। आपका ध्यान के लिए धन्यवाद!

अनुवादक के बारे में

लेख का अनुवाद अल्कोनोस्ट ने किया था।

Alconost 68 भाषाओं में खेल , एप्लिकेशन और साइटों को स्थानीय करता है। मूल भाषा के अनुवादक, भाषाई परीक्षण, एपीआई के साथ क्लाउड प्लेटफ़ॉर्म, निरंतर स्थानीयकरण, परियोजना प्रबंधक 24/7, स्ट्रिंग संसाधनों का कोई भी प्रारूप।

हम विज्ञापन और प्रशिक्षण वीडियो भी बनाते हैं - Google Play और ऐप स्टोर के लिए बिक्री, छवि, विज्ञापन, प्रशिक्षण, टीज़र, खोजकर्ता, ट्रेलरों के लिए।

अधिक जानकारी