רשתות להעברת תוכן (CDN)

לשפר את הביצועים באמצעות רשת להעברת תוכן.

רשתות להעברת תוכן (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 היא שימוש במשאבי "pull" של 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 מרכזי עם יחסי היטלים גבוהים יותר. אם מטמון קצה לא מצליח לאתר משאב, הוא יחפש נקודת מכירה מרכזית של המשאב. בגישה הזו מחליפים את זמן האחזור מעט יותר גדול יותר סבירות גבוהה יותר שהמשאב יוצג ממטמון CDN – אבל לא בהכרח מטמון קצה.

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

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

ההשפעות על Largest Contentful Paint (LCP)

כפי שתואר קודם במאמר זה, המטרה העיקרית של CDN היא להפחית את זמן האחזור על ידי חלוקת משאבים לשרתים שנמצאים בקרבת משתמשים מבחינה גיאוגרפית. לכן היתרון העיקרי של CDN הוא שהוא משפר את ביצועי הטעינה. באופן ספציפי, אפשר לשפר באופן משמעותי את Time to First Byte (TTFB) של משאב מסוים כשמוסיפים CDN לארכיטקטורת האתר בצד השרת.

TTFB הוא לא מדד ביצועים שמתמקד במשתמשים, אבל הוא הוא מדד חשוב לאבחון בעיות בכלי המהירות שבה נטען רכיב התוכן הכי גדול (LCP), שהוא מדד שמתמקד במשתמשים.

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

תכונות נוספות

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

כיצד להגדיר ולהגדיר CDN

עדיף להשתמש ב-CDN כדי לשרת את האתר כולו. ברמה הכללית, תהליך ההגדרה לשם כך כולל הרשמה לספק CDN, ולאחר מכן עדכון רשומת ה-CNAME DNS כך שתצביע אל ספק ה-CDN. לדוגמה, רשומת ה-CNAME של www.example.com עשויה להצביע על example.my-cdn.com. כתוצאה משינוי זה ב-DNS, התנועה לאתר שלך תנותב דרך ה-CDN.

אם אין אפשרות להשתמש ב-CDN כדי לשרת את כל המשאבים, ניתן להגדיר CDN לשרת רק קבוצת משנה של משאבים - לדוגמה, רק משאבים סטטיים. ניתן לעשות זאת על ידי יצירה של רשומת CNAME נפרדת שתשמש רק למשאבים שיוצגו על ידי ה-CDN. לדוגמה, אפשר ליצור רשומת static.example.com CNAME שמפנה אל 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 או על האופן שבו הוא נשמר, מומלץ גם להגדיר את ההוראה Cache-Control: immutable.Cache-Control: immutable מציינת שהמשאב "לא יעודכן במהלך חיי הרענון שלו". כתוצאה מכך, הדפדפן לא יאמת מחדש את המשאב בעת ההגשה שלו מהמטמון של הדפדפן, ויבטל בקשת שרת מיותרת. לצערנו, הוראה זו נתמכת רק על ידי Firefox ו-Safari, והיא אינה נתמכת בדפדפנים מבוססי Chromium. הבעיה הזו עוקבת אחרי התמיכה ב-Chromium ב-Cache-Control: immutable. סימון הבעיה בכוכב יכול לעזור לעודד תמיכה בתכונה הזו.

להסבר מפורט יותר על שמירת HTTP במטמון 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 אינה נתמכת באופן נרחב על ידי CDNs, והיא עלולה לגרום לכך שמשאב אחר שניתן לשמור במטמון לא יוצג מהמטמון.

הכותרת 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

אם ה-CDN לא הפעיל כבר HTTP/2 כברירת מחדל, מומלץ להפעיל אותו. ל-HTTP/2 יש כמה יתרונות ביצועים ב-HTTP/1, והוא נתמך בכל הדפדפנים המובילים. תכונות הביצועים של HTTP/2 כוללות: ריבוב, תעדוף של סטרימינג ודחיסת כותרת.

• ריבוב

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

• מתן עדיפות לשידור

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

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

הטמעות CDN של תעדוף משאבים של HTTP/2 משתנות באופן משמעותי. כדי לבדוק אם ה-CDN שלכם תומך באופן מלא ונכון בתעדוף משאבים של HTTP/2, ניתן לעיין במאמר האם HTTP/2 מהיר עוד?.

למרות שהעברת מכונת ה-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 מבטל את החסימה של חיבור 'ראש הקו' ברמת החיבור ומקצר את זמן ההגדרה של החיבור.

• ביטול חסימה של 'כותרת ראשית'

  ב-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 משפרות עוד יותר את הביצועים.