דחיסת אותו קובץ בכל פעם

השרת Apache דוחס תשובות תוך כדי מסירה. בדף ששונה בכל פעם, זאת האפשרות היחידה. בגיליון סגנונות שמשתנה פעם בחודש, המשמעות היא שהשרת עושה שוב את אותה עבודה לכל מבקר, במשך שבועות, וזורק את התוצאה בכל פעם. אין לה מטמון.

נמדד ב־19 באוגוסט 2026 על גבי חיבור קיים, עם הקובץ של האתר הזה style.css (124 kB) ועם world.js (102 kB):

	זמן	בתים
ללא דחיסה	2.9 ms	124,755
gzip, תוך כדי מסירה	18.1 ms	34,995
brotli, תוך כדי מסירה	14.5 ms	32,685
world.js, gzip	47.9 ms	38,283
world.js, brotli	15.9 ms	38,086

ארבעים ושמונה אלפיות השנייה של זמן מעבד, לכל בקשה, כדי להפיק תוצאה זהה בית לבית. בשרת קטן זאת אינה שגיאת עיגול.

לדחוס פעם אחת, לדיסק

שלב בנייה כותב את הקובץ הדחוס לצד המקור, וכלל שכתוב מגיש אותו כשהדפדפן אומר שהוא מקבל gzip. הגשת קובץ מוכן עולה כמו הגשת כל קובץ אחר.

gzip ולא brotli, מסיבה משעממת: אין קובץ הרצה של brotli מותקן במחשב הזה. הקבצים גדולים בכ־7% ממה ש־brotli היה מפיק, וזמן השרת הוא חמישית מהעלות של brotli תוך כדי מסירה. היה כדאי לקבל את הפשרה הזאת עכשיו במקום להמתין לתשובה נאה יותר.

הגרסה נכנסת לשם הקובץ

הבנייה כותבת style.css.<mtime>.gz, והערך ?v= בקוד הסימון הוא אותו מועד שינוי. השכתוב מופעל רק כשקיים קובץ עם המספר התואם.

לסידור הזה יש תכונה שכדאי לתכנן במכוון: אם גיליון הסגנונות משתנה ושוכחים לבנות מחדש, המספר בקוד הסימון מצביע על קובץ שאינו קיים, השכתוב אינו מופעל, והשרת Apache מגיש את המקור כרגיל. במקרה הגרוע חסרה ההאצה. לא יכול לצאת גיליון סגנונות מיושן. כל שיטת מטמון צריכה להיבדק מול השאלה הזאת — כשמשהו משתבש, האם היא נעשית איטית או שגויה?

הבאג שבאמצע

הקובץ שמוגש כבר דחוס ב־gzip, ולכן אסור לדחוס אותו שוב בדרך החוצה. ההגדרה המקורית קבעה no-gzip, שעוצר אחד משני המדחסים של Apache. האחר, mod_brotli, דחס ב־brotli בשמחה את קובץ ה־gzip המוכן בזמן שכותרת התשובה המשיכה לומר gzip.

הדפדפנים קיבלו תוכן בלתי קריא. הדבר לא התגלה מהתבוננות בדף — הוא התגלה מחיבור מספר הבתים ומציאת מספר לא הגיוני. הפתרון דורש גם no-gzip וגם no-brotli יחד, ורק אחד מהם מובן מאליו.