היכן פרוקסי דחיסה יכול לחסוך רוחב פס
הצבו את הפחתת התוכן לפני קישור הלקוח המוגבל והביאו בחשבון איכות תמונה, דחיסה קיימת ונראות 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 קובעת טיפול תואם בתוכן; היא נפרדת מהצפנת התעבורה. העריכו את התועלת לפי התוכן בפועל ולפי נתיב ההצפנה, ולא לפי הדגמה ישנה של תמונות בטקסט גלוי.