שיפור מהירות אתר: איך לבדוק, לנתח ולשפר את ביצועי המהירות של האתר שלכם
מהירות האתר היא אחד המרכיבים החשובים בקידום האורגני במנועי חיפוש (SEO) וגם בכל הקשור לביצועים שגורמים לאנשים לצרוך את התכנים, המוצרים והשירותים שלכם. למרות זאת, בדיקת מהירות האתר היא אחת התעלומות הגדולות של עסקים רבים ויש מאחוריה מיתוסים וחוסר הבנות שהגיע הזמן לנפץ. המדריך הבא סוקר את המרכיבים החשובים של בדיקות המהירות השונות וכיצד ניתן להשתמש בהם לשיפור מהירות האתר שלכם
בדיקת מהירות טעינת האתר עוזרת לבעלי אתרים לוודא שהאתר שלהם נטען בזמן סביר בדפדפנים רגילים ובדפדפנים במובייל. מטרת הבדיקה היא להצביע על בעיות המשפיעות לרעה על זמן הטעינה ולאפשר לבעלי האתר לטפל בהן ובכך לשפר את חווית השימוש באתר עבור הגולשים.
המטרה הראשונה בבדיקה היא למדוד את הזמן שעובר מרגע טעינת הדף ועד הרגע שבו המשתמש רואה משהו על המסך. ה-"משהו" הזה צריך להיות חלק כלשהו מהתוכן של הדף וככל שהוא יוצג מהר יותר, כך הגולשים באתר ירגישו שהוא נטען במהירות מספקת שלא תגרום להם לנטוש אותו. השאיפה היא שהאתר יציג תוכן ראשוני בשניה הראשונה מרגע הטעינה. גוגל קוראים למדד הזה FCP (ראשי תיבות של First Contentful Paint) – אם האתר מציג תוכן ראשוני תוך שניה אחת לכל היותר הוא יחשב כאתר מהיר לפי מדד ה-FCP, אם המהירות היא תוך 1-3 שניות אז אפשר להתייחס למהירות כבינונית. זמן הגדול מ-3 שניות נחשב לאיטי. כמובן שצריך לזכור שאנחנו לא מדברים כאן על טעינה מלאה של הדף, רק על חיווי ראשוני.
השלב הבא הוא לבדוק את זמן הטעינה המלא של הדף בעזרת סטים שונים של מדדים שמטרתם לקבוע את משך זמן הטעינה המלא של הדף (Speed Index), את משך הזמן עד שהדף הופך הוא אינטרקטיבי בצורה מלאה למשתמש – הכוונה היא שהמשמש יכול לתפעל את כל האזורים בדף עם העכבר\מקלדת (Time to Interactive), וגם את זמן התגובה של האתר מרגע שהמשתמש ביצע פעולה כלשהי, כמו לחיצה על קישור, ועד הרגע שהאתר מגיב אליה (First Input Delay).
השקלול של כל המדדים הללו נותן ציון סופי שקובע האם הדף הוא איטי (0-49), בינוני (50-89) או מהיר (90-100). כמעט בכל המקרים הציון של טעינת הדף בדפדפן רגיל יהיה גבוה יותר לעומת ציון טעינת אותו הדף במובייל. הסיבה היא שלמחשב שולחני יש יכולות עיבוד הרבה יותר גבוהות ממכשיר סלולרי, אבל הציפיה היא שהאתר יטען מהר גם בגרסה הרגילה וגם בגרסה הרספונסיבית.
ניתן לבדוק את מהירות האתר דרך גוגל, GTmetrix, speedom וכלים אחרים. הציון לא בהכרח יהיה זהה בכל המקרים מכיוון שכל אחד מהם משכלל את הציון בצורה אחרת, והבדיקה עצמה מתבצעת במקום גאוגרפי שונה והקרבה הפיזית בין השרתים בהחלט יכולה להשפיע על זמן הטעינה. אני באופן אישי מעדיף לבדוק את מהירות הטעינה דרך גוגל.
כשאתם מבצעים בדיקת מהירות לאתר מומלץ לבדוק לא רק את דף הבית, אלא גם את הדפים הפנימיים של האתר, כדי לקבל תמונה מלאה על מהירות הטעינה של האתר שלכם. לאחר שתריצו את הבדיקה יוצג הציון בליווי רשימה של הצעות כיצד לשפר את מהירות הטעינה של הדף. בגלל שאופי ההצעות הוא טכני במהותו, אנסה להסביר בשפה פשוטה את המשמעות שלהן.
Eliminate render-blocking resources
השאיפה של גוגל היא שהתוכן של הדף יוצג למשתמש במהירות המרבית – כל מה שאינו קשור לתוכן באופן ישיר נחשב כגורם מעכב: פונטים, הגדרות עיצוב, קבצי קוד – כל אלה נחשבים כגורמים מעכבים המשפיעים לרעה על קצב הטעינה של הדף.
הסיבה היא שהדפדפן צריך לעצור את תהליך ההצגה של הדף על מנת להוריד מהשרת קבצים נוספים – הפונטים הם בסופו של דבר קבצים, הגדרות העיצוב הן קבצי CSS, אלמנטים דינמיים כמו קרוסלת תמונות מתאפשרים בעזרת קבצי קוד JS – הדפדפן צריך לעצור את התהליך, להמתין לסיום טעינת הקבצים הללו ורק אז הוא יכול להמשיך הלאה.
הפתרון הוא "להסביר" לדפדפן מהם המשאבים הקריטיים לטעינה הראשונית של הדף.
בשפה פשוטה, אנחנו רוצים שהשרת עליו מתארח האתר יגיד לדפדפן: "היי, הדף שביקשת ממני עושה שימוש בפונט Roboto, אני מצרף לך מראש גם את הקבצים של הפונט וגם את קבצי העיצוב בבת-אחת, כדי שלא תצטרך לבקש אותם ממני תוך כדי תהליך הטעינה של הדף".
בנוסף אנחנו רוצים לגרום לדפדפן להשהות את הטעינה של קבצי קוד לסוף התהליך, אחרי שהדף הוצג למשתמש.
לאתרי וורדפרס קיימים מגוון תוספים (חינמיים ובתשלום) שיכולים לטפל בבעיה בהיבט הטכני ולשפר את זמני הטעינה של הדף חשוב להדגיש שאין פתרון אחיד לבעיה וכדאי לקחת בחשבון שטיפול שגוי עלול לגרום לתקלות לא צפויות.
Defer offscreen images
המטרה של ההצעה היא להצביע על התמונות הממוקמות מחוץ לגבולות המסך – תמונות שהמשתמש צריך לגלול את הדף על מנת לצפות בהן. אנו שואפים לקצר את זמן הטעינה של הדף עד כמה שניתן אבל האתר מבזבז רוחב פס כדי לטעון תמונות שהמשתמש גם ככה לא רואה כרגע.
הפתרון הוא לבצע "טעינה עצלה" (Lazy loading) של התמונות – לגרום לדפדפן לטעון את התמונה בדיוק ברגע הנכון, כאשר המשתמש גולל עם העכבר ומגיע למיקום של התמונה בדף, במקום שהדפדפן יטען את כל התמונות בדף בבת-אחת. בדרך זו אנחנו חוסכים רוחב פס וגורמים לדף להיטען יותר מהר.
Efficiently encode images
הבדיקה תתריע אם באתר שלכם נעשה שימוש בתמונות שלא עברו אופטימיזציה. באתרים כמו tinypng תוכלו לבצע בחינם אופטימיזציה לתמונות שתביא להקטנת הנפח של התמונה מבלי לפגוע באיכות שלה. באתרי וורדפרס אפשר להתקין תוסף שעושה אופטימיזציה לתמונות בצורה אוטומטית מאחורי הקלעים.
Serve images in next-gen formats
בשנים האחרונות פורמטים חדשים של תמונה צוברים תאוצה ויותר אתרים עושים בהם שימוש. תמונות בפורמט WebP הן תמונות שעברו אופטימיזציה אופטימלית שמורידה את נפח הקובץ עם השפעה מינימלית על איכות התמונה, וגורמת להן להיטען מהר יותר לעומת פורמטים נפוצים כמו png או jpg.
מכיוון שלא כל הדפדפנים תומכים עדיין בפורמט החדש, מומלץ להמיר את כל התמונות באתר לפורמט WebP ולאפשר לדפדפנים שתומכים בו לטעון את התמונה בפורמט WebP בעוד שדפדפנים שאינם תומכים בפורמט יטענו את התמונה בפורמט המקורי.
זאת משימה לא פשוטה ליישום. אנחנו נדרשים להמיר את כל התמונות שלנו לפורמט WebP וצריכים לעדכן את הקוד באתר שיאפשר תמיכה גם בפורמט החדש וגם בפורמט הישן בגלל אי תאימות של הדפדפנים הנפוצים בשוק. באתרי וורדפרס אני ממליץ להשתמש בתוסף של ShortPixel שמטפל בכל ההיבטים הטכניים (המרת התמונה לפורמט WebP וטעינה שלה בדפדפנים התומכים בו) בצורה אוטומטית.
Properly size images
הבדיקה מתריעה על תמונות בפרופורציה גדולה ללא סיבה. אם תמונה מוצגת בדף בגובה ורוחב של 300 פיקסלים, אין שום סיבה לטעון תמונה ענקית בגודל 2000X2000 – תמונות גדולות מבזבזות רוחב פס ולכן כדאי להקטין את המימדים של התמונה לגודל המדויק בו הן צריכות להיות מוצגות באתר.
Ensure text remains visible during webfont load
כמעט בכל אתר נעשה שימוש בפונט Web. להבדיל מפונטים רגילים, פונט Web הוא פונט בפורמט המאפשר לו להיטען ולהיות מוצג בדפדפן. לגוגל יש מאגר חינמי של פונטים התומכים בשפה העברית, וכמובן שקיימים מאגרים בתשלום של פונטים בעברית, אבל תאצלו להיפרד מכמה מאות שקלים כדי להשתמש בהם באופן חוקי.
הבעיה היא שהדפדפן צריך לטעון את קבצי הפונט מהשרת לפני שהוא יוכל להציג את התוכן בפונט המתאים, והמשמעות של זה היא עיכוב בטעינה של האתר. השאיפה היא למנוע את העיכוב ולהציג את הטקסטים באתר בפונט סטנדרטי, שיתחלף לפונט המבוקש ברגע שהטעינה שלו תסתיים.
הפתרון דורש התמצאות ב-CSS אבל זאת אחת הבעיות הפשוטות ביותר לתיקון באתר, המשמעות היא שבטעינה הראשונית יתכן ותבחינו בהבהוב קצר של הטקסט שנטען בתחילה עם פונט ברירת המחדל של הדפדפן ואז מתחלף לפונט המעוצב אחרי שקובץ הפונט נטען מהשרת.
Minify CSS / Minify JavaScript
בדיקה שמתריעה על קבצי css וקבצי js שלא עברו אופטימיזציה שמקטינה את הנפח שלהם ומשפרת את זמן הטעינה של האתר. האופטימיזציה משנה את הקבצים ומבטלת רווחים מיותרים, שבירות שורה, הערות בקוד ודברים נוספים שבסופו של דבר מורידים את נפח הקובץ למינימום.
אם אתם עושים שימוש בתוסף אופטימיזציה באתר שלכם, מומלץ שתפעילו את האפשרות לכווץ את הקבצים של האתר, הפעולה תגרום לשיפור הציון של מהירות הטעינה של הדף.
Uses efficient cache policy on static assets
בדיקה שמטרתה לזהות משאבים (כמו תמונות, פונטים, קבצי JS +CSS) שלא הוגדר להם זמן תפוגה בשרת. ההמלצה היא להגדיר לקבצים האלו זמן תפוגה של שנה, והתוצאה היא שהם ישמרו בזיכרון של הדפדפן למשך הזמן שהוגדר בשרת וישפרו את זמן הטעינה אצל מבקרים חוזרים באתר.
במידה והבדיקה משפיעה על הציון של האתר שלכם מומלץ לפנות לחברת האחסון שלכם ולבקש מהם לטפל בהגדרות ברמת השרת, אם כי בחלק מהמקרים מדובר בבעיה שנגרמת מטעינה של קבצים משרתים חיצוניים, לדוגמה: קוד הטמעה של גוגל אנליטיקס או קוד מעקב של פיקסל פייסבוק – במקרים כאלה אין לכם שליטה על זמן התפוגה שהוגדר לקבצים, ונדרש פתרון יותר יצירתי ומורכב לבעיה.
Avoids an excessive DOM size
בדיקה המתריעה על דפים בהם יש יותר מ-1,500 אלמנטים בקוד ה-HTML של הדף. הבעיה באה לידי ביטוי בעיקר במכשירים ישנים, או במחשבים עם מעט זיכרון בגלל שנדרש כוח עיבוד רב יותר כדי לטעון את הדף ולהציגו למשתמש. כמובן שדף עמוס באלמנטים מבזבז רוחב פס גדול יותר לעומת דף בעל מבנה "רזה".
במידה והבעיה משפיעה על ציון האתר כדאי לבצע השוואה ולבדוק דפים אחרים באתר – אם היא חוזרת על עצמה אז נדרש טיפול עומק במבנה הכללי של האתר.
במידה והיא מופיעה רק בדף ספציפי אז יתכן מאוד שהתוכן המקורי הועתק מוורד והודבק בכתבן דרך ממשק הניהול – הרבה פעמים העתקה מוורד מוסיפה "זבל" מיותר לטקסט, כדאי להעתיק את המלל של הפוסט לכתבן רגיל (Notepad) ולהחליף אותו עם התוכן הפגום בכתבן.
Avoids enormous network payloads
חיווי לכך שזמן הטעינה מתארך בצורה משמעותית בגלל טעינה רבה של קובצי תמונה, קובצי עיצוב (css), קובצי קוד (js) וקבצים אחרים. מספר גדול מדי של קבצים מאט את זמן הטעינה של הדף, בעיקר אם אתם מנסים לגלוש אליו מרשת איטית.
אם הבדיקה מורידה את ציון המהירות של האתר צריך קודם כל להבין איזה קבצים גורמים לה. במידה ומדובר בתמונות הפתרון הוא לוודא שהן עברו אופטימיזציה ולטעון אותן בעזרת "טעינה עצלה" שתגרום לדפדפן לטעון אותן מהשרת רק ברגע בו המשתמש גולל אליהן בתוכן הדף (כמו בהסבר Defer offscreen images). בקבצים אחרים צריך לבדוק האם מדובר במקטעי קוד קצרים שניתן להטמיע ישירות בדף ולהגדיר תיעדוף שיביא לכך שרק הקבצים הקריטיים באמת יטענו בשלב הטעינה הראשונה, וכל שאר הקבצים יטענו מהשרת בשלב מאוחר יותר.
Avoid multiple page redirects
מדובר בעיה פשוטה לטיפול באופן יחסי, הבדיקה מתריעה על קישורים שגורמים לדפדפן לבצע מספר רב של הפניות על מנת להגיע לכתובת העדכנית של הדף.
ניתן להמחיש את הבעיה בדרך הבאה: הדפדפן פונה לשרת ומבקש לטעון דף בכתובת X, השרת מחזיר תשובה שהנתיב לתוכן השתנה והמיקום העדכני שלו הוא בכתובת Y. הדפדפן מבין ומנסה לטעון את הדף דרך כתובת Y, אבל אז השרת מחזיר תשובה שהמיקום השתנה לכתובת Z, אז הדפדפן מנסה לטעון את הדף דרך כתובת Z. לא עדיף פשוט לטעון את הדף מלכתחילה דרך כתובת Z העדכנית, ובכך למנוע את "הדיאלוג" המיותר בין הדפדפן והשרת?
הבעיה נפוצה באתרים וותיקים שלאורך השנים בוצעו בהם שדרוגים שגרמו לשינויים במבנה הקישורים. הפתרון הוא לוודא שכל הקישורים באתר מפנים לנתיב העדכני של התוכן.
Preconnect to required origins / Preload key requests / Minimize third-party usage
שלוש בדיקות שונות אך בעלות אופי דומה, המטרה שלהן היא לגרום לדפדפן להבין שבתהליך הטעינה של הדף הוא יידרש לטעון משאבים מסוימים ממקורות חיצוניים (קבצים שיושבים בדומיין שונה מזה של האתר). מדובר ב"רמז" שאנחנו יכולים לספק לדפדפן שיגרום לו להתחבר מראש אל כל אותם מקורות חיצוניים עוד בטרם תחילת תהליך הטעינה, ובכך לקצר את זמן הטעינה של הדף.
הבעיות מתרחשות באתרים שעושים שימוש בשירותים חיצוניים שדורשים טעינה של קבצים משרתים אחרים, לדוגמה: פונטים מגוגל, הטמעת קאפצ'ה כדי למנוע ספאם, קוד הטמעה של גוגל אנליטיקס, הטמעת קישור לדף העסקי בפייסבוק באתר, הטמעת פיקסל פייסבוק ועוד.
אם אתם רואים שהבעיה פוגעת בביצועים של האתר שלכם מומלץ להעתיק ולהדביק את שורות הקוד שגוגל מציעים בדפי האתר ולבצע בדיקת מהירות נוספת כדי לוודא שהבעיה נפתרה.
Enable text compression
הבדיקה מצבעיה על פוטנציאל לשיפור מהירות הטעינה על ידי שימוש באלגוריתם לדחיסת הנתונים שמגיעים מהשרת. בדומה לקובצי ZIP ו-RAR, ניתן ליישם בשרת דחיסת נתונים אוטומטית שתקטין את הנפח הכולל של הקבצים ותקצר את זמני הטעינה של הדף באופן משמעותי.
ניתן לטפל בבעיה ברמת השרת, על ידי שינוי הגדרות, ובאתרי וורדפרס ניתן להתקין תוסף (כמו wp-rocket לדוגמה) שמסוגל לבצע את הדחיסה מאחורי הקלעים בלי תלות בשרת.
Use video formats for animated content
הבדיקה תתריע על מקרים בהם האתר שלכם עושה שימוש בקובצי GIF בשביל אנימציות, כאשר עדיף להמיר אותם לקובץ וידאו בפורמט MP4. הסיבה היא שקובץ וידאו בפורמט MP4 הוא קובץ שעבר אופטימיזציה והוא בעל נפח קטן יותר לעומת קובץ GIF ולכן הוא יטען יותר מהר.
Minimize main thread work
הבדיקה מחשבת את הזמן שלוקח לדפדפן מהרגע שהוא מתחיל לפענח את הגדרות העיצוב והקוד ועד להשלמת התהליך. דפים המכילים אלמנטים דינמיים כמו קרוסלת תמונות, תפריטים נפתחים, אנימציות, אפקטים מיוחדים וכו' מעכבים את תהליך הטעינה ופוגעים בביצועים של הדף.
הדרך הבטוחה למנוע מהבדיקה לפגוע בציון המשוכלל של מהירות הדף היא להימנע עד כמה שניתן מאפקטים מיותרים שהופכים את האתר שלכם לקרקס :)
לסיכום, המטרה של בדיקת המהירות היא לוודא שהאתר שלכם נטען במהירות האופטימלית. ברוב המקרים מדובר בפרקי זמן של מאיות-שניה שיכולים להשפיע על הציון הסופי לטובה או לרעה.
במידה והציון הממוצע של הדפים נמוך מ-50 מומלץ מאוד לבצע שיפורים שיתרמו לחוויית השימוש באתר שלכם. בחלק מהבעיות תוכלו לטפל בעצמכם בקלות יחסית, אבל הטיפול ברוב הבדיקות מצריך ידע מעמיק ולכן מומלץ להעביר את הטיפול בהן למתכנת\ת מקצועי\ת ולא לקחת סיכון שעלול לפגוע בפעילות השוטפת של האתר.
-
הכותב הוא יועץ שיווקי ובונה אתרים.