כל בייט שהשרת שלך שולח עולה זמן. בחיבור מהיר זה כמעט לא מורגש. ברשת סלולרית, או כשהשרת מטפל במאות בקשות במקביל, הבייטים האלה מצטברים מהר. דחיסת Gzip היא אחת מהשיפורים הפשוטים ביותר בצד השרת, ו-Nginx נותן לך שליטה מדויקת על איך זה עובד.
רוב התקנות Nginx המוגדרות כברירת מחדל מגיעות עם gzip כבוי או כמעט לא מוגדר. להגדיר את זה נכון לוקח כעשר דקות, והתוצאות מופיעות מיד בגודל התגובות ובזמן עד הבייט הראשון. ראינו דפי HTML שמתכווצים ב-70-80% וקבצי JavaScript שמצטמצמים לשליש מגודלם המקורי - רק בזכות הגדרת gzip תקינה.
איך דחיסת Gzip ב-Nginx עובדת בפועל
כשדפדפן שולח בקשה, הוא מצרף כותרת Accept-Encoding: gzip, deflate, br. זה אומר לשרת שהוא יכול לטפל בתגובות דחוסות. Nginx בודק את הכותרת הזו, ואם gzip מופעל, הוא דוחס את גוף התגובה לפני השליחה. הדפדפן פורס את הנתונים בצורה שקופה. קוד האפליקציה שלך לא משתנה כלל.
הפשרה המרכזית היא בין זמן CPU לבין רוחב פס. הדחיסה דורשת כמות קטנה של כוח עיבוד בצד השרת. עבור רוב האתרים, זה רווחי - החיסכון ברוחב הפס גדול בהרבה מעלות ה-CPU, במיוחד בתגובות עשירות בטקסט. היוצא מן הכלל הוא קבצים שכבר דחוסים, כמו תמונות JPEG, ארכיוני ZIP, או סרטוני MP4. לנסות לדחוס אותם ב-gzip רק מבזבז CPU ובקושי מקטין את הקובץ.
בלוק הגדרות ה-Gzip הבסיסי ב-Nginx
כל הגדרות ה-gzip נמצאות בקובץ nginx.conf, בדרך כלל בבלוק http כדי שיחולו באופן גלובלי. הנה הגדרת התחלה טובה:
http { gzip on; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_min_length 256; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css text/xml text/javascript application/json application/javascript application/x-javascript application/xml application/xml+rss application/atom+xml image/svg+xml font/truetype font/opentype application/vnd.ms-fontobject; }בואו נפרק את ההוראות שבאמת חשובות.
gzip_comp_level: ההגדרה שרוב האנשים מפספסים
רמת הדחיסה נעה בין 1 (הכי מהיר, דחיסה מינימלית) ל-9 (הכי איטי, דחיסה מקסימלית). מדריכים רבים ממליצים להגדיר 9. אל תעשו את זה.
רמה 9 צורכת הרבה יותר CPU מרמה 6, אבל ההבדל בגודל הקובץ קטן - בדרך כלל פחות מ-2-3% קטן יותר מרמה 6. רמה 6 היא נקודת האיזון האידיאלית. מקבלים כ-70-80% דחיסה על קבצי HTML ו-CSS טיפוסיים בלי לעמיס על ה-CPU בכל בקשה. כוונון ביצועי nginx עוסק לרוב בהסרת צווארי בקבוק ולא ברדיפה אחרי שיפורים שוליים, וזה דוגמה טובה לעיקרון הזה.
gzip_min_length: אל תדחסו תגובות קטנות
לדחוס תגובה של 50 בייט זה חסר טעם. העומס של כותרת gzip לבדה הוא כ-20 בייט, אז בקושי חוסכים משהו ובזבזתם CPU. הגדרת gzip_min_length 256 אומרת ל-Nginx לדחוס רק תגובות גדולות מ-256 בייט. עבור תגובות API קטנות מאוד או קבצי טקסט זעירים, ההוראה הזו חוסכת זמן עיבוד אמיתי.
gzip_vary: חיוני לשכבות מטמון
תמיד הפעילו gzip_vary on. זה מוסיף כותרת Vary: Accept-Encoding לתגובות, שאומרת ל-CDN ולמטמוני proxy לשמור גרסאות נפרדות של כל משאב - אחת דחוסה ואחת לא. בלי זה, CDN עלול לשמור את הגרסה הדחוסה ולהגיש אותה לדפדפן שאמר שלא יכול לטפל ב-gzip. הדפדפן אז יקבל נתונים פגומים.
gzip_proxied: טיפול בבקשות דרך proxy
אם Nginx שלך יושב מאחורי load balancer או CDN, הבקשות מגיעות עם כותרת Via. כברירת מחדל, Nginx לא ידחוס תגובות לבקשות שעברו דרך proxy. הגדרת gzip_proxied any אומרת לו לדחוס בכל מקרה. ברוב ההגדרות זה מה שרוצים.
אילו סוגי MIME לכלול (ואילו לדלג)
ההוראה gzip_types קובעת בדיוק אילו סוגי תוכן נדחסים. Nginx תמיד דוחס text/html ללא קשר לרשימה הזו, אבל כל השאר צריך לציין במפורש.
דחסו את סוגי הקבצים האלה - הם בעיקר טקסט ומתדחסים מצוין:
- קבצי CSS ו-JavaScript (לרוב קטנים ב-60-80%)
- תגובות JSON מ-API (לרוב קטנות ב-70-85%)
- תמונות SVG (לרוב קטנות ב-50-70%)
- פידי XML ומפות אתר
- גופנים בפורמטים מבוססי טקסט
דלגו לגמרי על אלה:
- תמונות JPEG, PNG, WebP, AVIF - כבר דחוסות
- MP4, WebM ופורמטי וידאו אחרים
- קבצי ZIP, GZ וארכיונים אחרים
- קבצי PDF
- קבצי גופן WOFF2 - כבר דחוסים פנימית
לנסות לדחוס JPEG ב-gzip לא רק לא חוסך מקום - זה עלול להגדיל את הקובץ מעט תוך כדי בזבוז CPU. השאירו פורמטים בינאריים בשקט.
בדיקת הגדרות ה-Gzip שלך
אחרי טעינה מחדש של Nginx, אמתו שהדחיסה עובדת עם curl:
curl -H "Accept-Encoding: gzip" -I https://yourdomain.comאתם אמורים לראות Content-Encoding: gzip בכותרות התגובה. אם לא, בדקו שבלוק ההגדרות נמצא בהקשר הנכון (בלוק http, לא בתוך בלוק location שעשוי לעקוף אותו).
לתמונה מלאה יותר, הריצו את ה-URL שלכם דרך Google PageSpeed Insights או בדקו את לשונית Network ב-Chrome DevTools. הסתכלו על עמודת הגודל - תראו את הגודל שהועבר לעומת הגודל האמיתי. קובץ CSS שמשקל 80KB בלי דחיסה ומופיע כ-18KB שהועברו אומר ש-gzip עובד כראוי.
צעד נוסף עם Gzip סטטי
אם רוצים לדחוף את כוונון ביצועי nginx עוד יותר, כדאי להסתכל על ngx_http_gzip_static_module. במקום לדחוס קבצים בכל בקשה, מדחסים אותם מראש ושומרים גרסאות .gz על הדיסק. Nginx מגיש את הקובץ הדחוס מראש ישירות כשהלקוח תומך ב-gzip, ומדלג לגמרי על שלב הדחיסה.
location ~* \.(js|css|html|xml|json|svg)$ { gzip_static on; expires max; add_header Cache-Control public; }הגישה הזו מתאימה לצינורות assets סטטיים שבהם קבצים נבנים ונפרסים. תהליך הבנייה שלכם יוצר app.js ו-app.js.gz, ו-Nginx מגיש את המתאים. אפס עלות CPU בזמן ריצה לדחיסה על הקבצים האלה. כבר כיסינו את הנושא הרחב של הגדרת תהליכי worker במאמר איך להגדיר תהליכי Worker ב-Nginx לתפוקה מרבית, ו-gzip סטטי משתלב באופן טבעי באותה שכבת ביצועים.
Gzip ו-Brotli: האם להשתמש בשניהם?
Brotli הוא אלגוריתם דחיסה חדש יותר של Google שבדרך כלל משיג דחיסה טובה ב-15-25% מ-gzip על קבצי טקסט, עם עלות CPU דומה. כל הדפדפנים המודרניים תומכים בו. אם יש לכם את המודול ngx_brotli, הפעלתו לצד gzip נותנת את הטוב משני העולמות - Brotli לדפדפנים מודרניים, gzip כגיבוי לישנים.
תבנית ההגדרה מקבילה ל-gzip:
brotli on; brotli_comp_level 6; brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;Nginx שולח Brotli כשהדפדפן מבקש אותו, וחוזר ל-gzip אחרת. אין עבודה נוספת מצדכם אחרי שזה מוגדר.
מה לצפות אחרי הפעלת Gzip
השיפורים אמיתיים ומיידיים. דף טיפוסי עם 200KB של HTML, CSS ו-JS בלי דחיסה בדרך כלל מועבר בכ-50-70KB אחרי gzip. זו הפחתה של 65-75% בגודל ההעברה. בחיבור סלולרי איטי של 5 Mbps, זה ההבדל בין העברה של 320ms לבין 90ms - לפני שבכלל מחשבים DNS, לחיצות יד TCP, או עיבוד.
TTFB (Time to First Byte) לא משתנה מ-gzip לבד, כי זה מודד את זמן העיבוד בשרת לפני שהתגובה מתחילה לזרום. אבל זמן טעינת הדף הכולל יורד בצורה ניכרת כי גוף התגובה מגיע מהר יותר. אם אתם עובדים על TTFB בנפרד, למה ה-Time to First Byte שלכם פוגע בהמרות עובר על זה בפירוט.
שלבו gzip עם מטמון בצד השרת וערמתם שניים מהשיפורים המשפיעים ביותר הזמינים. תגובה שמורה במטמון ודחוסה היא כמעט המהירה ביותר שהשרת שלכם יכול לספק. לתמונה רחבה יותר של מה שמאחורי שרת מהיר, איך אחסון אתרים מהיר נראה מתחת למכסה המנוע מכסה את התמונה המלאה.
ההגדרות למעלה לוקחות דקות ליישום. טענו מחדש את Nginx, אמתו עם curl, וסיימתם. שיפור הביצועים נשאר לצמיתות ללא צורך בתחזוקה שוטפת.
