שיפור הביצועים באמצעות רשת להעברת תוכן.
רשתות להעברת תוכן (CDN) משפרות את ביצועי האתר על ידי שימוש ברשת מבוזרת של שרתים לאספקת משאבים למשתמשים. רשתות CDN מפחיתות את העומס על השרת, ולכן הן מפחיתות את עלויות השרת ומתאימות להתמודד עם עליות חדות בתעבורת נתונים. במאמר הזה נסביר איך רשתות CDN פועלות ונספק הדרכה ללא קשר לפלטפורמה: בחירה, הגדרה ואופטימיזציה של הגדרות CDN.
סקירה
רשת להעברת תוכן מורכבת מרשת של שרתים שמותאמים למסירה מהירה של תוכן למשתמשים. אף על פי שרשתות CDN ידועות בדרך כלל להצגת תוכן ששמור במטמון, רשתות CDN יכולות גם לשפר את המסירה של תוכן שלא ניתן לשמור במטמון. באופן כללי, מומלץ להציג יותר תוכן מהאתר על ידי ה-CDN.
ברמה הכללית, יתרונות הביצועים של רשתות CDN נובעים מכמה עקרונות: שרתי CDN ממוקמים קרוב יותר למשתמשים מאשר שרתי מקור, ולכן יש להם זמן אחזור קצר יותר בזמן הלוך ושוב (RTT) קצר יותר; אופטימיזציות של רשתות מאפשרות לרשתות CDN לספק תוכן מהר יותר מאשר אם התוכן נטען "ישירות" משרת המקור; לבסוף, מטמוני CDN מבטלים את הצורך בבקשה לעבור למקור
העברת משאבים
למרות שזה אולי נראה לא אינטואיטיבי, השימוש ב-CDN כדי לספק משאבים (גם כאלה שלא ניתן לשמור במטמון) יהיה בדרך כלל מהיר יותר מאשר שימוש בטעינת המשאב "ישירות" מהשרתים שלכם.
כשמשתמשים ב-CDN כדי להעביר משאבים מהמקור, נוצר חיבור חדש בין הלקוח לשרת CDN בקרבת מקום. שארית התהליך (במילים אחרות, העברת הנתונים בין שרת ה-CDN לבין המקור) מתרחשת ברשת של ה-CDN, שכוללת לעיתים קרובות חיבורים קיימים ועקביים עם המקור. היתרונות בכך הם שניים: סיום החיבור החדש קרוב ככל האפשר למשתמש, מבטל עלויות מיותרות של הגדרת חיבור (יצירת חיבור חדש היא יקרה ודורשת מספר פעולות הלוך ושוב). השימוש בחיבור מחומם מראש מאפשר העברה מיידית של נתונים בתפוקה המקסימלית האפשרית.
רשתות CDN מסוימות משפרים את זה עוד יותר על ידי ניתוב התנועה למקור דרך מספר שרתי CDN שמפוזרים באינטרנט. החיבורים בין שרתי CDN מתרחשים במסלולים אמינים שעברו אופטימיזציה, ולא במסלולים שנקבעו על ידי Border Gateway Protocol (BGP). למרות ש-BGP הוא פרוטוקול הניתוב בפועל של האינטרנט, ההחלטות שלו בנוגע לניתוב לא תמיד מוכוונות ביצועים. לכן, סביר להניח שמסלולים שמוגדרים ל-BGP יהיו פחות ביצועים טובים ממסלולים שעברו כוונון עדין בין שרתי CDN.
שמירה במטמון
שמירת משאבים במטמון בשרתי CDN מבטלת את הצורך בבקשה לעבור את כל הדרך למקור כדי להגיש אותה. כתוצאה מכך, המשאב מועבר מהר יותר ומפחית את העומס על שרת המקור.
הוספת משאבים למטמון
השיטה הנפוצה ביותר לאכלוס מטמון CDN היא להשתמש במשאבי "משיכה" של CDN כפי שהם נחוצים, שנקראת 'משיכת מקור'. בפעם הראשונה שמשאב מסוים מתבקש מהמטמון, ה-CDN יבקש אותו משרת המקור וישמור את התגובה במטמון. באופן הזה, התוכן של המטמון מצטבר לאורך זמן כשמבקשים משאבים נוספים שלא נשמרו.
הסרת משאבים מהמטמון
רשתות CDN משתמשות בניקוי מטמון כדי להסיר מהמטמון מדי פעם משאבים לא כל כך שימושיים. בנוסף, בעלי אתרים יכולים להשתמש במחיקה סופית כדי להסיר משאבים באופן מפורש.
פינוי מטמון
למטמון יש נפח אחסון מוגבל. כשמטמון מתקרב לקיבולת שלו, הוא מפנה מקום למשאבים חדשים על ידי הסרת משאבים שלא בוצעה אליהם גישה לאחרונה או שתופסים הרבה מקום. התהליך הזה נקרא 'ניקוי המטמון'. המשמעות של הסרת משאב ממטמון אחד לא בהכרח אומרת שהוא הוסר מכל המטמון ברשת CDN.
הרמת יד
מחיקה באופן סופי (נקרא גם 'ביטול התוקף של המטמון') היא מנגנון להסרת משאב מהמטמון של CDN בלי להמתין עד שהתוקף שלו יפוג או לצאת ממנו. בדרך כלל היא מופעלת דרך API. מחיקה סופית היא פעולה קריטית במצבים שבהם צריך לבטל תוכן (לדוגמה, לתקן שגיאות הקלדה, שגיאות תמחור או כתבות חדשותיות שגויות). בנוסף, הוא יכול גם למלא תפקיד קריטי באסטרטגיית השמירה במטמון של האתר.
אם רשת CDN תומכת במחיקה מיידית באופן סופי, אפשר להשתמש במחיקה באופן סופי כמנגנון לניהול השמירה של תוכן דינמי במטמון: כדאי לשמור תוכן דינמי באמצעות TTL ארוך, ולאחר מכן למחוק באופן סופי את המשאב בכל פעם שהוא מתעדכן. כך ניתן למקסם את משך השמירה במטמון של משאב דינמי, בלי לדעת מראש מתי המשאב ישתנה. השיטה הזו נקראת לפעמים 'שמירה במטמון עד להמתנה'.
כשמשתמשים במחיקה באופן סופיה בקנה מידה גדול, בדרך כלל משתמשים בה בשילוב עם קונספט שנקרא 'תגי מטמון' או 'מפתחות ללא הצפנה במטמון'. המנגנון הזה מאפשר לבעלי אתרים לשייך מזהה נוסף אחד או יותר (המכונים לפעמים 'תגים') למשאב שנשמר במטמון. לאחר מכן ניתן להשתמש בתגים האלה כדי לבצע מחיקה מפורטת מאוד באופן סופי. לדוגמה, אפשר להוסיף תג "footer" לכל המשאבים (לדוגמה,
/about,/blog) שכוללים את הכותרת התחתונה של האתר. כשהכותרת התחתונה מתעדכנת, צריך להנחות את ה-CDN למחוק באופן סופי את כל המשאבים המשויכים לתג 'footer'.
משאבים שאפשר לשמור במטמון
המידה והאופן שבו צריך לשמור משאב במטמון תלוי בשאלה אם הוא ציבורי או פרטי, סטטי או דינמי.
משאבים פרטיים וציבוריים
משאבים פרטיים
משאבים פרטיים מכילים נתונים שמיועדים למשתמש יחיד ולכן אין לשמור אותם במטמון על ידי CDN. משאבים פרטיים מסומנים באמצעות הכותרת
Cache-Control: private.משאבים ציבוריים
משאבים ציבוריים לא מכילים מידע ספציפי למשתמש ולכן ניתן לשמור אותם במטמון על ידי CDN. משאב יכול להיחשב כניתן לשמירה במטמון על ידי CDN אם אין לו כותרת
Cache-Control: no-storeאוCache-Control: private. משך הזמן שבו אפשר לשמור משאב ציבורי במטמון תלוי בתדירות השינוי של הנכס.
תוכן דינמי וסטטי
תוכן דינמי
תוכן דינמי הוא תוכן שמשתנה לעיתים קרובות. תגובת API ודף הבית של החנות הם דוגמאות לסוג התוכן הזה. עם זאת, העובדה שהתוכן הזה משתנה לעיתים קרובות לא בהכרח מונעת את שמירתו במטמון. במהלך תקופות של עומס כבד, שמירת התגובות האלה במטמון לפרקי זמן קצרים מאוד (למשל, 5 שניות) יכולה להפחית באופן משמעותי את העומס על שרת המקור, תוך השפעה מינימלית על עדכניות הנתונים.
תוכן סטטי
התוכן הסטטי משתנה לעיתים רחוקות, אם בכלל. תמונות, סרטונים וספריות עם גרסאות הן בדרך כלל דוגמאות לסוג התוכן הזה. כיוון שהתוכן הסטטי לא משתנה, צריך לשמור אותו במטמון עם אורך חיים ארוך (TTL) – לדוגמה, 6 חודשים או שנה אחת.
בחירת CDN
בדרך כלל, הביצועים הם שיקול חשוב כשבוחרים CDN. עם זאת, חשוב לשקול את התכונות האחרות שיש ב-CDN (לדוגמה, תכונות אבטחה וניתוח נתונים) וגם את התמחור, התמיכה וההדרכה של CDN.
ביצועים
ברמה הכללית, אפשר לחשוב על אסטרטגיית הביצועים של CDN כדי למצוא את האיזון בין מזעור זמן האחזור להגדלה של יחס ההיט של המטמון. רשתות CDN עם נקודות נוכחות רבות (PoP) יכולות לאפשר זמן אחזור קצר יותר, אבל הן עשויות ליהנות מיחסי היטלים נמוכים יותר במטמון, כתוצאה מפיצול התנועה בין יותר מטמון. לעומת זאת, רשתות CDN עם פחות PoP עשויות להיות ממוקמות גיאוגרפית רחוקים יותר מהמשתמשים, אבל הן יכולות להשיג יחסי היט גבוהים יותר במטמון.
כתוצאה מכך, ברשתות CDN מסוימות משתמשים בגישה מדורגת לשמירה במטמון: ל-PoP שקרובים למשתמשים (שנקראים גם 'מטמוני קצה') נוספים ל-PoP מרכזיים עם יחסי היט גבוהים יותר במטמון. כשמטמון קצה לא מצליח למצוא משאב, הוא מועבר ל-PoP מרכזי של המשאב. גישה זו מחליפה זמן אחזור מעט גדול יותר בסבירות גבוהה יותר שניתן יהיה להציג את המשאב ממטמון CDN - אם כי לא בהכרח מטמון קצה.
יחסי הגומלין בין צמצום זמן האחזור למיקסום יחס ההיטים של המטמון הוא מגוון רחב. אין גישה מסוימת טובה יותר באופן אוניברסלי. עם זאת, בהתאם לאופי האתר ובסיס המשתמשים שלו, ייתכן שתגלו שאחת מהגישות האלו מניבה ביצועים טובים יותר באופן משמעותי מהשיטה השנייה.
חשוב גם לציין שביצועי ה-CDN עשויים להשתנות באופן משמעותי בהתאם למיקום גיאוגרפי, לשעה ביום ואפילו לאירועים אקטואליים. למרות שתמיד כדאי לחקור בעצמכם את הביצועים של CDN, לפעמים קשה לחזות את הביצועים המדויקים שתקבלו מ-CDN.
ההשפעות על Largest Contentful Paint (LCP)
כפי שתואר קודם במאמר הזה, המטרה העיקרית של CDN היא לקצר את זמן האחזור על ידי הפצת משאבים לשרתים שקרובים יותר למשתמשים מבחינה גיאוגרפית. לכן, היתרון העיקרי של CDN הוא שהוא משפר את ביצועי הטעינה. באופן ספציפי, ניתן לשפר באופן משמעותי את Time to First Byte (TTFB) של משאב כשמוסיפים CDN לארכיטקטורה בצד השרת של האתר.
מדד ה-TTDFB הוא לא מדד ביצועים שמתמקד במשתמשים, אבל הוא הוא מדד חשוב לאבחון בעיות באמצעות המהירות שבה נטען רכיב התוכן הכי גדול (LCP), שהוא מדד שמתמקד במשתמשים.
רשתות CDN יעילות במיוחד בשיפור מדד ה-LCP, כי הן יכולות לשפר את מסירת המסמכים (על ידי צמצום נושא ה-TTFB בהגדרת החיבור ובשמירת המסמך במטמון) וגם בשיפור ההעברה של משאבים סטטיים הדרושים לעיבוד של רכיב ה-LCP.
תכונות נוספות
רשתות CDN בדרך כלל מציעות מגוון רחב של תכונות בנוסף להיצעי ה-CDN העיקריים שלהן. דוגמאות לתכונות נפוצות: איזון עומסים, אופטימיזציה של תמונות, וידאו בסטרימינג, מחשוב קצה ומוצרי אבטחה.
איך להגדיר ולהגדיר CDN
באופן אידיאלי, צריך להשתמש ב-CDN כדי לשרת את כל האתר. תהליך ההגדרה ברמה הכללית כולל הרשמה עם ספק CDN, ולאחר מכן עדכון רשומת ה-DNS של ה-CNAME כך שיצביע על ספק ה-CDN. לדוגמה, רשומת ה-CNAME של www.example.com עשויה להצביע על example.my-cdn.com. כתוצאה משינוי ה-DNS, התנועה לאתר שלכם תנותב דרך ה-CDN.
אם אין אפשרות להשתמש ב-CDN למילוי כל המשאבים, ניתן להגדיר CDN כך שיציג רק קבוצת משנה של משאבים – לדוגמה, רק משאבים סטטיים. כדי לעשות זאת, אפשר ליצור רשומת CNAME נפרדת שתשמש רק למשאבים שאמורים להיות מוצגים על ידי ה-CDN. לדוגמה, אפשר ליצור רשומת CNAME static.example.com שמצביעה אל example.my-cdn.com. בנוסף, צריך לשכתב את כתובות ה-URL של המשאבים שמוצגים על ידי ה-CDN כך שיצביעו על תת-הדומיין static.example.com שיצרתם.
אף על פי שה-CDN שלכם יוגדר בשלב הזה, סביר להניח שההגדרות שלכם לא ייפגעו. בשני הקטעים הבאים של מאמר זה מוסבר איך להפיק את המרב מה-CDN שלכם על ידי הגדלת יחס ההיט של המטמון והפעלת תכונות ביצועים.
שיפור יחס ההיטים של המטמון
הגדרה יעילה של CDN תציג משאבים רבים ככל האפשר מהמטמון. המדד הזה בדרך כלל נמדד לפי יחס ההיט של המטמון (CHR). יחס ההתאמה של המטמון מוגדר כמספר ההיטים של המטמון חלקי מספר הבקשות הכולל במהלך פרק זמן נתון.
למטמון שאתחל לאחרונה יהיה CHR של 0, אבל הערך הזה גדל ככל שהמטמון מאוכלס במשאבים. ערך CHR של 90% הוא יעד טוב לרוב האתרים. ספק ה-CDN שלכם אמור לספק לכם ניתוח נתונים ודוחות לגבי ה-CHR.
כשמבצעים אופטימיזציה של CHR, הדבר הראשון שצריך לוודא הוא שכל המשאבים שניתן לשמור במטמון נשמרים במטמון למשך פרק הזמן הנכון. זוהי הערכה פשוטה שצריך לבצע בכל האתרים.
באופן כללי, הרמה הבאה של אופטימיזציית CHR היא כוונון עדין של הגדרות ה-CDN כדי לוודא שתגובות שרת שוות ערך מבחינה לוגית לא נשמרות בנפרד. זהו חוסר יעילות נפוץ שמתרחש עקב ההשפעה של גורמים כמו פרמטרים של שאילתות, קובצי Cookie וכותרות של בקשות על השמירה במטמון.
בדיקה ראשונית
רוב רשתות ה-CDN יספקו ניתוח של נתוני המטמון. בנוסף, ניתן להשתמש בכלים כמו WebPageTest ו-Lighthouse כדי לאמת במהירות שכל המשאבים הסטטיים בדף נשמרים במטמון למשך הזמן הנכון. ניתן לעשות זאת על ידי בדיקת הכותרות של מטמון ה-HTTP של כל משאב. שמירה של משאב במטמון תוך שימוש באורך המקסימלי המתאים של אורך החיים (TTL) תמנע אחזורים לא נחוצים של מקורות בעתיד, וכתוצאה מכך תגרום להגדלת ה-CHR.
לכל הפחות, צריך להגדיר בדרך כלל אחת מהכותרות הבאות כדי שהמשאב יישמר במטמון על ידי CDN:
Cache-Control: max-age=Cache-Control: s-maxage=Expires
בנוסף, למרות שהדבר לא משפיע על האופן שבו משאב נשמר במטמון על ידי CDN או על האופן שבו הוא נשמר במטמון על ידי CDN, מומלץ להגדיר גם את ההוראה Cache-Control: immutable.Cache-Control: immutable מציין שהמשאב "לא יעודכן במהלך חיי עדכניותו". כתוצאה מכך, הדפדפן לא יאשר מחדש את המשאב בעת הצגתו מהמטמון של הדפדפן, ובכך יבטל בקשת שרת מיותרת. לצערנו, ההוראה הזו נתמכת רק על ידי Firefox ו-Safari - היא לא נתמכת בדפדפנים המבוססים על Chromium. הבעיה הזו עוקבת אחרי התמיכה של Chromium ב-Cache-Control: immutable. סימון הבעיה הזו בכוכב יכול לעזור לעודד תמיכה בתכונה הזו.
להסבר מפורט יותר לגבי שמירה במטמון של HTTP, ראו מניעת בקשות רשת לא נחוצות באמצעות מטמון HTTP.
כוונון עדין
הסבר מעט פשוט על האופן שבו פועלים מטמון של CDN הוא שכתובת ה-URL של משאב משמשת כמפתח לשמירה במטמון ולאחזור המשאב מהמטמון. בפועל, זה עדיין נכון באופן כללי, אבל הוא קצת מורכב מההשפעה של גורמים כמו כותרות של בקשות ופרמטרים של שאילתות. כתוצאה מכך, שכתוב של כתובות ה-URL של הבקשות הוא שיטה חשובה גם למיקסום ה-CHR וגם להבטיח שהתוכן הנכון יוצג למשתמשים. מכונת CDN שהוגדרה כראוי יוצרת את האיזון הנכון בין שמירה מפורטת מדי במטמון (שפוגעת ב-CHR) לבין שמירה לא מפורטת מספיק במטמון (וכתוצאה מכך מוצגות למשתמשים תגובות שגויות).
פרמטרים של שאילתות
כברירת מחדל, רשתות CDN מביאות בחשבון פרמטרים של שאילתה כששומרים משאב במטמון. עם זאת, לשינויים קלים בטיפול בפרמטרים של השאילתות יכולה להיות השפעה משמעותית על ה-CHR. למשל:
פרמטרים מיותרים של שאילתות
כברירת מחדל, CDN ישמור במטמון
example.com/blogו-example.com/blog?referral_id=2zjkבנפרד, על אף שסביר להניח שהם אותו משאב בסיסי. כדי לפתור את הבעיה, משנים את ההגדרות של CDN כך שיתעלם מהפרמטר של השאילתהreferral\_id.סדר הפרמטרים של השאילתה
CDN ישמור במטמון
example.com/blog?id=123&query=dogsבנפרד מ-example.com/blog?query=dogs&id=123. ברוב האתרים אין חשיבות לסדר הפרמטרים של השאילתות, לכן הגדרת ה-CDN למיון הפרמטרים של השאילתה (כך נירמול כתובת ה-URL שמשמשת למטמון של תגובת השרת) תגדיל את ה-CHR.
שינוי
כותרת התגובה Vary מיידעת את המטמון כך שתגובת השרת שתואמת לכתובת URL מסוימת עשויה להשתנות בהתאם לכותרות שהוגדרו בבקשה (לדוגמה, כותרות הבקשה Accept-Language או Accept-Encoding). לכן, הוא מורה ל-CDN לשמור את התגובות האלה במטמון בנפרד. הכותרת Vary לא נתמכת באופן נרחב על ידי רשתות CDN, והיא עלולה לגרום לכך שמשאב שניתן לשמור במטמון לא יוצג מהמטמון.
הכותרת Vary יכולה להיות כלי שימושי, אבל שימוש בלתי הולם פוגע ב-CHR. בנוסף, אם משתמשים ב-Vary, נירמול של כותרות הבקשות יעזור לשפר את ה-CHR. לדוגמה, ללא נירמול, כותרות הבקשה Accept-Language: en-US ו-Accept-Language: en-US,en;q=0.9 יובילו לשתי רשומות מטמון נפרדות, למרות שהתוכן שלהן כנראה יהיה זהה.
עוגיות
קובצי cookie מוגדרים בבקשות דרך הכותרת Cookie. הם מוגדרים בתשובות דרך הכותרת Set-Cookie. יש להימנע משימוש לא נחוץ בכותרת Set-Cookie כי המטמון בדרך כלל לא כולל תגובות של השרת במטמון שמכילות את הכותרת הזו.
תכונות לשיפור הביצועים
בקטע הזה נפרט על תכונות הביצועים שזמינות בדרך כלל ברשתות CDN כחלק מהיצע המוצרים העיקרי שלהן. אתרים רבים שוכחים להפעיל את התכונות האלה, וכתוצאה מכך מפסידים רווחים קלים בביצועים.
דחיסה
כל התשובות מבוססות-הטקסט צריכות להיות דחוסות באמצעות gzip או Brotli. אם יש לכם אפשרות, עדיף לבחור ב-Brotli ולא ב-gzip. Brotli הוא אלגוריתם דחיסה חדש יותר, ובהשוואה ל-gzip הוא יכול להשיג יחסי דחיסה גבוהים יותר.
יש שני סוגים של תמיכה ב-CDN לדחיסת Brotli: 'Brotli ממקור' ו'דחיסת Brotli אוטומטית'.
Brotli ממקור
Brotli ממקור הנתונים כאשר CDN מציג משאבים שנדחסו באמצעות Brotli מהמקור. למרות שזה אולי נראה כמו תכונה שכל רשתות ה-CDN צריכות לתמוך בה מחוץ לאריזה, היא דורשת ש-CDN יוכל לשמור במטמון מספר גרסאות (במילים אחרות, גרסאות דחוסות ב-gzip ובדחוס Brotli) של המשאב שמתאים לכתובת URL נתונה.
דחיסת Brotli אוטומטית
דחיסה אוטומטית של Brotli מתבצעת כשמשאבים דחוסים על ידי Brotli על ידי ה-CDN. רשתות CDN יכולות לדחוס משאבים גם במטמון וגם משאבים שלא ניתן לשמור.
בפעם הראשונה שמשאב מבוקש, הוא מוצג באמצעות דחיסת נתונים "טובה מספיק" – לדוגמה, Brotli-5. סוג זה של דחיסה חל גם על משאבים שניתן לשמור במטמון וגם על משאבים שאינם ניתנים לשמירה.
בינתיים, אם משאב ניתן לשמירה, רשת ה-CDN תשתמש בעיבוד אופליין כדי לדחוס את המשאב ברמת דחיסה חזקה יותר אבל איטית יותר – למשל, Brotli-11. לאחר השלמת הדחיסה, הגרסה הדחוסה יותר תישמר במטמון ותשמש לבקשות הבאות.
שיטות מומלצות לדחיסה
אתרים שרוצים למקסם את הביצועים צריכים להחיל דחיסת Brotli גם בשרת המקור וגם ב-CDN. דחיסת Brotli במקור מצמצמת את גודל ההעברה של משאבים שאי אפשר להציג מהמטמון. כדי למנוע עיכובים בבקשות למילוי בקשות, המקור צריך לדחוס משאבים דינמיים באמצעות רמת דחיסה שמרנית למדי – לדוגמה, Brotli-4. ניתן לדחוס משאבים סטטיים באמצעות Brotli-11. אם המקור לא תומך ב-Brotli, ניתן להשתמש ב-gzip-6 כדי לדחוס משאבים דינמיים. אפשר להשתמש ב-gzip-9 כדי לדחוס משאבים סטטיים.
TLS 1.3
TLS 1.3 הוא הגרסה החדשה ביותר של Transport Layer Security (TLS), הפרוטוקול הקריפטוגרפי שמשמש את HTTPS. TLS 1.3 מספק פרטיות וביצועים טובים יותר בהשוואה ל-TLS 1.2.
TLS 1.3 מקצר את לחיצת היד של TLS משני דו-שלביים לשניים. בחיבורים שמשתמשים ב-HTTP/1 או ב-HTTP/2, קיצור לחיצת היד של TLS לחזרה אחת הלוך ושוב מפחית ביעילות את זמן הגדרת החיבור ב-33%.
HTTP/2 ו-HTTP/3
גם HTTP/2 וגם HTTP/3 מספקים יתרונות ביצועים על פני HTTP/1. מבין השניים, HTTP/3 מציע יתרונות פוטנציאליים גדולים יותר מבחינת ביצועים. HTTP/3 עדיין לא סטנדרטי באופן מלא, אבל ברגע שזה יקרה תהיה לו תמיכה רחבה.
HTTP/2
אם HTTP/2 לא מופעל כבר ב-CDN כברירת מחדל, כדאי להפעיל אותו. ל-HTTP/2 יש מספר יתרונות ביצועים על פני HTTP/1 והוא נתמך בכל הדפדפנים המובילים. תכונות הביצועים של HTTP/2 כוללות: ריבוב, תעדוף סטרימינג ודחיסת כותרות.
Multiplexing
נטען כי ריבוי קטעים הוא התכונה החשובה ביותר של HTTP/2. ריבוב מאפשר חיבור TCP יחיד לשרת כמה צמדים של בקשה-תגובה בו-זמנית. הפעולה הזו מבטלת את התקורה של הגדרות חיבור מיותרות; מכיוון שמספר החיבורים שהדפדפן יכול לפתוח בכל רגע נתון הוא מוגבל, ולכן ייתכן שהדפדפן יכול לבקש יותר משאבים בדף במקביל. שיטת הריבוי עיבודים מסירה את הצורך באופטימיזציות של HTTP/1, כמו שרשור וגיליונות sprite. עם זאת, בפועל הטכניקות האלה ימשיכו להיות רלוונטיות כי קבצים גדולים יותר יידחסו טוב יותר.
תעדוף של סטרימינג
ריבוי שידור מאפשר לשדר כמה שידורים בו-זמנית. תעדוף של זרמים מספק ממשק להעברת עדיפות יחסית של כל אחד מהשידורים האלה. כך השרת יכול לשלוח קודם את המשאבים החשובים ביותר – גם אם הם לא ביקשו אותם קודם.
תעדוף השידור מתבטא על ידי הדפדפן באמצעות עץ תלות, והוא רק הצהרת העדפה: במילים אחרות, השרת לא מחויב לעמוד (או אפילו לקחת בחשבון) את העדיפויות של הדפדפן. תעדוף של שידורים חיים יעיל יותר כשכמות גדולה יותר של אתרים מוצגת דרך CDN.
בהטמעות CDN של תעדוף משאבי HTTP/2 יש הבדלים משמעותיים. כדי לזהות אם רשת ה-CDN תומכת באופן מלא ונכון בתעדוף משאבים של HTTP/2, אפשר לעיין בקטע Is HTTP/2 FastYt?
למרות ששינוי מופע ה-CDN ל-HTTP/2 הוא בעיקר פשוט של הפיכת מתג, חשוב לבדוק באופן יסודי את השינוי הזה לפני שמפעילים אותו בסביבת ייצור. HTTP/1 ו-HTTP/2 משתמשים באותן מוסכמות לגבי כותרות של בקשות ושל תגובות, אבל HTTP/2 הרבה יותר פחות סלקטיבי כשלא פועלים לפי המוסכמות האלה. כתוצאה מכך, שיטות עבודה שלא מתייחסות למפרט, כמו הכללת תווים שאינם ASCII או תווים באותיות רישיות בכותרות, עלולות להתחיל לגרום לשגיאות ברגע ש-HTTP/2 מופעל. במקרה כזה, הניסיונות של הדפדפן להוריד את המשאב ייכשלו. ניסיון ההורדה שנכשל יופיע בכרטיסייה 'רשת' בכלי הפיתוח. בנוסף, הודעת השגיאה "ERR_HTTP2_PROTOCOL_ERROR" תוצג במסוף.
HTTP/3
HTTP/3 הוא התחליף ל-HTTP/2. החל מספטמבר 2020, בכל הדפדפנים המובילים יש תמיכה ניסיונית ב-HTTP/3, וחלק מרשתות ה-CDN תומכות בו. ביצועים הם היתרון העיקרי של HTTP/3 על פני HTTP/2. באופן ספציפי, HTTP/3 מבטל את חסימת הראש (head-line) ברמת החיבור ומקצר את זמן הגדרת החיבור.
ביטול של חסימת 'ראש הדף'
ב-HTTP/2 הושקה פיצ'ר עם ריבוי עיבודים, שמאפשר להשתמש בחיבור יחיד כדי לשדר מספר מקורות נתונים בו-זמנית. עם זאת, במקרה של HTTP/2, חבילה אחת שהושגה חוסמת את כל הסטרימינג בחיבור (תופעה שנקראת 'חסימת כותרת'). באמצעות HTTP/3, חבילה שהושגה חוסמת רק שידור אחד. השיפור הזה בדרך כלל תוצאה של שימוש ב-HTTP/3 באמצעות UDP (ב-HTTP/3 נעשה שימוש ב-UDP דרך QUIC), ולא ב-TCP. כך HTTP/3 שימושי במיוחד להעברת נתונים ברשתות עמוסות או עם אובדן נתונים.
קיצור זמן ההגדרה של החיבור
פרוטוקול HTTP/3 משתמש ב-TLS 1.3 ולכן יש לו יתרונות מבחינת ביצועים: יצירת חיבור חדש דורשת רק הלוך ושוב אחד, ולהמשך של חיבור קיים אין צורך בפעולות הלוך ושוב.
ל-HTTP/3 תהיה ההשפעה הגדולה ביותר על משתמשים בחיבורי רשת חלשים: לא רק ש-HTTP/3 מטפל באובדן מנות טוב יותר מקודמותיו, אלא גם מפני שהחיסכון המוחלט בזמן כתוצאה מהגדרה של 0-RTT או 1-RTT יהיה גדול יותר ברשתות עם זמן אחזור ארוך.
אופטימיזציה של תמונות
שירותי אופטימיזציה של תמונות באמצעות CDN מתמקדים בדרך כלל באופטימיזציות של תמונות שניתן להחיל באופן אוטומטי כדי להקטין את גודל העברת התמונות. לדוגמה: הסרת נתוני EXIF, החלת דחיסה ללא אובדן נתונים והמרת תמונות לפורמטים חדשים יותר של קבצים (לדוגמה, WebP). תמונות מהוות כ-50% מהבייטים שמועברים בדף האינטרנט החציוני, כך שאופטימיזציה של תמונות יכולה להקטין באופן משמעותי את גודל הדף.
הקטנה
תכונת ההקטנה מסירה תווים מיותרים מ-JavaScript, מ-CSS ומ-HTML. עדיף לבצע הקטנה בשרת המקור ולא ב-CDN. לבעלי אתרים יש הקשר נוסף לגבי הקוד שיש להקטין אותו, ולכן הם יכולים לעיתים קרובות להשתמש בשיטות הקטנה אגרסיביות יותר מאלה שבהן משתמשים ברשתות CDN. עם זאת, אם לא ניתן הקטנת קוד במקור, הקטנה באמצעות ה-CDN היא חלופה טובה.
סיכום
- שימוש ב-CDN: רשתות CDN מספקות משאבים במהירות, מפחיתות את העומס על שרת המקור ועוזרות להתמודד עם עליות חדות בתנועה.
- כדאי לשמור תוכן במטמון באופן אגרסיבי ככל האפשר: אפשר וצריך לשמור תוכן דינמי וגם תוכן סטטי במטמון, אבל לפרקי זמן שונים. מומלץ לבדוק את האתר מדי פעם כדי לוודא שהתוכן נשמר במטמון באופן אופטימלי.
- הפעלת תכונות לשיפור הביצועים של CDN: תכונות כמו Brotli , TLS 1.3 , HTTP/2 ו-HTTP/3 משפרות את הביצועים עוד יותר.