כדאי לבצע אופטימיזציה של הקידוד וההעברה של נכסים מבוססי טקסט

Ilya Grigorik

Jeremy Wagner

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

דחיסת נתונים 101

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

כדי להשיג את הביצועים הטובים ביותר, צריך לשלב את כל השיטות הבאות:

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

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

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

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

# Below is a secret message, which consists of a set of headers in
# key-value format followed by a newline and the encrypted message.
format: secret-cipher
date: 08/25/16
AAAZZBBBBEEEMMM EEETTTAAA

1. הודעות יכולות להכיל הערות שרירותיות – שנקראות לפעמים תגובות – שמצוינות באמצעות הקידומת '‎#'. ההערות לא משפיעות על המשמעות של ההודעה או על ההתנהגות שלה.
2. הודעות יכולות להכיל כותרות, שהן צמדי מפתח/ערך (מופרדים על ידי ":" בדוגמה הקודמת) שמופיעים בתחילת ההודעה.
3. ההודעות מכילות עומסי נתונים של טקסט.

מה אפשר לעשות כדי לצמצם את הגודל של ההודעה הקודמת, שמתחילה ב-200 תווים?

1. התגובה מעניינת, אבל היא לא משפיעה על משמעות ההודעה. להסיר אותו במהלך העברת ההודעה.
2. יש שיטות טובות לקידוד כותרות בצורה יעילה. לדוגמה, אם אתם יודעים שלכל ההודעות יש את השדות 'format' ו-'date', תוכלו להמיר אותם למזהי מספר שלמים קצרים ולשלוח אותם. עם זאת, יכול להיות שזה לא נכון, לכן עדיף לא לעשות שום דבר כרגע.
3. תוכן העומס הוא טקסט בלבד. אנחנו לא יודעים מהו התוכן האמיתי שלו (כנראה שהוא כולל "secret-cipher"), אבל כבר מהסתכלות על הטקסט אפשר לראות שיש בו הרבה יתירות. אולי במקום לשלוח אותיות חוזרות, אפשר פשוט לספור את מספר האותיות שחוזרות על עצמן ולקודד אותן בצורה יעילה יותר. לדוגמה, הערך "AAA" הופך ל-"3A", שמייצג רצף של שלוש אותיות A.

השילוב של השיטות האלה מניב את התוצאה הבאה:

format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A

ההודעה החדשה באורך 56 תווים, כלומר דחסתם את ההודעה המקורית ב-72%. זו ירידה משמעותית!

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

הקטנה: עיבוד מראש ואופטימיזציות ספציפיות להקשר

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

דחיסה היא סוג של אופטימיזציה ספציפית לתוכן שיכולה לצמצם באופן משמעותי את הגודל של המשאבים המועברים. מומלץ להחיל את האופטימיזציה הזו כחלק מתהליך ה-build והפריסה. לדוגמה, חבילות קוד (bundlers) הן סוג נפוץ של תוכנה שיכולה לבצע אוטומציה של דחיסת משאבים ממש לפני הפריסה של קוד ייצור חדש באתר.

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

<html>
  <head>
    <style>
      /* awesome-container is only used on the landing page */
      .awesome-container {
        font-size: 120%;
      }

      .awesome-container {
        width: 50%;
      }
    </style>
  </head>
  <body>
    <!-- awesome container content: START -->
    <div>
      This is my awesome container, and it is <em>so</em> awesome.
    </div>
    <!-- awesome container content: END -->
    <script>
      awesomeAnalytics(); // Beacon conversion metrics
    </script>
  </body>
</html>

נתבונן בקטע הקודם של HTML ובשלושת סוגי התוכן השונים שהוא מכיל:

1. סימון HTML.
2. CSS כדי להתאים אישית את המצגת של דף.
3. JavaScript כדי להפעיל אינטראקציות ויכולות מתקדמות אחרות בדף.

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

• תגובות בקוד הן החברות הכי טובות של המפתחים, אבל הדפדפן לא זקוק להן. הסרת תגובות של CSS (/* ... */), HTML (<!-- ... -->) ו-JavaScript (// ...) מפחיתה את הגודל הכולל של ההעברה של הדף ושל משאבי המשנה שלו.
• כלי 'חכם' לדחיסת CSS יכול להבחין שאנחנו משתמשים בדרך לא יעילה להגדרת כללים בשביל .awesome-container, ולכווץ את שתי ההצהרות לאחת – בלי להשפיע על סגנונות אחרים, וכך לחסוך יותר בייטים. הסרת יתירות מהסוג הזה עשויה לעלות על מספר גדול של כללי CSS, אבל ייתכן שזו לא פעולה אגרסיבית שאפשר להחיל באופן אגרסיבי, כי הרבה פעמים יש צורך לשכפל סלקטורים בהקשרים שונים, למשל בשאילתות מדיה.
• מרחבים וכרטיסיות נותנים למפתחים יתרונות ב-HTML, ב-CSS וב-JavaScript. דחיסה נוספת יכולה להסיר את כל הכרטיסיות והרווחים. בשונה מטכניקות אחרות לביטול כפילויות, אפשר לבצע אופטימיזציה כזו בצורה די אגרסיבית, כל עוד רווחים או כרטיסיות כאלה לא הכרחיים למצגת של הדף. לדוגמה, מומלץ לשמור את הרווחים בתוך רצפי טקסט במסמך HTML, מכיוון שהן מבטיחות את הקריאוּת של התוכן שהמשתמשים יראו בפועל.

<html><head><style>.awesome-container{font-size:120%;width:50%}</style></head><body><div>This is my awesome container, and it is <em>so</em> awesome.</div><script>awesomeAnalytics()</script></body></html>

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

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

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

הערה: לדוגמה, גרסאות הפיתוח הלא דחוסות של מסגרות פופולריות גדולות בהרבה מהגרסאות המקבילות שנועדו לשימוש בסביבת הייצור. לדוגמה, גרסת הפיתוח של Angular 1.8.3 היא כמעט 1.4 מגה-בייט. גרסת הייצור היא 177KB. זהו דוגמה מצוינת לפוטנציאל של פעולות האופטימיזציה האלה.

באופן דומה, אפשר להרחיב את השימוש בשיטות שמתוארות למעלה גם לנכסים דיגיטליים שאינם מבוססי טקסט. תמונות, סרטונים וסוגים אחרים של תוכן מכילים צורות משלהם של מטא-נתונים ועומס שימושי (payload) שונה. לדוגמה, כשמצלמים תמונה במצלמה, בדרך כלל הקובץ שלה כולל הרבה מידע נוסף: הגדרות המצלמה, המיקום וכו'. בהתאם לאפליקציה, הנתונים האלה עשויים להיות קריטיים (לדוגמה, אתר לשיתוף תמונות) או שהם לא יהיו שימושיים כלל. כדאי לשקול אם כדאי להסיר אותו. בפועל, המטא-נתונים האלו יכולים להוסיף עד עשרות קילובייט לכל תמונה.

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

דחיסת טקסט באמצעות אלגוריתמים לדחיסת נתונים

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

• gzip ו-Brotli הם אלגוריתמים לדחיסה, שמניבים את הביצועים הטובים ביותר בנכסים מבוססי-טקסט: CSS, JavaScript ו-HTML.
• כל הדפדפנים המודרניים תומכים בדחיסת gzip ובדחיסת Brotli, והם יפרסמו תמיכה בשתיהן בכותרת הבקשה Accept-Encoding של HTTP.
• צריך להגדיר את השרת כך שיאפשר דחיסת נתונים. בדרך כלל, תוכנת שרת האינטרנט מאפשרת למודול לדחוס משאבים מבוססי-טקסט כברירת מחדל.
• אפשר לכוונן גם את gzip וגם את Brotli כדי לשפר את יחסי הדחיסה על ידי התאמת רמת הדחיסה. עבור gzip, הגדרות הדחיסה נעות בין 1 ל-9, כאשר 9 היא הטובה ביותר. במקרה של Brotli, הטווח הוא 0 עד 11, ו-11 הוא הערך הכי טוב. עם זאת, הגדרות דחיסה גבוהות יותר דורשות יותר זמן. למשאבים דחוסים באופן דינמי – כלומר בזמן הבקשה – הגדרות באמצע הטווח נוטות להתאים בצורה הטובה ביותר בין יחס הדחיסה למהירות. עם זאת, אפשר לבצע דחיסה סטטית, כלומר כשדוחסים את התגובה מראש, ולכן אפשר להשתמש בהגדרות הדחיסה האגרסיביות ביותר שזמינות לכל אלגוריתם דחיסה.
• רשתות להעברת תוכן (CDN) מציעות בדרך כלל דחיסה אוטומטית של משאבים שעומדים בדרישות. שירותי ה-CDN יכולים גם לנהל בשבילכם דחיסה דינמית וסטטית, כך שלא תצטרכו לדאוג עוד היבט אחד של הדחיסה.

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

הערה:  אם אתם רוצים הסבר מעמיק יותר על אופן הפעולה של דחיסת הנתונים, כדאי לצפות בהסבר המצוין הזה ברמה בסיסית על gzip. אם אתם רוצים להתנסות בדחיסת טקסט, כדאי לנסות את ה-codelabs באמצעות gzip ו-Brotli.

בפועל, גם gzip וגם Brotli מניבים את הביצועים הטובים ביותר בתוכן מבוסס-טקסט, ולרוב מגיעים לשיעורי דחיסה של עד 70-90% בקבצים גדולים יותר. עם זאת, הפעלת האלגוריתמים האלה על נכסים שכבר דחוסים באמצעות אלגוריתמים חלופיים – כמו רוב פורמטים התמונות שמשתמשים בשיטות דחיסה ללא אובדן נתונים או עם אובדן נתונים – לא מניבה שיפור משמעותי או שיפור בכלל.

כל הדפדפנים המודרניים מכריזים על תמיכה ב-gzip וב-Brotli בכותרת הבקשה Accept-Encoding של HTTP. עם זאת, ספק האירוח אחראי לוודא ששרת האינטרנט מוגדר כראוי כדי להציג את המשאב המכווץ כשהלקוח מבקש אותו.

קובץ	אלגוריתם	גודל לא דחוס	גודל דחוס	יחסי דחיסה
angular-1.8.3.js	ברוטלי	1,346 KiB	256 KiB	81%
angular-1.8.3.js	gzip	1,346 KiB	329 KiB	76%
angular-1.8.3.min.js	ברוטלי	‎173 KiB	53 KiB	69%
angular-1.8.3.min.js	gzip	‎173 KiB	60 KiB	65%
jquery-3.7.1.js	Brotli	302 KiB	69 KiB	77%
jquery-3.7.1.js	gzip	302 KiB	83 KiB	73%
jquery-3.7.1.min.js	Brotli	85 KiB	27 KiB	68%
jquery-3.7.1.min.js	gzip	85 KiB	30 KiB	65%
lodash-4.17.21.js	Brotli	531 KiB	73 KiB	86%
lodash-4.17.21.js	gzip	531 KiB	94 KiB	82%
lodash-4.17.21.min.js	Brotli	71 KiB	23 KiB	68%
lodash-4.17.21.min.js	gzip	71 KiB	25 KiB	65%

בטבלה שלמעלה מוצגים החיסכון שאפשר להשיג באמצעות דחיסת Brotli ו-gzip בכמה ספריות JavaScript ידועות. החיסכון נע בין 65% ל-86%, בהתאם לקובץ ולאלגוריתם. לידיעתכם, רמת הדחיסה המקסימלית הוחלו על כל קובץ גם ב-Brotli וגם ב-gzip. בכל מקרה אפשר להשתמש ב-Brotli במקום ב-gzip.

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

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

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

ייצוג של גודל העברה (כלומר, דחוס) של כל משאבי הדף לעומת הגודל בפועל שלהם, כפי שמוצג בחלונית הרשת של כלי הפיתוח של Chrome.

כמו בתמונה הקודמת, אתם אמורים לראות פירוט של:

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

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

ההשפעה על מדדי הליבה לבדיקת חוויית המשתמש באתר

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

כשמפעילים את האופטימיזציות שמפורטות במדריך הזה במשאבים באתר, ההשפעה על מדדי Core Web Vitals עשויה להשתנות בהתאם למשאבים שעברו אופטימיזציה ולמדדים הרלוונטיים. עם זאת, ריכזנו כאן כמה מקרים שבהם החלת האופטימיזציות האלה יכולה לשפר את מדדי חוויית המשתמש הבסיסיים באתר:

• משאבי HTML שעברו אופטימיזציה ודחיסה יכולים לשפר את טעינת ה-HTML, את יכולת הגילוי של משאבי המשנה שלו, וכתוצאה מכך לשפר את טעינת משאבי המשנה. הפעולה הזו יכולה לשפר את הזמן שבו נטען רכיב התוכן הכי גדול (LCP) בדף. אפשר להשתמש ברמזים של משאבים כמו rel="preload" כדי להשפיע על יכולת הגילוי של משאבים, אבל שימוש ביותר מדי מהם עלול לגרום לבעיות עם סתירה בין רוחב הפס. כדי לוודא שתגובת ה-HTML לבקשת ניווט דחוסה, סורק ההטענה מראש יכול לגלות את המשאבים שבתוכה בהקדם האפשרי.
• אפשר גם להשתמש בקידוד כדי לטעון חלק מהקובצי ה-LCP האפשריים מהר יותר. לדוגמה, אפשר לצמצם את משך הזמן לטעינת המשאב של תמונות SVG שיכולות להיחשב כ-LCP באמצעות דחיסת טקסט. זה שונה מהאופטימיזציות שאפשר לבצע בסוגי תמונות אחרים, שנדחסים באופן מהותי באמצעות שיטות דחיסה אחרות, כמו השימוש בדחיסת נתונים עם אובדן בתמונות JPEG.
• בנוסף, צמתים של טקסט יכולים להיות גם מועמדים ל-LCP. השיטות המתוארות במדריך הזה תלויות בשאלה אם אתם משתמשים בגופן אינטרנט בטקסט בדפי האינטרנט שלכם. אם משתמשים בגופן אינטרנט, שיטות מומלצות לאופטימיזציה של גופן באינטרנט חלות עליו. עם זאת, אם לא משתמשים בגופני אינטרנט, אלא בגופני מערכת שמוצגים בלי לצבור משך טעינה של משאבים – הקטנה ודחיסה של ה-CSS מקצרת את משך הזמן הזה. המשמעות היא שרינדור צמתים של טקסט LCP פוטנציאליים עשוי להתרחש מוקדם יותר.

סיכום

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

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

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