संकुचन प्रॉक्सी कुठे बँडविड्थ वाचवू शकतो
मर्यादित क्लायंट लिंकच्या आधी सामग्री कपात ठेवा आणि प्रतिमा गुणवत्ता, विद्यमान संकुचन तसेच HTTPS दृश्यता विचारात घ्या.
प्रतिसाद मार्गावरील मर्यादित लिंकच्या आधी सामग्री कपात ठेवा:
website → proxy transforms response → slow or metered link → browser
जर संपूर्ण बॉडी आधीच त्या लिंकमधून गेली असेल, तर नंतर ती लहान केल्याने ते बाइट परत मिळत नाहीत. वेगवान अपस्ट्रीम असलेला दूरचा रूपांतरक ब्राउझरजवळील स्थानिक प्रॉक्सीपेक्षा वेगळा उद्देश पूर्ण करू शकतो.
Ziproxy हा दृष्टिकोन दाखवतो: त्याचा प्रकल्प कॅशिंग न करणाऱ्या HTTP प्रॉक्सीचे वर्णन करतो जी मजकुरासारखी सामग्री gzip करते आणि लहान, कमी गुणवत्तेच्या प्रतिमा तयार करू शकते.
| प्रतिसाद मार्ग | संभाव्य घट |
|---|---|
| gzip एन्कोडिंग | हानीरहित; ब्राउझर मूळ डेटा डीकोड करतो |
| प्रतिमांचे पुन्हा संकुचन | तपशील सोडू शकते आणि अचूक प्रतिमा महत्त्वाच्या असताना अयोग्य ठरू शकते |
| आधीच कार्यक्षमतेने संकुचित सामग्री | अधिक घटीसाठी कमी जागा |
| सामान्य HTTPS CONNECT | अपारदर्शक TLS दुसऱ्या विश्वासार्ह स्पष्ट-मजकूर प्रवेश व्यवस्थेशिवाय HTML किंवा प्रतिमा रूपांतरण रोखते |
प्रक्रिया आणि अतिरिक्त हॉपलाही वेळ लागतो, त्यामुळे कमी बाइट वेगवान पूर्ततेची हमी देत नाहीत. कॅश पात्र साठवलेला प्रतिसाद पुन्हा वापरते; संकुचन नव्याने मिळवलेला प्रतिसाद न साठवता रूपांतरित करू शकते.
HTTP सामग्री दिसणाऱ्या ठिकाणी Cache-Control: no-transform पाळा. no-transform प्रतिसाद धोरण अनुरूप सामग्री हाताळणी नियंत्रित करते; ते वाहतूक एन्क्रिप्शनपासून वेगळे आहे. फायदे प्रत्यक्ष सामग्री आणि एन्क्रिप्शन मार्गावरून अंदाजा, जुन्या स्पष्ट-मजकूर प्रतिमा प्रात्यक्षिकावरून नाही.