לצד ביטול הורדות של משאבים מיותרים, הדבר הטוב ביותר שאפשר לעשות שיפור מהירות הטעינה של דפים הוא לצמצם את גודל ההורדה הכולל על ידי אופטימיזציה ולדחוס את שאר המשאבים.
דחיסת נתונים 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
- הודעות עשויות לכלול הערות שרירותיות, הנקראות לפעמים תגובות שמסומנות בסימן # . אין השפעה על הערות המשמעות של ההודעה או ההתנהגות שלה.
- ההודעות עשויות להכיל כותרות, שהן צמדי מפתח/ערך (שמופרדות באמצעות
":"
בדוגמה הקודמת) שמופיעים בתחילת ההודעה. - ההודעות כוללות מטענים ייעודיים של טקסט.
מה אפשר לעשות כדי להקטין את ההודעה הקודמת, שמתחילה ב- 200 תווים?
- התגובה מעניינת, אבל היא לא משפיעה על משמעות ההודעה. יש להסיר אותה במהלך העברת ההודעה.
- יש שיטות טובות לקידוד כותרות בצורה יעילה. עבור למשל, אם אתם יודעים שכל ההודעות כוללות את המילה "format" ו-"date", אפשר להמיר אותם למספרים שלמים קצרים ולשלוח אותם. אבל יכול להיות הוא לא נכון, אז מומלץ לא לעשות זאת כרגע.
- המטען הייעודי (Payload) הוא טקסט בלבד. למרות שאנחנו לא יודעים מה התוכן של השיחה
(נראה שהן משתמשות ב-
"secret-cipher"
), רק מסתכלות על הטקסט מראה שיש הרבה יתירות. אולי במקום לשלוח אותיות שחוזרות על עצמן, אפשר פשוט לספור אותן לקודד אותן בצורה יעילה יותר. לדוגמה,"AAA"
הופך ל-"3A"
, שמייצג רצף של שלושה סימני A.
שילוב השיטות האלה מניב את התוצאה הבאה:
format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A
ההודעה החדשה היא באורך 56 תווים, כלומר דחסת את מֶסֶר מקורי ב-72%. זו הפחתה משמעותית!
זוהי דוגמה צעצוע שממחישה איך אלגוריתמים של דחיסה יכולים להיות יעילים, צמצום גודל ההעברה של משאבים מבוססי-טקסט. בפועל, דחיסת נתונים שהם הרבה יותר מתוחכמים ממה שהדוגמה הקודמת משקפת, באינטרנט, ניתן להשתמש באלגוריתמים של דחיסה כדי להפחית באופן משמעותי את ההורדה המשאבים. על ידי החלת דחיסה על נכסים מבוססי-טקסט, דף אינטרנט יכולים לבזבז פחות זמן על טעינה של משאבים, כך שהמשתמשים יוכלו לראות את ההשפעה של את המשאבים האלה מוקדם יותר ממה שהם היו יכולים בלי דחיסה.
הקטנה: עיבוד מראש ואופטימיזציות ספציפיות להקשר
השיטה הראשונה שמתוארת כאן היא הקטנה. אמנם ההקטנה לא מתבצעת שימוש באלגוריתם דחיסה בלבד, זו דרך להסיר תווים מיותרים בקוד המקור כדי להפוך את המשאבים לקריאים יותר בני אדם. עם זאת, רמת הקריאוּת הזו לא נדרשת כדי לשמור על הפונקציונליות. מקוד המקור הזה באתרים בסביבת הייצור, והוא עלול לעכב את הטעינה של המשאבים באינטרנט.
הקטנה היא סוג של אופטימיזציה ספציפית לתוכן, שיכולה באופן משמעותי לצמצם את גודל המשאבים המוצגים, ומומלץ להשתמש בהם כחלק מתהליך ה-build והפריסה לדוגמה, ב-Bundler תוכנה הכי נפוצה שיכולה להקטין משאבים באופן אוטומטי לפני הפריסה של קוד ייצור חדש באתר.
הדרך הטובה ביותר לדחוס נתונים מיותרים או מיותרים היא להסיר אותם. עם זאת, אי אפשר פשוט למחוק נתונים שרירותיים. עם זאת, בהקשרים מסוימים שבהם יש ידע ספציפי בתוכן לגבי פורמט הנתונים והמאפיינים שלהם, שאפשר לצמצם באופן משמעותי את גודל המטען הייעודי (Payload) בלי להשפיע המשמעות או היכולות האמיתיות שלהם.
<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 הקודם ואת שלושת סוגי התוכן השונים שהוא כולל כולל:
- תגי עיצוב של HTML.
- CSS כדי להתאים אישית את המצגת של דף.
- 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%. אומנם, זה לא ממש קריא, אין חובה להשתמש בו כדי שניתן יהיה להשתמש בו. גם שיטות פיתוח מודרניות לשמור על גרסאות קריאה ופורמט תקין של קוד המקור בנפרד מהקוד המותאם היטב שאתם שולחים לסביבת הייצור. בשילוב עם מפות מקור – שמספקות ייצוג קריא של קוד לסביבת הייצור מאפשר לפתור בקלות רבה יותר באגים בסביבת הייצור — ליהנות מחוויית מפתח טובה ובמקביל לבצע אופטימיזציה של הביצועים של חוויית המשתמש.
הדוגמה הקודמת ממחישה נקודה חשובה: שימוש כללי מכשיר מדחס – למשל, כזה שנועד לדחוס טקסט שרירותי – יכול לעשות לדחוס את הדף בדוגמה הקודמת, אבל הוא לעולם לא ידע להסיר את התגובות, לכווץ כללי CSS או ואופטימיזציות. זו הסיבה לכך שעיבוד מראש, הקטנה והצגה של מודעות מבוססות הקשר אחרות ויש חשיבות רבה לאופטימיזציה.
באופן דומה, ניתן להרחיב את השיטות שתוארו למעלה גם משיטות מבוססות-טקסט בלבד. נכסים דיגיטליים. תמונות, סרטונים וסוגי תוכן אחרים מכילים כולם צורות משלהם מטא-נתונים ומטענים ייעודיים (payloads) שונים. לדוגמה, בכל פעם שמצלמים תמונה עם מצלמה, הקובץ שלו בדרך כלל מטמיע הרבה מידע נוסף: הגדרות המצלמה, המיקום וכו'. בהתאם לאפליקציה, הנתונים האלה עשויים להיות קריטיים (למשל, אתר לשיתוף תמונות) או שהאתר לא יהיה שימושי כלל. שלך לשקול אם כדאי להסיר אותו. בפועל, המטא-נתונים האלה יכולים להוסיף עד עשרות קילובייט לכל תמונה.
בקיצור, כשלב ראשון באופטימיזציה של היעילות של הנכסים, מלאי של סוגי תוכן שונים ולבחון אילו סוגים של תוכן אופטימיזציות ספציפיות לתוכן שניתן להחיל כדי להקטין את גודלן. ואז – אחרי כבר למדתם מהן האופטימיזציות האלה, ונבצע אוטומציה שלהן על ידי הוספתן את שלבי ה-build והגרסה כדי לוודא שהאופטימיזציות מיושמות באופן עקבי לכל גרסה חדשה לסביבת הייצור.
דחיסת טקסט באמצעות אלגוריתמים לדחיסת נתונים
השלב הבא כדי להקטין את הגודל של נכסים מבוססי-טקסט הוא להוסיף את האלגוריתם של הדחיסה אליהם. מתקדמים צעד אחד נוסף באגרסיביות לחפש דפוסים שחוזרים על עצמם במטענים ייעודיים (payloads) מבוססי טקסט לפני שהם שולחים אותם את המשתמש, ולבטל את הדחיסה שלו כשהוא מגיע לדפדפן של המשתמש. כתוצאה מכך היא צמצום נוסף ומשמעותי של משאבים כאלה, זמני הורדה מהירים יותר.
- gzip ו-Brotli הם אלגוריתמים לדחיסה שמשתמשים בהם בדרך כלל, שהביצועים שלהם הם הטובים ביותר נכסים מבוססי-טקסט: CSS, JavaScript, HTML.
- כל הדפדפנים המודרניים תומכים בדחיסת gzip ו-Brotli, והם יפרסמו
תמיכה בשניהם בכותרת של בקשת ה-HTTP
Accept-Encoding
. - יש להגדיר את השרת כדי להפעיל דחיסה. תוכנה לשרת אינטרנט יאפשרו למודולים לדחוס משאבים מבוססי-טקסט כברירת מחדל.
- ניתן לכוונן גם את gzip וגם את Brotli כדי לשפר את יחסי הדחיסה באמצעות להתאים את רמת הדחיסה. עבור gzip, הגדרות הדחיסה נעות בין 1 עד 9, ו-9 הוא הכי טוב. עבור Brotli, הטווח הזה הוא 0 עד 11, כאשר 11 להיות הכי טוב. עם זאת, להגדרות דחיסה גבוהה יותר נדרש יותר זמן. עבור משאבים דחוסים באופן דינמי, כלומר בקשה — הגדרות באמצע הטווח נוטות לתת את הפשרה הטובה ביותר בין יחס הדחיסה למהירות. עם זאת, דחיסה סטטית כי זה אפשרי, כי התגובה דחוסה מראש, ויכולה ולכן להשתמש בהגדרות הדחיסה האגרסיביות ביותר שזמינות לכל את האלגוריתם לדחיסה.
- ברשתות להעברת תוכן (CDN) יש בדרך כלל אפשרות לדחיסה אוטומטית של מקורות מידע שעומדים בקריטריונים. רשתות CDN יכולות לנהל דחיסה דינמית וסטטית עבור כך שיש היבט אחד פחות של דחיסת נתונים שצריך לדאוג לגביו.
gzip ו-Brotli הם אמצעי דחיסה נפוצים שאפשר להחיל על כל זרם של בייטים. הם זוכרים חלק מהתוכן שנבדק בעבר, קובץ, ולאחר מכן לנסות למצוא ולהחליף קטעי נתונים כפולים בדרך יעילה.
בפועל, gzip ו-Brotli משיגים את הביצועים הטובים ביותר בתוכן מבוסס-טקסט, ובדרך כלל משיגים קצב דחיסה של עד 70%-90% לקבצים גדולים. אבל, הרצה של של אלגוריתמים שכבר דחוסים באמצעות אלגוריתמים חלופיים - מכיוון שרוב הפורמטים של תמונות שמשתמשים בטכניקות דחיסה ללא אובדן נתונים או עם איבוד נתונים, מניבות תפוקה שיפור מועט או ללא שיפור.
כל הדפדפנים המודרניים מפרסמים תמיכה ב-gzip וב-Brotli
כותרת בקשת HTTP Accept-Encoding
. עם זאת, המטרה היא
לוודא ששרת האינטרנט מוגדר כראוי כדי לשרת את
משאב דחוס כשהלקוח מבקש אותו.
קובץ | אלגוריתם | גודל לא דחוס | גודל דחוס | יחס דחיסה |
---|---|---|---|---|
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 | ברוטלי | 302 KiB | 69 KiB | 77% |
jquery-3.7.1.js | gzip | 302 KiB | 83 KiB | 73% |
jquery-3.7.1.min.js | ברוטלי | 85 KiB | 27 KiB | 68% |
jquery-3.7.1.min.js | gzip | 85 KiB | 30 KiB | 65% |
lodash-4.17.21.js | ברוטלי | 531 KiB | 73 KiB | 86% |
lodash-4.17.21.js | gzip | 531 KiB | 94 KiB | 82% |
lodash-4.17.21.min.js | ברוטלי | 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.
הפעלת דחיסה היא אחת משיטות האופטימיזציה הפשוטות והאפקטיביות ביותר להטמיע. אם האתר שלך לא מנצל אותה לרעה, אתה מחמיץ הזדמנויות הזדמנות גדולה לשפר את הביצועים של המשתמשים. למרבה המזל, אתרים רבים שרתים שמספקים הגדרות ברירת מחדל שמאפשרות את האופטימיזציה החשובה הזו, ו-CDN בייחוד, יעילים מאוד בהטמעה שלהם איזון בין מהירות הדחיסה ליחס.
דרך מהירה לראות את דחיסת הנתונים בפעולה היא לפתוח את כלי הפיתוח ל-Chrome, רשת, טוענים דף לבחירתכם ומעיינים בתחתית המסך. חלונית הרשת.
![הקראה של גודל ההעברה בפועל לעומת גודל ההעברה בכלי הפיתוח.](https://web.dev/static/articles/optimizing-content-efficiency-optimize-encoding-and-transfer/image/resource-size-fig.png?authuser=5&hl=he)
כמו בתמונה הקודמת, אתם אמורים לראות פירוט של:
- מספר הבקשות, שהוא מספר המשאבים שנטענו עבור הדף הזה.
- גודל ההעברה של כל הבקשות. הדבר משקף את האפקטיביות של דחיסה של כל אחד מהמשאבים בדף.
- גודל המשאב של כל הבקשות. הנתון הזה משקף את הגודל של המשאבים הדפים אחרי פירוק הדחיסה.
ההשפעות על מדדי הליבה לבדיקת חוויית המשתמש באתר
לא ניתן למדוד שיפורי ביצועים אלא אם יש מדדים שמשקפים את השיפורים האלה. מטרת יוזמת מדדי הליבה לבדיקת חוויית המשתמש באתר היא ליצור ולהגביר את המודעות למדדים שמשקפים את חוויית המשתמש בפועל. זאת בניגוד למדדים - כמו זמן טעינה פשוט של דף, לדוגמה - לא מתורגמים בבירור לאיכות של חוויית המשתמש.
כשתיישמו את האופטימיזציות המפורטות במדריך זה על המשאבים ההשפעות על מדדי הליבה לבדיקת חוויית המשתמש באתר עשויות להשתנות בהתאם למשאבים לבצע אופטימיזציה ואת המדדים הקשורים. עם זאת, כאן יש כמה מקרים שבהם יישום האופטימיזציות האלה יכול לשפר את מדדי הליבה לבדיקת חוויית המשתמש באתר שלכם:
- משאבי HTML מוקטנים ודחוסים יכולים לשפר את הטעינה של
את ה-HTML, את יכולת הגילוי של משאבי המשנה שלו, ולכן אפשר לשפר
הטעינה שלהם. האפשרות הזו יכולה להיות שימושית להמהירות שבה נטען רכיב התוכן הכי גדול (LCP) בדף
(LCP). אפשר להשתמש ברמזים של משאבים כמו
rel="preload"
כדי להשפיע על יכולת גילוי של משאבים, שימוש ביותר מדי מהם עלול לגרום לבעיות תחרות בין רוחב פס. על ידי וידוא תגובת ה-HTML לבקשת ניווט דחוסה, כך שניתן יהיה למצוא את המשאבים שבתוכן בהקדם האפשרי. באמצעות סורק הטעינה מראש. - את חלק ממועמדי ה-LCP אפשר גם לטעון מוקדם יותר באמצעות דחיסה. עבור לדוגמה, תמונות SVG שהן מועמדים מסוג LCP יכולות לכלול את טעינת המשאבים שלהן. משך הזמן מקוצר באמצעות דחיסה מבוססת-טקסט. זה שונה מ- שהייתם מבצעים בסוגי תמונות אחרים - דחוסים במהותו באמצעות שיטות דחיסה אחרות - כמו JPEG התמונות משתמשות בדחיסת נתונים מסוג Lossy.
- בנוסף, צומתי טקסט יכולים להיות גם מועמדים מסוג LCP. איך הטכניקות שמתוארת במדריך הזה תלויה בשאלה אם אתם משתמשים בגופן אינטרנט עבור טקסט את דפי האינטרנט שלך. אם משתמשים בגופן אינטרנט, האופטימיזציה הטובה ביותר של גופנים באינטרנט נהלים. עם זאת, אם אתם לא משתמשים בגופנים אינטרנטיים, אלא במערכת גופנים שמוצגים בלי לצבור משך טעינה של משאבים — צמצום דחיסת ה-CSS מקצרת את משך הזמן הזה, כלומר עיבוד של צמתים פוטנציאליים של טקסט LCP יכולים להתרחש מוקדם יותר.
סיכום
הבסיס לאופטימיזציה של הקידוד וההעברה של נכסים מבוססי-טקסט קונספט של ביצועים, אבל יש לו השפעה גדולה. עליך לוודא לעשות את כל מה שאפשר כדי להבטיח שהמשאבים יהיו כשירים להקטנה לדחיסת נתונים מועילות מהאופטימיזציות האלה.
וחשוב יותר, יש לוודא שהתהליכים האלה הם אוטומטיים. עבור הקטנה, שימוש ב-bundler כדי להחיל הקטנה על משאבים שעומדים בדרישות. ודאו שתצורת שרת האינטרנט שלכם תומכת בדחיסה, אבל מעבר לזה, אתם צריכים להשתמש את הדחיסה היעילה ביותר שיש. כדי לעשות את זה טריוויאלי ככל האפשר, להשתמש ברשתות CDN כדי להפוך את הדחיסה באופן אוטומטי, מפני שהן לא רק יכולות לדחוס נתונים בשבילך, אבל הם יכולים לעשות את זה גם מהר מאוד.
על ידי הטמעת המושגים הבסיסיים האלה של הביצועים אפשר לוודא שמאמצי האופטימיזציה של הביצועים בסיס טוב, והאופטימיזציות הבאות יכולות להיות מונחות על בסיס חזק של שיטות בסיסיות מומלצות.