מהירות ואופטימיזציה בעידן ה HTTP/2

מהם היתרונות, ומהם השינויים שיש לבצע במעבר ל HTTP/2 ברמת אופטימיזציה למהירות האתר.

פרוטוקול HTTP קיים בערך משנת 1991. פרוטוקול תקשורת זה קיבל שידרוג משמעותי בשנת 1999 כאשר HTTP/1.1 הגיח לעולם. מאז שוחרר פרוטוקול זה הרבה מאד מאמרים ומדריכים שוחררו לרשת בכדי להסביר כיצד להערים ולנסות לכפר על מגרעות ברמת ביצועים של פרוטוקול זה, וישנם לא מעט מגרעות…

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

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

אז מה חדש ב HTTP/2?

ניתן מבט בהרחבה על מה חדש ב HTTP/2 ואיך זה מתבטא בשיפור ביצועים בכלל האתרים (לעניינו אתרי וורדפרס…)

Multiplexing

זהו ללא ספק הפיצ׳ר המשמעותי ביותר ב HTTP/2 המספק פתרון עבור אחת הבעיות המרכזיות (head-of-line blocking) שקיימות בפרוטוקול HTTP/1.1. אם נפשט את הבעיה למספר מילים נאמר כי אך ורק בקשה אחת יכולה להתקבל בחיבור מסויים בזמן נתון, מה שגורם להרבה עכבות (latency). במילים אחרות, הבקשה לנכס נוסף, בין אם זה תמונה, קובץ css או קובץ javascript, יכולה להתרחש אך ורק לאחר שהתקבלה התגובה לנכס הנוכחי מה שגורם למעין ״תור״ (queue) של נכסים שהדפדפן נדרש להוריד מהשרת.

בניסיון לעקוף מכשול זה, דפדפנים מנסים לפתוח מספר חיבורים (TCP Connections) ובכך מאפשרים להוריד מספר נכסים במקביל. אך דפדפנים מוגבלים במספר החיבורים אותם יכולים לפתוח בו זמנית. זה בד״כ נע בין 2-8 חיבורים וזאת בהתאם לדפדפן ובכדי לא להציף את התעבורה ברשת.

מתברר לי אגב (ברגע זה) כי עצם פתיחת חיבור חדש על יד הדפדפן גורמת ל latency, במיוחד כאשר החיבור הוא HTTPS.

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

אתם יכולים לראות את ההשפעה שיש ל multiplexing בתמונות מטה. פרוטוקול HTTP/1.1 מתחיל להוריד נכסים אך ורק כאשר יש לו חיבור TCP פנוי:

http1-waterfall-test

לעמות זאת, HTTP/2 מוריד נכסים אלו במקביל:

http2-waterfall-test

HPACK Header Compression

לכל בקשת HTTP קיים Header המאפשר לשרת ולדפדפן להוסיף מידע נוסף לבקשת או לתגובת ה HTTP. תגובה טיפוסית מ https://he.savvy.co.il/blog תחזיר את header הבא:

accept-ranges:bytes
cache-control:max-age=31536000, public
content-length:37534
content-type:image/jpeg
date:Sat, 21 Oct 2017 09:12:12 GMT
expires:Sun, 21 Oct 2018 09:12:12 GMT
last-modified:Sat, 30 Sep 2017 15:42:50 GMT
pragma:public
server:Apache
status:200
x-xss-protection:1; mode=block

headers יכולים להכיל מידע נוסף כגון cookies או referrers, הגורמים ל header להיות גדול אף יותר. בהנחה ובבקשה השנייה ה header יכיל עוד אינפורמציה רק הדלתא בינהם תשלח:

:path: /logo.png
referer: https://he.savvy.co.il/blog/lp/index.html

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

Server Push

כשהדפדפן שולח בקשה לעמוד מסויים, השרת מחזיר html בתגובה. לאחר מכן השרת צריך להמתין לדפדפן עד שיפרוס את ה html ויבצע בקשות לשאר הנכסים (stylesheets, js & images) לפני שיישלח אלו לדפדפן. Server Push מאפשר למנוע זאת באמצעות שליחה של אותם נכסים אותם הוא חושב שהדפדפן הולך לבקש. לדוגמא, כאשר ישנה בקשה לעמוד מסויים, סביר להניח כי עמוד זה הולך לבקש stylesheet. השרת יישלח את ה stylesheet ללא המתנה לבקשה מהדפדפן.

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

HTTP/2 יכול לעבוד אך ורק על HTTPS

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

האתר HTTP vs HTTPS נותן השוואה לזמן הטעינה בין פרוטוקול HTTP/1.1 לפרוטוקול HTTP/2. השיפור במקרה זה HTTP/2 מהיר ביותר מ 80% מ HTTP/1.1:

http-vs-https-test

שיפור ביצועים באתרי וורדפרס

כפי שהראינו, המעבר ל HTTP/2 לבדו יכול להוביל לשיפור משמעותי בזמן הטעינה והביצועים של האתר שלכם. אך ישנן לא מעט פעולות שניתן לבצע על מנת לשפר את מהירות האתר שלכם. תוכלו למצוא הרבה מידע במדריכים הבאים:

ובעוד מאמרים באתר..

על הדרך, הצטרפו לרשימת התפוצה !


מה השינויים עקב המעבר ל HTTP/2?

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

איחוד קבצים (Concatenation)

ב HTTP/1.1 הרבה יותר מהיר לטעון קובץ קובץ אחד גדול לעומת מספר קבצים קטנים. מסיבה זו, נהוג היה לאחד קבצי javascript וקבצי css לקובץ אחד. בעידן ה HTTP/2, בקשות HTTP זולות יותר ומכאן שאיחוד מספר קבצים לקובץ אחד מיותר בהרבה מקרים משתי סיבות:

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

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

styles/main.css
styles/blog.css

לעומת הגשה של כל מודול בנפרד:

styles/header.css
styles/sidebar.css
styles/footer.css
styles/blog.css

Image Sprites

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

Inlining

אחת המטודות לצמצום מספר ה HTTP requests הינה inlining. פעולה זו שימושית בעיקר עבור תמונות קטנות שניתם להמיר אותם ל data-URI ונטענות על ידי הדפדפן ללא ביצוע בקשה נוספת לשרת. הבעיה עם טכניקה זו היא שהנכס אינו יכול חהיות cached על ידי הדפדפן ולכן חייב לרדת כל פעם מחדש בכל בקשה כחלק מקוד העמוד.

Domain Sharding

Domain Sharding היא טכניקה מתקדמת יותר בכדי ״לעבוד״ על הדפדפן בכדי שיטען יותר נכסים במקביל. לדוגמא, וכפי שהסברנו קודם, אם אתם מגישים נכסים מהשרת שלכם, הדפדפן יוכל להוריד 2-8 קבצים סימולטנית (בגלל מגבלת ה TCP). לעומת זאת, אם תחלקו את הנכסים בין שלושה דומיינים, הדפדפן יוכל להוריד 6-24 במקביל. זו הסיבה שנהוג לראות נכסים המקושרים ממספר דומיינים:

  • cdn1.domain.com
  • cdn2.domain.com
  • cdn3.domain.com

זהו מצב שיש להמנע ממנו בשימוש ב HTTP/2 מכיוון ו multiplexing אינו יכול לנצל את הפוטנציאל המלא שלו.

לסיכום

לא רק שהגלישה בימינו הרבה יותר מהירה ובטוחה עקב האימוץ של HTTP/2, הרבה יותר קל למפתחים ובעלי אתרים להטמיע דרכים המשפרות את מהירות הטעינה ואת אבטחת האתר שלהם.

אין חסרונות למעבר ל HTTTP/2, כל הדפדפנים הרציניים בשוק תומכים בפרוטוקול זה כבר זמן רב, ואלו שלא פשוט מבצעים fallback ל HTTP/1.1. אתרי וורדפרס המגישים מספר רב של נכסים ואלו העובדים ב HTTPS יראו שיפור משמעותי בביצועי האתר שלהם ומעבר לכך, בעלי אותם אתרים כבר אינם צריכים לדאוג לענייני איחוד קבצים, פיזור נכסים על דומיינים שונים ופעולות כמו יצירת image sprites.

לקריאה נוספת:

אוהבים את התוכן? הרשמו לרשימת התפוצה והרגישו חופשי לשתף מה אתם חושבים בתגובות…

רועי יוסף

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

תגובות פייסבוק

{ 7 תגובות… הוסף אחת }
  • יואב ניומן 22 באוקטובר 2017, 1:33

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

  • Rubb 22 באוקטובר 2017, 9:02

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

    • רועי יוסף 23 באוקטובר 2017, 3:27

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

      • Rubb 23 באוקטובר 2017, 8:52

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

  • מאור 9 בנובמבר 2017, 18:41

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

    אני כן עובד עם cdn. אולי מפה נובעת הבעיה? למרות ששוב, גם בבדיקות שערכתי מולם אני רואה שאני משתמש ב http2. אני לא מרגיש שאני נהנה מהיתרונות שב http2.

    • רועי יוסף 9 בנובמבר 2017, 19:27

      היי מאור, תודה 🙂

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

השאירו תגובה

שיתופים
קראו גם את:
יואסט SEO מדריך תוסף
מדריך שימוש בתוסף WordPress SEO by Yoast – חלק א׳

התוסף Wordpress SEO by Yoast הוא הנפוץ ביותר שקיים לקידום ואופטימזציה של אתרי וורדפרס במנועי...