דחיסת gzip nginx: היכן מאבדים מהירות ותעבורה
הדחיסה מופעלת, ההנחיה בקונפיגורציה של Nginx קיימת, הפעלה מחדש בוצעה — אך הדפדפן עדיין מקבל תגובה כבדה. משקל התגובה של הדף לא משתנה, הטעינה הראשונה האיטית נשארת, וזה מורגש לא בלוגים אלא במדדים בצד הלקוח.
סיבה טיפוסית: דחיסת gzip מוגדרת, אך אינה פועלת עבור כל התגובות — חלקן עוברות ליד הכלל מהמטמון הפנימי, דרך פרוקסי או כקבצים סטטיים, שעבורם התנאי לא התקיים.
הקבוצה השנייה של בעיות — כיסוי. רשימת סוגי התוכן כברירת מחדל צרה: סגנונות, סקריפטים, גרפיקה וקטורית, JSON אינם נכללים בה. חלק מהתגובות נדחסות בזמן אמת בכל בקשה, אחרות נשלחות דחוסות שוב — והלקוח מפענח את מה שעדיף היה לקבל כפי שהן. זה נבדק רק לפי כותרות: האם השרת מסתכל על הפורמטים הנתמכים על ידי הלקוח ומה באמת נמצא בגוף התגובה.
השלישית — צוואר בקבוק בהגשה. הדחיסה מתבצעת ברגע הגעת הבקשה, והמשאב מתבזבז על כל פנייה במקום להגיש קובץ שהוכן מראש. בעומסי שיא זה יוצר תור: זמן התגובה גדל לא בגלל עומס על הערוץ, אלא בגלל אותה עבודה חוזרת ונשנית. המחיר מדיד — פי כמה יותר בתים ללקוח, ירידה בהמרות בטעינה ראשונה איטית ותעבורה שגדלה יחד עם הקהל.
להלן נבחן כיצד זה נסגר: היכן בדיוק אובדת הדחיסה, אילו כללים תופסים זאת וכיצד להגיש ארכיונים מוכנים מראש במקום עבודה בכל בקשה.
מה נותנת דחיסה נכונה: זמן תגובה ונפח
נפח העברה
נדחסים משאבי טקסט: סימון, סגנונות, סקריפטים, תגובות API ב-JSON. בפרונטאנד טיפוסי זה 60–80% ממשקל הדף, ולאחר ההגדרה הם נשלחים בזרימה קטנה פי 3–5. תמונות, וידאו ופונטים כבר דחוסים על ידי הפורמט — אותם מוציאים מהמדיניות כדי לא לבזבז מעבד לשווא.
זמן תגובה
פחות בתים על החוט — מסך ראשון מצויר מהר יותר, במיוחד ברשתות סלולריות ובאזורים מרוחקים. Brotli על סטטי נותן נפח קטן באופן ניכר יותר מאשר gzip באותה רמה: ההבדל בגודל מגיע ל-15–25% בסגנונות ובסקריפטים. עבור דינמיקה מפעילים דחיסה בזמן אמת ברמה מתונה — הרווח בזמן עולה על העלות.
עומס על המעבד
דחיסה עולה מחזורים, לכן מפזרים אותה לפי סוגי תוכן ורמות. סטטי מכינים מראש ומאחסנים במטמון, דינמיקה דוחסים ברמה נמוכה, תגובות קטנות לא נוגעים בהן כלל — בהן הכותרות שוקלות יותר מהגוף. כך המעבד עסוק רק במקומות שבהם זה באמת מקצר את ההעברה.
עמידות תחת עומס
חיסכון בערוץ — זה מרווח בעומסי שיא. כאשר התעבורה גדלה פי כמה, צוואר הבקבוק עובר מהפס אל השירותים עצמם, והאתר מחזיק מעמד בגל ללא הרחבת הערוץ. הגשת סטטי מואצת גם הודות למטמון בקצה הרשת: תגובה דחוסה נמסרת ממנו בלי להגיע לאפליקציה.
מה בודקים לאחר ההגדרה
מודדים את שיעור התגובות הדחוסות, את המקדם בפועל לפי סוגי קבצים ואת עומס המעבד בשעות שיא. תיקונים מבוצעים לפי נתונים, לא "בעין": רואים אילו פורמטים להשאיר במדיניות ואילו להחריג.
היכן להפעיל דחיסה: אפשרויות ומגבלות
נקודת ההפעלה נבחרת לפי מי שמחזיק בתגובה והיכן מתאים לבזבז מעבד. דחיסה היא חוליה בשרשרת האספקה: האפליקציה יוצרת את הגוף, פרוקסי הפוך מנתב בקשות, שרת האינטרנט מגיש סטטי, הפריפריה היא מטמון. אין לדחוס בשני מקומות ברצף: עיבוד חוזר של גוף שכבר דחוס שובר את התגובה, לכן בוחרים נקודה אחת.
קריטריונים לבחירה: שליטה ברשימת הסוגים ובאורך המינימלי של התגובה, קיום Vary: Accept-Encoding לעבודה תקינה של מטמונים, מחיר זמן המעבד לבקשה ויכולת לאחסן ארכיונים מוכנים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| דחיסה בשרת האינטרנט | תעבורה מעורבת: סטטי ותגובות אפליקציה עוברים דרך שרת אחד, נדרשים כללים גמישים לפי סוגים | רשימת הסוגים וסף האורך מוגדרים ידנית; שגיאה בכללים נותנת תגובה לא דחוסה או עומס מיותר |
| דחיסה בפרוקסי הפוך | מספר שירותים תחת כניסה אחת, נדרשים כללים אחידים ומטמון של תגובות דחוסות | דוחס לפי כותרות, אינו רואה את התוכן; בעת אחסון במטמון יש להפריד וריאנטים לפי Accept-Encoding |
| הכנת קבצים מראש | סטטי שמשתנה לעתים רחוקות: הבנייה מניחה מיד לצד .gz ו-.br |
רק קבצים על הדיסק; אינו מכסה דינמיקה, יש לבנות מחדש את הארכיונים בכל עדכון |
| דחיסה בפריפריית האספקה | קהל מבוזר גיאוגרפית ונפח סטטי גדול | ההגדרות תלויות בפלטפורמה; חלק מהתגובות עוברות ליד אם הדחיסה כבר בוצעה במקור |
| דחיסה באפליקציה | תגובות נוצרות בזמן אמת ואינן עוברות דרך שרת משותף | זמן מעבד מתבזבז על כל בקשה, קשה יותר לאחסן במטמון ולנפות |
סדר העבודות: מביקורת ההגשה ועד בדיקה בפרודקשן
דחיסה היא לא הנחיה אחת בקונפיג, אלא שרשרת החלטות: מה לדחוס, באיזה צומת להפעיל דחיסה וכיצד לא לשבור פורמטים שכבר דחוסים כמו תמונות ווידאו. להלן הסדר שבו אנו מובילים את ההטמעה: האפקט צפוי, והחזרה לאחור אורכת דקות.
-
ביקורת הגשה. אנו מודדים גדלים אמיתיים של תגובות לפי סוגי תוכן: סימון, סגנונות, סקריפטים, פונטים, תגובות API. בודקים מה כבר מגיע דחוס מהפריפריה. בפלט — רשימת סוגים שבהם דחיסה נותנת רווח, ואלה שבהם היא רק מבזבזת משאב.
-
תרשים עיבוד בקשה. מתעדים באיזה צומת מיושמת הדחיסה ומה דוחסת הפריפריה. דחיסה כפולה של אותה תגובה — זה עומס בלי רווח בגודל.
-
הגדרת דחיסה. מפעילים gzip ככיסוי בסיסי ו-Brotli עבור לקוחות שתומכים בו: בסוגי טקסט הוא נותן גודל קטן יותר. מגדירים רמת דחיסה, גודל תגובה מינימלי, רשימת סוגים וחריגים עבור פורמטים שכבר דחוסים; הגרסה הדחוסה והלא דחוסה צריכות להיות מופרדות כראוי במטמון.
-
בדיקה לפני עלייה לאוויר. משווים גודל וזמן הגשה לפני ואחרי בסביבת בדיקות, בנפרד על מטמון קר וחם, מריצים דפים מרכזיים ותגובות API.
-
תוכנית החזרה לאחור. הקונפיגורציה מנוהלת בגרסאות, השינויים יוצאים בתיקון אחד, שאותו מסירים בלי לבנות מחדש את האפליקציה. מראש מתעדים מדדים שלפיהם נחשב את העלייה ללא מוצלחת.
-
עלייה לאוויר ומסירה. פורסים תחילה על חלק מהתעבורה, עוקבים אחר שיעור התגובות הדחוסות וזמן ההגשה, ואז מפעילים באופן מלא. מעבירים לצוות קונפיגים, תרשים והוראה קצרה לבדיקה לאחר השחרור.
קונפיגורציות, תרשימים ותקנות בפלט
אנו מעבירים לא רק שרת עובד, אלא גם מערכת של חפצים (ארטפקטים), שלפיהם הדחיסה ממשיכה להתנהל בכוחות עצמכם. כל מסמך קשור למקום מסוים בקונפיגורציה, לכן אין צורך לשחזר את היגיון הכללים מהיסטוריית התיקונים.
- קונפיגורציות שרת מוכנות: רמות דחיסה לסטטי ולדינמיקה, סף גודל תגובה מינימלי, עבודה עם קבצים דחוסים מראש — עם הסבר מדוע נבחרו דווקא ערכים אלה.
- תרשים עיבוד בקשה: המסלול מהלקוח ועד ההגשה דרך פרוקסי, מטמון ואפליקציה, מקום הדחיסה בשרשרת זו ונקודות שבהן התגובה יכולה לעבור לידו.
- מדיניות חריגים: רשימת סוגי קבצים שדחיסתם חסרת טעם — תמונות, וידאו, ארכיונים, פורמטים ארוזים ממילא.
- תקנון שינויים: כיצד תיקונים ברשימות וברמות עוברים בדיקה לפני עלייה לאוויר, מה מתועד בהיסטוריה ולפי איזה תנאי מתבצעת החזרה לאחור.
- תיעוד הגשה: אילו כותרות השרת חייב להחזיר, כיצד לוודא שהתגובה הגיעה דחוסה, לאן להסתכל בתלונה על טעינה איטית.
- מערכת בדיקות ומדדים: שיעור התגובות עם דחיסה, נפח הנתונים המועברים לפני ואחרי, זמן הגשה ותדירות שגיאות דחיסה.
- הוראות תמיכה: היכן לשנות חריגים ורמות, כיצד להוסיף סוג קובץ חדש ומה זה ישפיע.
מקרה בוחן: האצנו את הגשת הקטלוג בלי להחליף שרתים
קטלוג של ספק גדול: עשרות אלפי כרטיסים, תבניות כבדות, הרבה טקסט וסימון בכל תגובה. המדידות הראו שצוואר הבקבוק אינו בשרת ולא בבסיס הנתונים — המעבד והדיסק היו בעומס של חצי, והדף האט דווקא בהעברה. אף תגובת טקסט לא יצאה דחוסה: את ההגדרה כיבו עוד בהתקנה הראשונית ומאז לא חזרו אליה.
מדידות לפני ההטמעה
דף קטלוג ממוצע שקל כ-1.2 MB, מתוכם יותר מ-80% היו סימון, סגנונות וסקריפטים. זמן עד לתצוגה ראשונה בערוץ ממוצע — כ-3.4 שניות, שיעור התגובות הדחוסות — אפס. נטישות במובייל היו גבוהות באופן ניכר יותר מאשר בדסקטופ: ההבדל הוסבר ברוחב הפס של הערוץ, לא באיכות הפריסה.
מה שינינו ומה יצא
הפעלנו gzip עבור סוגי טקסט והוספנו brotli עם דחיסה מראש של סטטי על הדיסק — הקבצים הוכנו פעם אחת, ולא בכל בקשה. את הקונפיגורציה של Nginx השלמנו עם רשימה מפורשת של סוגים, חיתוך של פורמטים שכבר דחוסים ואחסון במטמון של וריאנטים בפרוקסי.
שיעור התגובות הדחוסות עלה ל-96%, משקל דף הקטלוג ירד ל-210 KB, זמן התגובה הצטמצם ל-1.1 שניות — על אותה חומרה ובלי לכתוב מחדש את הלוגיקה של השרת.
את התוצאה אימתו לפי יומני גישה ומדידות מאזורים שונים, כדי לשלול השפעה של מטמון. הקונפיגורציה נמצאת בקובץ נפרד, לכן החזרה להתנהגות הקודמת — פקודה אחת.
במה שונה הכנה מראש מעיבוד בזמן אמת?
ההבדל הוא היכן ומתי מתבזבז זמן מעבד. בהכנה מראש הדחיסה מתבצעת פעם אחת — בשלב הבנייה או פרסום התוכן, והתוצאה נמצאת לצד המקור כקובץ נפרד. שרת האינטרנט במקרה זה רק בוחר את הווריאנט המתאים לפי כותרת Accept-Encoding ומגיש בתים מוכנים, בלי להעמיס על המעבד בכל בקשה.
עיבוד בזמן אמת דוחס את גוף התגובה בכל פעם שהשרת יוצר אותו. עלות זמן המעבד גדלה ליניארית עם התעבורה: ככל שרמת הדחיסה גבוהה יותר, כך התרומה לעומס הליבה גדולה יותר, ובזרם של תגובות קטנות ההוצאות הנלוות עולות על הרווח בנפח ההעברה.
תוכן דינמי — בדיוק הקטגוריה הזו: הגוף תלוי בבקשה, בסשן ובנתונים, אי אפשר להרכיב עבורו קובץ מוכן. כאן פועלים שני טריקים: מטמון בפריפריה, שמחזיק ייצוג דחוס כבר ומגיש אותו שוב בלי דחיסה חוזרת, וחיתוך לפי גודל וסוגים — אין טעם לדחוס תגובות קטנות מהסף, הן רק מבזבזות מעבד.
בפועל המצבים לא מתחרים, אלא מחלקים תחומי אחריות: סטטי ותבניות — מראש, דינמיקה — בזמן אמת ברמה מתונה ועם מטמון מופעל בפריפריה. פריסה כזו נותנת חיסכון בתעבורה בעומס צפוי על המעבד.
שאלות טכניות נפוצות בנושא הגדרת הגשה
הספקות לפני הפעלת דחיסה הם בדרך כלל אותם ספקות: כיצד לוודא שהיא עובדת, האם התוכן לא יתחיל להיות דחוס פעמיים ומה להחריג מהעיבוד. תשובות קצרות לכל אחת — להלן.
כיצד לבדוק שהדחיסה באמת הופעלה?
בקשה עם כותרת Accept-Encoding ותגובה עם Content-Encoding: בגוף מגיע אותו תוכן, אך עם Content-Length קטן באופן ניכר יותר.
הדרך הפשוטה ביותר היא להשוות את גודל התגובה עם הכותרת ובלעדיה, ולפי הלוגים בנוסף להסתכל על מקדם הדחיסה — כך רואים שהכלל פעל לא רק על הסימון, אלא גם על סגנונות, סקריפטים ופונטים.
מאיפה מגיעה דחיסה כפולה?
אם לפני השרת עומד פרוקסי או מטמון חיצוני שדוחס את התגובות בעצמו, התוכן יוצא מקודד פעמיים. אפשרות עבודה — להשאיר רמה אחת: או בקצה, או בשרת עצמו. אנו מתעדים זאת לפני העבודות, כדי לאחר מכן לא לחפש את הסיבה לנפח התגובה שגדל אצל חלק מהמשתמשים.
אילו סוגי קבצים מחריגים?
כברירת מחדל נדחס רק הסימון, את השאר — סגנונות, סקריפטים, json, svg, פונטים — מפרטים ידנית. פורמטים בינאריים ועותקים דחוסים מראש מוגשים כפי שהם: אין רווח בגודל, והעומס על המעבד גדל בכל בקשה.
מה עם אחסון במטמון וכותרות?
בלי הכותרת Vary: Accept-Encoding מטמון ביניים עשוי להגיש וריאנט דחוס ללקוח שלא תומך בו. את תאריך השינוי שומרים, את חיי המדף של הסטטי מגדירים ארוכים — אז ביקורים חוזרים בכלל לא נוגעים בשרת.
האם זה תואם לפרוקסי ומאזני עומסים?
כן. הדבר היחיד שכדאי להסכים עליו מראש — באיזו רמה מופעלת הדחיסה: אם החיבור מסתיים במאזן העומסים, הגיוני יותר לעשות זאת שם. בדרך כלל כך מתברר מדוע אצל חלק מהקהל התגובות מגיעות ללא דחיסה.
נדון במשימה: ממה מתחילים ומה צריך מכם
השיחה הראשונה נדרשת כדי לראות את תרשים עיבוד הבקשות שלכם בשלמותו: היכן מסתיים החיבור המאובטח, מה עומד לפני האפליקציה, אילו תגובות כבר יוצאות דחוסות ואילו — כפי שהן. לפי תמונה זו מתברר היכן הפעלת gzip ו-Brotli תיתן אפקט מידי, והיכן היא תיתקל במעבד או במטמון ביניים.
בהמשך נדרשים נתוני קלט — בלעדיהם הערכת העבודות הופכת לניחושים. בדרך כלל אנו מבקשים:
- קונפיגורציה של שרת האינטרנט והפרוקסי ההפוך: היכן מופעלת הדחיסה, אילו מודולים מורכבים;
- רשימת סוגי תוכן והשיעור הנוכחי של תגובות דחוסות: סימון, JSON, סגנונות, פונטים, סטטי;
- תרשים אחסון במטמון: פרוקסי ביניים, רשת אספקת תוכן, ניהול גרסאות של קבצים;
- מרווח במעבד בצמתים שדוחסים תעבורה ופרופיל עומס שיא;
- סביבות וסדר שחרור: כיצד שינוי מגיע לפרודקשן והאם קיים קו בדיקות;
- דרישות לחזרה לאחור וחלונות שבהם ניתן להחליף קונפיגורציה ללא סיכון;
- מדדים שלפיהם אתם שופטים את התוצאה: זמן תגובה, נפח תעבורה, עומס על המעבד, שיעור פגיעות במטמון.
בפלט אתם מקבלים תוכנית עבודה: מה מפעילים, באיזה סדר, במה בודקים את האפקט וכיצד מחזירים לאחור בצעד אחד. תארו את המשימה — נחזור עם הערכה ותוכנית, ולאחר אישור נקבע את תחילת הפרויקט.