איך CDN יכול להשפיע על מהירות האתר שלך

CDN  – סקירה כללית 

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

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

אספקת תוכן ומשאבים בעזרת CDN 

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

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

מטמון במערכות CDN 

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

הוספת משאבים למטמון התוכן ב- CDN

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

הסרת משאבים מהמטמון בעזרת תוכן CDN 

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

פינוי מטמון תוכן CDN 

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

ניקוי תוכן CDN 

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

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

משאבים הניתנים להטמנה

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

משאבים פרטיים וציבוריים

פרטיים

משאבים אלה מכילים נתונים המיועדים למשתמש יחיד ולכן אסור לשמור אותם במטמון באמצעות CDN. הם מסומנים על ידי כותרת Cache-Control פרטית.

ציבוריים

משאבים אלה אינם מכילים מידע ספציפי למשתמש ולכן הם ניתנים לשמירה על ידי -CDN . משאב עשוי להיחשב כמטמון על ידי CDN אם אין לו Cache-Control: no-store או Cache-Control: כותרת פרטית. משך הזמן בו ניתן לשמור מטמון ציבורי תלוי בתדירות ההחלפה של הנכס.

תוכן דינמי וסטטי

תוכן דינמי

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

תוכן סטטי

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

בחירת תוכן CDN 

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

ביצועים

ניתן לחשוב על אסטרטגיית הביצועים של CDN במונחים של פשרה בין מזעור זמן טעינה למקסימום יחס פגיעת מטמון. מערכות CDN עם נקודות נוכחות רבות (PoPs) יכולות לספק זמן תגובה/אחזור נמוך יותר. אך הן עשויות לחוות יחסי מטמון נמוכים יותר כתוצאה מפיזור התנועה על פני יותר מטמונים. לעומת זאת, מערכות CDN עם ​​פחות PoPs עשויות להיות ממוקמות גיאוגרפית רחוק יותר מהמשתמשים, אך יכולות להשיג יחסי מטמון גבוהים יותר. כתוצאה מהפרדה זו ישנן מערכות    CDN  המשתמשות בגישה מדורגת במטמון PoPs וממוקמות קרוב למשתמשים (המכונים גם “מטמוני קצה”). מטמון קצה לא יכול למצוא משאב, הוא יחפש PoP מרכזי עבור המשאב. גישה זו מחליפה זמן אחזור גדול יותר בסבירות גבוהה יותר, כך שניתן להגיש את המשאב ממטמון– CDN, אם כי לא בהכרח מדובר במטמון קצה.

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

מאפיינים נוספים לתוכן CDN 

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

איך להתקין ולהגדיר CDN

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

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

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

שיפור יחס התאמת המטמון

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

בדיקה ראשונית של תוכן CDN 

מרבית רשתות ה- CDN -יספקו ניתוח מטמון. בנוסף, כלים כמו WebPageTest ו- Lighthouse יכולים לשמש אתכם בנוסף כדי לוודא במהירות שכל המשאבים הסטטיים של הדף נשמרים למשך הזמן הנכון. פעולה זו נעשית על ידי בדיקת כותרות המטמון של HTTP של כל משאב. אחסון במטמון במשאב תוך שימוש במקסימום זמן מתאים לחיים (TTL) ימנע אחזור מקור מיותר בעתיד ולכן יגדיל את ה. CHR –
בנוסף, מומלץ להשתמש גם בהגדרת ההוראה . Cache-Control: immutable כתוצאה מכך, הדפדפן לא יאבד את המשאב בעת ״שליפתו״ ממטמון הדפדפן ובכך יבטל בקשת שרת מיותרת. למרבה הצער, הנחיה זו נתמכת רק על ידי Firefox ו- Safari – ולא על ידי דפדפנים מבוססי .Chromium 

כיוונון איכותי של תוכן CDN 

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

פרמטרים

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

פרמטרים לא רצויים

כברירת מחדל CDN יאחסן במטמון את example.com/blog ו- example.com/blog?referral_id=2zjk  בנפרד, למרות שהם ככל הנראה אותו משאב בסיסי. פעולה זו מתוקנת על ידי התאמת תצורת CDN כדי להתעלם מפרמטר השאילתא של ההפניה.

סדר פרמטר

CDN  יאחסן במטמון את example.com/blog?id=123&query=dogs בנפרד מ-  example.com/blog?query=dogs&id=123  . עבור מרבית האתרים סדר הפעולה אינו משנה ולכן קביעת התצורה של ה CDN למיון פרמטר הבקשה יגדיל את ה- CHR. 

משתנה (Vary) 

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

Cookies

קובצי Cookie מוגדרים לפי דרישה דרך כותרת ה-Cookie ומוגדרים בתגובות דרך כותרת Set-Cookie. לרוב רצוי להימנע משימוש בכותרת Set-Cookie מכיוון שמטמונים בדרך כלל מתעלמים מתשובות השרת במטמון המכילות כותרת זו.

מאפייני ביצועי תוכן CDN 

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

דחיסה

יש לדחוס את כל התגובות מבוססות הטקסט באמצעות gzip או עם ברוטלי .(Brotli) אם יש לכם אפשרות, רצוי לבחור ברוטלי על פני .gzip ברוטלי הוא אלגוריתם דחיסה חדש יותר ובהשוואה ל  gzip-  הוא יכול להשיג יחסי דחיסה גבוהים יותר.
ישנם שני סוגים של תמיכה ב- CDN לדחיסת ברוטלי: “ברוטלי מהמקור” ו”דחיסת ברוטלי אוטומטית”.

ברוטלי ממקור

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

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

דחיסת ברוטלי אוטומטית

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

שיטות דחיסה מומלצות לתוכן CDN 

אתרים שרוצים להשיג ביצועים מקסימליים צריכים להחיל דחיסת Brotli הן בשרת המקור והן ב-  CDN . דחיסת ברוטלי במקור ממזערת את גודל ההעברה של המשאבים שלא ניתן לשלוף מהמטמון. כדי למנוע עיכובים בהגשת בקשות המקור צריך לדחוס משאבים דינמיים באמצעות רמת דחיסה שמרנית למדי. למשל .Brotli-4, ניתן לדחוס משאבים סטטיים באמצעות .Brotli-11 אם המקור אינו תומך בברוטלי ניתן להשתמש ב- gzip-6 לדחיסת משאבים דינמיים וב- gzip-9 לדחיסת משאבים סטטיים.

TLS 1.3

 TLS 1.3 היא הגרסה החדשה ביותר של .Transport Layer Security (TLS) פרוטוקול ההצפנה המשמש HTTP מספק פרטיות וביצועים טובים יותר בהשוואה ל.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/2

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

ריבוב

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

עדיפות זרימה

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

השרת אינו מתחייב לבצע (או לשקול) את העדיפויות שמספק הדפדפן. עדיפות הזרם הופכת ליעילה יותר כאשר קיימים מספר אתרים המוגשים באמצעות ב.CDN
למרות שהחיבור של ה- CDN שלכם ל- HTTP/2 כרוך רק בהפיכת מתג, חשוב לבדוק היטב את השינוי לפני שתאפשרו אותו בייצור HTTP/1 .ו HTTP/2 משתמשים באותן מוסכמות לכותרות בקשה ותגובה,  אך HTTP/2- הרבה פחות סלחני כאשר לא מקפידים על מוסכמות אלה. כתוצאה מכך, שיטות שאינן מפרט כגון הכללת תווים שאינם ASCII או אותיות גדולות בכותרות, עלולות לגרום לשגיאות לאחר הפעלת .HTTP/2 אם זה קורה, ניסיונות הדפדפן להוריד את המשאב ייכשלו. ניסיון ההורדה שנכשל יופיע בכרטיסייה “רשת” ב .DevTools- בנוסף, הודעת השגיאה “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 באמצעותHTTP/3) ,UDP  משתמש ב- UDP באמצעות (QUIC ולא ב- .TCP זה הופך את HTTP/3 שימושי במיוחד להעברת נתונים ברשתות עמוסות או אובדן.

הפחתת זמן הגדרת חיבור

 HTTP/3 משתמש ב TLS 1.3 ולכן חולק את יתרונות הביצועים שלה. יצירת חיבור חדש דורשת רק הלוך-חזור יחיד, אך חידוש חיבור קיים אינו מצריך זאת.
ל- HTTP/3 תהיה ההשפעה הגדולה ביותר על המשתמשים על חיבורי רשת גרועים: לא רק מכיוון ש- HTTP/3 מטפל באובדן מנות בצורה טובה יותר מקודמיו, אלא גם מכיוון שחיסכון הזמן המוחלט הנובע מהתקנת חיבור 0-RTT או 1RTT יהיה גדול יותר ברשתות עם חביון גבוה.

מיטוב תמונה

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

צמצום

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

סיכום

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

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

שפרו את הביצועים של האתר שלכם: תכונות כמו Brotli, TLS 1.3, HTTP/2 ו HTTP/3- משפרות את הביצועים עוד יותר ואת מהירות האתר בפרט.