דמיינו אתר ידע שנבנה בעזרת AI. בדף הבית יש תמונה רחבה, כרטיסיות של מדריכים וסינון לפי נושא. על המחשב שבו נערך האתר הכול נראה מהיר. בטלפון אחר התמונה מתעכבת, לחיצה על נושא מגיבה באיחור והכרטיסיות זזות בדיוק כשמנסים לבחור אחת מהן. אלה שלוש בעיות שונות, גם אם כולן מתוארות באותו משפט: האתר איטי.
הדרך שבה האתר נוצר אינה מספיקה כדי להסביר את הביצועים שלו. אתר שנכתב ידנית יכול לסבול מאותן בעיות. באתר שנבנה עם AI פשוט קל להגיע במהירות להרבה רכיבים, תמונות וספריות קוד בלי לעצור ולבחון מה כל אחד מהם מוסיף לטעינה. כדי לשפר את המצב צריך לזהות מה מעכב את הגלישה ולא להתחיל מהתקנת עוד תוסף.
שלושה מדדים לשלושה רגעים שונים
Core Web Vitals מתייחסים לטעינה, לתגובה לפעולות וליציבות החזותית. כל מדד מתאר חלק אחר בחוויה. לכן אפשר לקבל תוצאה טובה באחד מהם ועדיין להרגיש שהעמוד אינו נוח לשימוש.
| מדד | מה הוא מתאר | הטווח שנחשב טוב |
|---|---|---|
| LCP | הזמן עד הצגת רכיב התוכן הגדול באזור הנראה של העמוד. | עד 2.5 שניות |
| INP | ההשהיה בתגובה חזותית לפעולות כמו לחיצה והקלדה. | עד 200 אלפיות השנייה |
| CLS | תזוזות בלתי צפויות בפריסת העמוד. | עד 0.1 |
אלה אינם יעדים לממוצע של כמה הרצות במחשב האישי. ההערכה המקובלת מתייחסת לאחוזון ה־75 בנתוני השימוש, בנפרד לנייד ולמחשב. המשמעות היא שב־75% מהמדידות הערך נמוך מהערך המוצג או שווה לו. במצב שבו יש מספיק נתונים לכל שלושת המדדים, מעבר ההערכה דורש ששלושתם יהיו בטווח הטוב.
בדוגמה של אתר הידע, התמונה המתעכבת עשויה להשפיע על LCP. תגובה איטית לסינון קשורה ל־INP. כרטיסיות שנדחפות מטה אחרי שכבר התחילו לקרוא יכולות להשפיע על CLS. ההפרדה הזאת נותנת כיוון ראשוני, אבל עדיין צריך לבדוק את הגורם בפועל.
למה הציון של Lighthouse אינו התשובה המלאה
PageSpeed Insights מציג שני סוגי מידע שכדאי לקרוא בנפרד. נתוני השטח מגיעים מ־CrUX ומתארים חוויות של משתמשי Chrome שעומדים בתנאי ההשתתפות. נתוני המעבדה מופקים באמצעות Lighthouse בסביבת בדיקה מבוקרת. הציון המסכם של Lighthouse אינו ציון Core Web Vitals של כל המבקרים באתר.
לנתוני השטח יש יתרון ברור: הם כוללים תנאי שימוש אמיתיים. אבל CrUX אינו סופר כל גולש בכל דפדפן. בנוסף, ב־PageSpeed Insights מדובר בחלון איסוף מתגלגל של 28 ימים. שינוי שבוצע הבוקר עדיין מעורבב בנתונים עם חוויות מהגרסה הקודמת.
חשוב לקרוא גם את היקף הנתונים. לפעמים מוצגים נתונים של הכתובת שנבדקה ולפעמים נתונים של כלל האתר ברמת ה־origin. אם לדף הבית החדש אין מספיק דגימות, נתוני האתר כולו אינם הוכחה לכך שדווקא בו נמצאת הבעיה. באתר חדש ייתכן שלא יופיעו כלל נתוני שטח.
במעבדה אפשר לבדוק את הגרסה הנוכחית ולראות אילו משאבים מעכבים אותה. עם זאת, הרצת טעינה רגילה של Lighthouse אינה כוללת אדם שלוחץ על הסינון ולכן אינה מודדת INP. מדד TBT יכול לעזור לזהות עבודה שחוסמת את הדפדפן בזמן הטעינה, אך הוא אינו שם אחר ל־INP ואינו מחליף בדיקת אינטראקציות.
גם שתי הרצות מעבדה אינן בהכרח זהות. חיבור הרשת והעומס בסביבת הבדיקה יכולים להשתנות. לצורך השוואה שומרים את סוג המכשיר ואת הגדרות ההאטה ולא משווים בדיקת מחשב לבדיקה שמדמה טלפון. אם התוצאה משתנה בין הרצות, בוחנים אם אותו רכיב ממשיך להיות הגורם המעכב. הפרש קטן בציון לבדו לא תמיד מצדיק שינוי נוסף בקוד.
התמונה הראשית כבדה או שהיא פשוט מתחילה מאוחר?
כשדף הבית מלא בתמונות שנוצרו עם AI, טבעי להתחיל בדחיסה. לפעמים זה בדיוק מה שנדרש. אבל תמונה קטנה יותר לא תפתור עיכוב שנובע מכך שהדפדפן מגלה אותה רק אחרי סיום הרצת קוד. קודם מזהים בכלי הביצועים איזה רכיב נמדד כ־LCP. זה יכול להיות גם טקסט ולא התמונה שתכננו להבליט.
אם הרכיב הוא התמונה הראשית, בודקים את מסלול הטעינה שלה. מתי הגיע המסמך הראשוני מהשרת? מתי הדפדפן התחיל לבקש את התמונה? כמה זמן נמשכה ההורדה? והאם עבר זמן נוסף בין סיום ההורדה להצגתה? החלוקה הזאת מונעת מצב שבו דוחסים שוב ושוב קובץ שכבר אינו צוואר הבקבוק.
עיכוב בתשובת השרת דורש בירור של יצירת העמוד ושל המטמון. עיכוב בגילוי התמונה עשוי להצביע על כך שהיא מתווספת רק באמצעות JavaScript או מופיעה כרקע בקובץ עיצוב שטרם נטען. אם הקובץ כבר הגיע אבל התמונה עדיין מוסתרת עד לסיום אנימציה, צריך לבדוק את תנאי ההצגה.
לתמונה הראשית שמופיעה מיד בכניסה בדרך כלל לא מתאימה טעינה עצלה. היא צריכה להיות זמינה מוקדם. אפשר לתת לתמונת LCP קדימות הורדה באמצעות fetchpriority כשהמימוש מתאים לכך. לעומת זאת, אין טעם לתת קדימות גבוהה לכל תמונה בעמוד. הקדימות מאבדת ממשמעותה כשכולן מתחרות באותה דרגה.
לאחר מכן בוחנים את הקובץ עצמו. כדאי להגיש גודל שמתאים לתצוגה ולצפיפות המסך באמצעות תמונות רספונסיביות. אפשר לבחון WebP או AVIF ולוודא שהפרטים החשובים נשארים ברורים. אין סיבה שכרטיסית קטנה תוריד תמיד את קובץ המקור הגדול שנוצר בכלי התמונות.
אחרי החלפת התמונה בודקים בלשונית הרשת איזה קובץ הדפדפן הוריד בפועל. ייתכן שהתצוגה עדיין משתמשת בגרסה ישנה שנשמרה במטמון או שברוחב מסך מסוים נבחר קובץ אחר. שינוי בספריית המדיה אינו מוכיח שכל המופעים בעמוד התעדכנו. על בחירת החיתוך והפורמט אפשר לקרוא במדריך ל־יצירת תמונות AI ושילובן באתר.
כשהסינון מגיב לאט הבעיה אינה בהכרח ברשת
נניח שהתמונות כבר מוצגות אבל מעבר בין נושאים עדיין מרגיש כבד. הסינון עשוי לבנות מחדש מאות כרטיסיות בכל לחיצה. ייתכן שבמקביל פועלים קוד אנימציה, כלי מדידה ורכיבים מוטמעים. גם אחרי שקובץ JavaScript ירד מהר, הדפדפן צריך לפרש אותו ולהריץ את העבודה שבתוכו.
כאן צריך להקליט את הפעולה עצמה בלשונית Performance של כלי הפיתוח בדפדפן. מתחילים הקלטה, לוחצים על נושא ומפסיקים אחרי שהתצוגה מגיבה. מחפשים היכן נוצר העיכוב: לפני תחילת הטיפול בלחיצה, בזמן ביצוע הקוד או לפני הצגת המסך המעודכן. צילום של העמוד המוגמר לא יראה את ההבדל הזה.
אם הסינון מבצע עבודה רבה בכל לחיצה, אפשר לצמצם אותה. למשל, לא לחשב מחדש נתונים שלא השתנו ולא ליצור שוב אזורים שאינם מושפעים מהבחירה. עבודה שאינה נחוצה לתגובה הראשונית יכולה להתבצע בנפרד. במקרים מתאימים מפצלים משימות ארוכות כדי שהדפדפן יוכל להמשיך להגיב בין חלקיהן.
כאשר העומס מגיע מרכיב חיצוני, בודקים אם הוא נחוץ בעמוד הזה ובשלב הזה. נגן וידאו שמופיע בהמשך הדף לא תמיד צריך להפעיל את כל המערכת שלו ברגע הכניסה. אפשר לבחון טעינה לפי צורך. לעומת זאת, דחייה גורפת של כל הסקריפטים עד הלחיצה הראשונה עלולה להשאיר את הסינון עצמו לא פעיל.
חשוב גם להבדיל בין תגובה ללחיצה לבין השלמת פעולה ארוכה. אם הבחירה שולחת בקשת נתונים, אפשר להציג מיד מצב טעינה ברור בזמן שממתינים לתשובה. זה אינו הופך שרת איטי למהיר, אבל מונע מצב שבו הכפתור נראה קפוא. לאחר מכן בודקים בנפרד את זמן קבלת הנתונים.
מה גורם לכרטיסיות לזוז אחרי שהעמוד כבר הופיע
תמונה יכולה להיות קלה ומהירה ובכל זאת להזיז את כל מה שמתחתיה אם לא נשמר לה מקום מראש. כאשר הדפדפן אינו יודע מה יהיה היחס בין הרוחב לגובה, הטקסט עשוי להופיע תחילה גבוה בעמוד ואז להידחף מטה. הפתרון הוא להגדיר מידות או יחס ממדים שמתאימים לתמונה, לא רק להקטין את הקובץ שלה.
אותה בעיה יכולה להגיע מסרטון מוטמע או מרכיב שמתמלא מאוחר. אם באזור מסוים אמור להופיע תוכן בגודל ידוע, שומרים עבורו מקום כבר בפריסה הראשונית. צריך לבדוק גם את המסך הצר. מקום שמתאים לסרטון במחשב לא בהכרח מתאים לאופן שבו הוא מוצג בטלפון.
לפעמים דווקא הטקסט משנה את הפריסה. גופן שמגיע מאוחר עשוי להחליף גופן זמני ולהעביר כותרת לשורה נוספת. כדאי לבדוק אם נטענים משקלים שאינם בשימוש ואם הגופן החלופי דומה מספיק בגודלו. בחירת דרך טעינת הגופן צריכה לשמור גם על הופעת הטקסט וגם על יציבותו.
תזוזות שמשפיעות על CLS יכולות להופיע גם אחרי הטעינה הראשונית. לכן גוללים באתר הידע עד הכרטיסיות התחתונות ורואים מה קורה כשתמונות נוספות נטענות. בכלי הביצועים אפשר לאתר תזוזות פריסה. הרכיב שסומן כזז אינו תמיד הגורם: ייתכן שמשהו חדש נכנס מעליו ודחף אותו.
איך בוחרים מה לתקן קודם
בדף הבית המדומיין שלנו לא מתחילים משלושת המדדים יחד. בוחרים את הבעיה הבולטת בנתונים או בהתנהגות שאפשר לשחזר. אם יש עיכוב משמעותי בגילוי התמונה הראשית, תיקון שלו קודם לניקוי זעיר של קובץ עיצוב. אם העמוד נטען היטב אך הסינון נתקע, דחיסת תמונות נוספת כנראה לא תפתור את ההמתנה ללחיצה.
שומרים מדידת בסיס של הכתובת ושל סוג המכשיר. מבצעים שינוי ממוקד ובודקים שוב באותם תנאים. רצוי להשוות כמה הרצות ולא לבחור רק את התוצאה הנוחה ביותר. לאחר מכן מפעילים את החלק שתוקן כדי לוודא שהשיפור לא הושג במחיר של התנהגות חסרה.
באתר WordPress חשוב לבדוק גם את התוצאה הציבורית אחרי שינוי במטמון או בהגדרות טעינה. העורך והמבקר שאינו מחובר לא תמיד מקבלים את אותו עמוד. מספר התוספים לבדו אינו מסביר את הביצועים: תוסף יחיד יכול להעמיס עבודה רבה, בעוד אחרים כמעט אינם משפיעים על העמוד הנבדק.
אותו היגיון חל על אתרים שנוצרו בפלטפורמות אחרות. לפני שמבקשים מסוכן ה־AI לשכתב את האתר, כדאי להראות לו את הרכיב ואת העיכוב שאותרו. היכרות עם ההבדלים בין פלטפורמות לבניית אתרים עם AI עוזרת להבין היכן ניתן לערוך את המימוש ומה נשלט על ידי הפלטפורמה.
לאחר שתיקון עבר בדיקה מקומית, ממשיכים לעקוב אחר נתוני השטח. אין צורך להמתין לסיום חלון שלם כדי לראות שהקוד החדש נטען אחרת במעבדה. מצד שני, אין לצפות שנתוני 28 הימים יחליפו מיד את ההיסטוריה. שתי הבדיקות משלימות זו את זו במקום להתחרות על השאלה איזו מהן נכונה.
כדאי לשמור גם תיאור קצר של התיקון: איזו תמונה קיבלה קדימות או איזו פעולה הפסיקה לחשב מחדש את כל הכרטיסיות. בעדכון הבא אפשר לחזור לאותה בדיקה ולראות אם הבעיה חזרה. כך תוספת של מדור חדש או רכיב שנוצר בשיחה נוספת עם AI אינה מוחקת בשקט את השיפור שכבר הושג. המטרה היא לשמור על חוויה יציבה גם כשהאתר ממשיך להתפתח.
שאלות שעולות בזמן שיפור הביצועים
אין לאתר החדש נתוני שטח. האם זה אומר שהוא איטי?
לא. ייתכן שאין מספיק דגימות כדי להציג נתוני CrUX עבור הכתובת או האתר. בינתיים אפשר להשתמש בבדיקות מעבדה ולבדוק פעולות אמיתיות בכמה תנאי שימוש. אם צריך מעקב מפורט יותר, אפשר להוסיף מדידת ביצועים ממשתמשים באתר. היעדר נתונים אינו ציון טוב או רע.
האם SSR מבטיח אתר מהיר?
לא. הוא יכול לאפשר לתוכן להגיע מוקדם מהשרת, אבל תגובת שרת איטית, תמונות כבדות או קוד רב בדפדפן עדיין יכולים לעכב את החוויה. במדריך על בדיקת אתר Lovable והרינדור שלו מוסבר גם ההבדל בין זמינות התוכן בכתובת לבין מה שקורה אחרי שהדפדפן מתחיל לעבוד עליו.
הציון במעבדה השתפר אבל INP לא השתנה. מה בודקים?
קודם בודקים אם התיקון בכלל נגע לפעולה האיטית. שיפור טעינת תמונה לא בהכרח משנה את קוד הסינון. אחר כך משווים את היקף הנתונים ואת התקופה שמוצגת. כדאי לשחזר את הפעולה בכלי הפיתוח ולבדוק אותה ישירות, לצד המשך מעקב אחר נתוני השימוש המצטברים.
