जिम्मेदार डेवलपर के लिए HTTP शीर्ष लेख

आज, कई लोगों के लिए ऑनलाइन होना एक सामान्य स्थिति है। हम सभी विभिन्न विषयों पर जानकारी के लिए लेख खरीदते हैं, संवाद करते हैं, पढ़ते हैं। नेटवर्क हमें पूरी दुनिया से जोड़ता है, लेकिन सबसे ऊपर, यह लोगों को जोड़ता है। मैं खुद 20 साल से इंटरनेट का उपयोग कर रहा हूं, और इसके साथ मेरा संबंध आठ साल पहले बदल गया जब मैं एक वेब डेवलपर बन गया।

डेवलपर्स लोगों को जोड़ते हैं।
डेवलपर्स लोगों की मदद करते हैं।
डेवलपर्स लोगों को अवसर देते हैं।

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

HTTP - हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल

पहले HTTP की बात करते हैं। HTTP एक प्रोटोकॉल है जिसका उपयोग इंटरनेट पर डेटा का अनुरोध करने और भेजने के लिए किया जाता है।

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

सर्वर अनुरोधित संसाधन के साथ प्रतिक्रिया करता है, लेकिन संसाधन या सर्वर के बारे में जानकारी युक्त प्रतिक्रिया हेडर भी भेजता है।

Request: GET https://the-responsible.dev/ Accept: text/html,application/xhtml+xml,application/xml Accept-Encoding: gzip, deflate, br Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,de;q=0.7 ... Response: Connection: keep-alive Content-Type: text/html; charset=utf-8 Date: Mon, 11 Mar 2019 12:59:38 GMT ... Response Body 

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

नेटवर्क सुरक्षित होना चाहिए

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

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

क्या इन सभी लोगों और सभी स्रोत कोड पर भरोसा किया जा सकता है?

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

यदि आप विश्लेषण करना चाहते हैं कि आपकी साइट पर थर्ड-पार्टी कोड कितना चलता है, तो आप डेवलपर पैनल में देख सकते हैं या रिक्वेस्ट मैप जेनरेटर आज़मा सकते हैं ।

HTTPS और HSTS - सुनिश्चित करें कि आपका कनेक्शन सुरक्षित है

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

सौभाग्य से, आज टीएलएस प्रमाणपत्र मुफ्त हैं ; HTTPS मानक बन गया है, और ब्राउज़र केवल सुरक्षित कनेक्शन के लिए उन्नत सुविधाएँ प्रदान करते हैं, और यहां तक ​​कि गैर-HTTPS वेबसाइटों को असुरक्षित के रूप में चिह्नित करते हैं, जो इस प्रोटोकॉल के कार्यान्वयन की सुविधा प्रदान करता है। दुर्भाग्य से, हम हमेशा सुरक्षित नहीं होते हैं जब हम इंटरनेट पर होते हैं। जब कोई साइट खोलना चाहता है, तो वह प्रोटोकॉल को एड्रेस बार में दर्ज नहीं करता है (और उसे क्यों करना चाहिए?)। इसका परिणाम अनएन्क्रिप्टेड HTTP अनुरोध में होता है। सुरक्षित रूप से चलने वाली साइटें उपयोगकर्ता को HTTPS पर पुनर्निर्देशित करती हैं। लेकिन क्या होगा अगर कोई पहली असुरक्षित अनुरोध स्वीकार करता है?

आप ब्राउज़र को बताने के लिए HSTS (HTTP स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी) रिस्पॉन्स हेडर का उपयोग कर सकते हैं कि आपकी साइट केवल HTTPS के माध्यम से काम करती है।

 Strict-Transport-Security: max-age=1000; includeSubDomains; preload 

यह शीर्षलेख उस ब्राउज़र को बताता है जिसे आप HTTP अनुरोधों का उपयोग नहीं करना चाहते हैं, और फिर यह एक ही स्रोत के लिए एक ही कनेक्शन के साथ एक ही अनुरोध को स्वचालित रूप से लागू करेगा। यदि आप HTTP के माध्यम से एक ही URL खोलने का प्रयास करते हैं, तो ब्राउज़र फिर से HTTPS का उपयोग करेगा और उपयोगकर्ता को पुनर्निर्देशित करेगा।

आप कॉन्फ़िगर कर सकते हैं कि यह विकल्प कितने समय तक सक्रिय रहना चाहिए (सेकंड में max-age ) यदि आप बाद में फिर से HTTP का उपयोग करना चाहते हैं। यदि आप उप-डोमेन को सक्षम करना चाहते हैं, तो आप इसे शामिल कर सकते हैं कॉन्फ़िगर कर सकते हैं includeSubDomains ।

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

क्या आपने कभी सोचा है कि आप HTTP के माध्यम से अपने ब्राउज़र में my-site.dev जैसे स्थानीय पर्यावरण चर का उपयोग क्यों नहीं कर सकते? इस आंतरिक सूची में इसका कारण ठीक है - .dev इस सूची में स्वचालित रूप से शामिल .dev , क्योंकि फरवरी 2019 में यह एक वास्तविक शीर्ष-स्तरीय डोमेन बन गया।

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

CSP - स्पष्ट रूप से इंगित करें कि आपकी साइट पर क्या अनुमति है

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

 Content-Security-Policy: upgrade-insecure-requests 

upgrade-insecure-requests सूचक ब्राउज़र को HTTP के सभी अनुरोधों को HTTPS अनुरोधों में जादुई रूप से परिवर्तित करने का कारण बनता है।

हालाँकि, CSP उपयोग किए गए प्रोटोकॉल तक सीमित नहीं है। यह निर्धारित करने के लिए विस्तृत तरीके प्रदान करता है कि आपकी साइट पर किन संसाधनों और गतिविधियों की अनुमति है। उदाहरण के लिए, आप यह निर्दिष्ट कर सकते हैं कि कौन सी स्क्रिप्ट निष्पादित होनी चाहिए या कहाँ से चित्र डाउनलोड करना चाहिए। यदि कुछ की अनुमति नहीं है, तो ब्राउज़र इस कार्रवाई को रोकता है और आपकी साइट पर संभावित हमलों को रोकता है।



लेखन के समय, सीएसपी के लिए 24 विभिन्न विन्यास विकल्प थे। वे शैली पत्रक से लेकर सेवा कार्यकर्ताओं तक लिपियों से लेकर हैं।



आप MDN पर पूर्ण समीक्षा पा सकते हैं ।

CSP का उपयोग करके, आप यह निर्दिष्ट कर सकते हैं कि आपकी साइट में क्या शामिल होना चाहिए और क्या नहीं होना चाहिए।

 Content-Security-Policy: default-src 'self'; script-src 'self' just-comments.com www.google-analytics.com production-assets.codepen.io storage.googleapis.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: images.contentful.com images.ctfassets.net www.gravatar.com www.google-analytics.com just-comments.com; font-src 'self' data:; connect-src 'self' cdn.contentful.com images.contentful.com videos.contentful.com images.ctfassets.net videos.ctfassets.net service.just-comments.com www.google-analytics.com; media-src 'self' videos.contentful.com videos.ctfassets.net; object-src 'self'; frame-src codepen.io; frame-ancestors 'self'; worker-src 'self'; block-all-mixed-content; manifest-src 'self' 'self'; disown-opener; prefetch-src 'self' 

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

अपनी साइट को हैक करने से बचने के लिए, CSP केवल रिपोर्टिंग मोड प्रदान करता है।

 Content-Security-Policy-Report-Only: default-src 'self'; ... report-uri https://stefanjudis.report-uri.com/r/d/csp/reportOnly 

Content-Security-Policy-Report-Only मोड का उपयोग करते हुए, ब्राउज़र केवल उन संसाधनों को रिकॉर्ड करते हैं जो वास्तव में अवरुद्ध करने के बजाय, अवरुद्ध हो जाएंगे। यह रिपोर्टिंग तंत्र आपको अपने नियम सेट को सत्यापित और कॉन्फ़िगर करने की अनुमति देता है।

Content-Security-Policy और Content-Security-Policy-Report-Only भी उल्लंघन report-uri भेजने और सूचना ( report-uri ) लॉग करने के लिए समापन बिंदु निर्धारित करने का एक तरीका प्रदान करते हैं। आप लॉग सर्वर को कॉन्फ़िगर कर सकते हैं और भेजे गए लॉग जानकारी का उपयोग सीएसपी नियमों को कॉन्फ़िगर करने के लिए कर सकते हैं जब तक कि यह भेजने के लिए तैयार न हो।

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

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

CSP का सामान्य कार्यान्वयन

आज ब्राउज़र सीएसपी का अच्छी तरह से समर्थन करते हैं , लेकिन दुर्भाग्य से कई साइट इसका उपयोग नहीं करती हैं। यह देखने के लिए कि कितनी साइटें CSP का उपयोग करके सामग्री वितरित करती हैं, मैंने HTTParchive को एक अनुरोध भेजा और पाया कि केवल 6% साइटें इस नीति का उपयोग करती हैं। मुझे लगता है कि हम इंटरनेट को अधिक सुरक्षित बना सकते हैं और अपने उपयोगकर्ताओं को अनजाने खनन क्रिप्टोकरेंसी से बचा सकते हैं ।

नेटवर्क सुलभ होना चाहिए।

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

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

कैश-कंट्रोल - अपरिवर्तनीय संसाधनों के लिए अनुरोध से बचें

आज एक साइट में सीएसएस से लेकर स्क्रिप्ट और चित्र तक सैकड़ों संसाधन हो सकते हैं। Cache-Control , डेवलपर्स निर्दिष्ट कर सकते हैं कि संसाधन को कितने समय तक "ताजा" माना जाना चाहिए और ब्राउज़र कैश से वापस किया जा सकता है।

 Cache-Control: max-age=30, public 

Cache-Control उचित कॉन्फ़िगरेशन के साथ, डेटा ट्रांसफर संरक्षित है और एक निश्चित संख्या ( max-age ) के लिए फ़ाइलों को ब्राउज़र कैश से उपयोग किया जा सकता है। इस अवधि के बाद ब्राउज़रों को कैश्ड संसाधनों की फिर से जाँच करनी चाहिए।

हालाँकि, यदि आगंतुक पृष्ठ को ताज़ा करते हैं, तो ब्राउज़र इसे वैसे भी फिर से जाँच लेंगे, जिसमें संसाधनों के लिंक भी शामिल हैं ताकि यह सुनिश्चित हो सके कि कैश्ड डेटा अभी भी मान्य है। सर्वर एक हेडर 304 के साथ प्रतिक्रिया करता है, यह दर्शाता है कि कैश्ड डेटा अभी भी मान्य है, या अपडेट किए गए डेटा को प्रसारित करते समय हेडर 200 है। यह आपको स्थानांतरित किए गए डेटा को बचाने की अनुमति देता है, लेकिन जरूरी अनुरोध नहीं किया गया है।

यह वह जगह है जहाँ immutable फ़ंक्शन खेल में आता है।

अपरिवर्तनीय - दो बार संसाधन का अनुरोध न करें

आधुनिक सीमांत अनुप्रयोगों में, CSS और स्क्रिप्ट फ़ाइलों में आमतौर पर विशिष्ट नाम होते हैं, उदाहरण के लिए, styles.123abc.css । इस फ़ाइल का नाम सामग्री पर निर्भर करता है। और जब आप फ़ाइलों की सामग्री बदलते हैं, तो उनके नाम भी बदल जाते हैं।

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

 Cache-Control: max-age=31536000, public, immutable 

इष्टतम कैशिंग को लागू करना बहुत मुश्किल है, और विशेष रूप से ब्राउज़र कैशिंग बहुत सहज नहीं है, क्योंकि इसमें विभिन्न कॉन्फ़िगरेशन हैं। मेरा सुझाव है कि आप निम्नलिखित सामग्री पढ़ें:

• हैरी रॉबर्ट्स ने आपके कैश और इसकी सेटिंग्स को प्रबंधित करने के लिए एक उत्कृष्ट गाइड लिखा है।
  
• जैक आर्किबाल्ड ने चित्रण के साथ सर्वश्रेष्ठ कैशिंग तकनीकों पर सुझाव दिए।
  
• इल्या ग्रिगोरिक ने कैशिंग हेडर के लिए एक उत्कृष्ट तकनीकी योजना प्रस्तावित की।
  

स्वीकार-एन्कोडिंग - अधिकतम संपीड़न (न्यूनतम करने के लिए)

Cache control की मदद से Cache control हम अनुरोधों को सहेज सकते हैं और नेटवर्क पर बार-बार प्रसारित होने वाले डेटा की मात्रा को कम कर सकते हैं। हम न केवल अनुरोधों को बचा सकते हैं, बल्कि जो भी संचारित है, उसे कम कर सकते हैं।

संसाधन देते हुए, डेवलपर्स को यथासंभव कम डेटा भेजने का ध्यान रखना चाहिए। HTML, CSS और JavaScript जैसे टेक्स्ट संसाधनों के लिए, ट्रांसफ़र किए गए डेटा को सहेजने में संपीड़न एक महत्वपूर्ण भूमिका निभाता है।

आज सबसे लोकप्रिय संपीड़न विधि GZIP है। सर्वर में मक्खी पर पाठ फ़ाइलों को संपीड़ित करने और अनुरोध करने पर संपीड़ित डेटा प्रदान करने की पर्याप्त शक्ति होती है। लेकिन GZIP अब सबसे अच्छा विकल्प नहीं है।

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

 Accept-Encoding: gzip, deflate, br 

यह हेडर सर्वर को बताता है कि कौन सा कंप्रेशन एल्गोरिदम इसे समझता है। थोड़ा ज्ञात br पैरामीटर ब्रेटली संपीड़न के लिए खड़ा है और इसका उपयोग Google और फेसबुक जैसी उच्च-ट्रैफ़िक साइटों पर किया जाता है। Brotli का उपयोग करने के लिए, आपकी साइट को HTTPS के माध्यम से काम करना चाहिए।

इस संपीड़न एल्गोरिदम को छोटे फ़ाइल आकार को ध्यान में रखते हुए बनाया गया था। यदि आप फ़ाइल को अपने स्थानीय डिवाइस पर मैन्युअल रूप से संपीड़ित करने का प्रयास करते हैं, तो आप पाएंगे कि ब्रेटली वास्तव में GZIP से बेहतर संपीड़ित करता है।



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

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

यदि आप ब्रेटली संपीड़न और GZIP के साथ इसकी तुलना के बारे में अधिक पढ़ना चाहते हैं, तो अकामाई कर्मचारियों ने इस विषय पर व्यापक शोध किया है ।

स्वीकार करें और स्वीकार करें- CH - उपयोगकर्ता के लिए व्यक्तिगत संसाधन परोसें

किलोबाइट को बचाने के लिए पाठ संसाधनों का अनुकूलन बहुत महत्वपूर्ण है, लेकिन इससे भी अधिक डेटा बचाने के लिए छवियों जैसे भारी संसाधनों का क्या?

स्वीकार करें - सही प्रारूप में छवियों की सेवा

ब्राउज़र न केवल हमें दिखाते हैं कि कौन सा संपीड़न एल्गोरिदम वे समझते हैं। जब ब्राउज़र एक छवि का अनुरोध करता है, तो यह इस बारे में भी जानकारी प्रदान करता है कि यह किस फ़ाइल प्रारूप को समझता है।

 Accept: image/webp, image/apng, image/*,*/*;q=0.8 

कई वर्षों तक, एक नए छवि प्रारूप के आसपास संघर्ष किया गया, लेकिन वेबप जीता। वेबप Google द्वारा आविष्कार किया गया एक छवि प्रारूप है , और इस प्रारूप के लिए समर्थन अब बहुत प्रासंगिक है।

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

स्वीकार-सीएच - छवियों की सेवा का सही आकार

आप इस सुविधा का समर्थन करने वाले ब्राउज़रों के लिए क्लाइंट प्रॉम्प्ट को भी सक्षम कर सकते हैं। क्लाइंट संकेत ब्राउज़र को देखने का क्षेत्र, छवि की चौड़ाई, और यहां तक ​​कि नेटवर्क की स्थिति, जैसे आरटीटी (ट्रांसमिशन और पुष्टि समय) और कनेक्शन के प्रकार के बारे में अतिरिक्त जानकारी भेजने का एक तरीका है, उदाहरण के लिए 2g ।

आप मेटा तत्व को जोड़कर संकेत सक्रिय कर सकते हैं:

 <meta http-equiv="Accept-CH" content="Viewport-Width, Downlink"> <meta http-equiv="Accept-CH-Lifetime" content="86400"> 

या मूल HTML अनुरोध में हेडर सेट करके:

 Accept-CH: Width, Viewport-Width Accept-CH-Lifetime: 100 

बाद के अनुरोधों में, ब्राउज़र एक निश्चित अवधि के लिए अतिरिक्त जानकारी भेजना शुरू कर देगा (सेकेंड Accept-CH-Lifetime सेकंड में), जो डेवलपर्स को HTML बदलने के बिना उपयोगकर्ता की स्थिति में छवियों को अनुकूलित करने में मदद कर सकता है।

उदाहरण के लिए, अधिक जानकारी के लिए, जैसे कि सर्वर साइड पर छवि की चौड़ाई, आप अपनी छवियों को ब्राउज़र की अतिरिक्त जानकारी देने के लिए sizes विशेषता के साथ प्रदान कर सकते हैं कि ये चित्र कैसे दिखेंगे।

 <!-- this images is laid over the full width | 100 viewport width --> <img class="w-100" src="/img/header.jpg" alt="" sizes="100vw"> 

Accept-CH रिस्पांस हेडर प्राप्त किया और आकृतियों की विशेषताओं के साथ छवियां, ब्राउज़र में छवि अनुरोधों में viewport-width और width हेडर शामिल होंगे, जो आपको दिखाएगा कि कौन सी छवि सबसे उपयुक्त है।



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

 <pictur> <!-- serve WebP to Chrome, Edge, Firefox and Opera --> <source media="(min-width: 50em)" sizes="50vw" srcset="/image/thing-200.webp 200w, /image/thing-400.webp 400w, /image/thing-800.webp 800w, /image/thing-1200.webp 1200w, /image/thing-1600.webp 1600w, /image/thing-2000.webp 2000w" type="image/webp"> <source sizes="(min-width: 30em) 100vw" srcset="/image/thing-crop-200.webp 200w, /image/thing-crop-400.webp 400w, /image/thing-crop-800.webp 800w, /image/thing-crop-1200.webp 1200w, /image/thing-crop-1600.webp 1600w, /image/thing-crop-2000.webp 2000w" type="image/webp"> <!-- serve JPEG to others --> <surce media="(min-width: 50em)" sizes="50vw" srcset="/image/thing-200.jpg 200w, /image/thing-400.jpg 400w, /image/thing-800.jpg 800w, /image/thing-1200.jpg 1200w, /image/thing-1600.jpg 1600w, /image/thing-2000.jpg 2000w"> <surce sizes="(min-width: 30em) 100vw" srcset="/image/thing-crop-200.jpg 200w, /image/thing-crop-400.jpg 400w, /image/thing-crop-800.jpg 800w, /image/thing-crop-1200.jpg 1200w, /image/thing-crop-1600.jpg 1600w, /image/thing-crop-2000.jpg 2000w"> <!-- fallback for browsers that don't support picture --> <img src="/image/thing.jpg" width="50%"> </pictur> 

यदि आपके पास व्यूपोर्ट और छवि के आकार की चौड़ाई तक पहुंच है, तो आप अपने सर्वर पर सबसे आगे रिसोर्सेस रिसोर्स का तर्क रख सकते हैं।

हालाँकि, ध्यान रखें कि आपको किसी भी चौड़ाई के लिए चित्र नहीं बनाना चाहिए क्योंकि आपके पास छवि की सटीक चौड़ाई है। एक विशिष्ट आकार सीमा ( image-200 , image-300 , ... ) के लिए छवियां भेजना CDN कैशिंग का उपयोग करने में मदद करता है और गणना समय बचाता है।

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

यदि आप क्लाइंट टिप्स के बारे में अधिक विस्तृत जानकारी की तलाश में हैं, तो आप इस विषय पर जेरेमी वैगनर या इल्या ग्रिगोरिक के लेख पढ़ सकते हैं।

नेटवर्क से सावधान रहना चाहिए

चूंकि हम में से प्रत्येक दिन नेटवर्क पर कई घंटे बिताते हैं, इसलिए अंतिम पहलू है जिसे मैं बहुत महत्वपूर्ण मानता हूं - नेटवर्क को सावधान रहना चाहिए।

प्रीलोड - प्रतीक्षा समय कम करें

डेवलपर्स के रूप में, हम अपने उपयोगकर्ताओं के समय को महत्व देते हैं। कोई भी समय बर्बाद नहीं करना चाहता है। , . , , .

: , , . , HTML . , , . .

Rel=preload , .

HTML-:

 <link rel="preload" href="/font.woff2" as="font" type="font/woff2" crossorigin="anonymous"> 

:

 Link: </font.woff2>; rel=preload; as=font; no-push 

, , , , . .

:

• , .
  
• preload , prefetch preconnect.
  

Feature-Policy —

, . .

. , . . , , — .

, , ? , ?

Feature-Policy. , , , , .

 Feature-Policy: vibrate 'none'; geolocation 'none' 

. , , , .

 <iframe allow="camera 'none'; microphone 'none'"> 

Feature-Policy , , , . , . .



MDN.

, — push-. , Feature-Policy push- , . , GitHub.

feature policy , , , , .

, . , «HTTP- — » .

, — . , , , … . , , , -, , - .