Lighthouse לעומק - איך משפרים ציון¶
כמעט כל מפתח פרונטאנד ראה בשלב מסוים את הדוח האדום-צהוב-ירוק המפורסם של Lighthouse ותהה מה בדיוק הוא בודק ואיך משפרים אותו בלי לנחש באקראי. Lighthouse הוא כלי בקוד פתוח של גוגל שבודק דף אינטרנט ונותן לו ציון בכמה קטגוריות, ואפשר להריץ אותו ישירות מכלי הפיתוח של כרום, מהטרמינל, או כחלק מ-pipeline של CI.
איך מריצים אותו נכון¶
הדרך הכי מהירה היא לפתוח את כלי הפיתוח בכרום, לעבור ללשונית Lighthouse, ולהריץ בדיקה. אבל יש כאן טעות נפוצה - להריץ את הבדיקה על סביבת פיתוח מקומית עם קוד לא ממוזער ובלי אופטימיזציות בנייה, ואז להיבהל מהציון הנמוך. תמיד עדיפה בדיקה על גרסת production אמיתית, כי רק שם רואים את המספרים שבאמת ישקפו את מה שהמשתמש חווה.
חשוב גם לזכור שהציון יכול להשתנות בין הרצה להרצה, בגלל תנודות ברשת ובעומס המחשב. אם רוצים מדידה יציבה יותר, כדאי להריץ כמה פעמים ולהסתכל על הממוצע.
ארבע הקטגוריות שהדוח בודק¶
- ביצועים - Performance. בודק כמה מהר הדף נטען ומגיב, כולל מדדים כמו זמן עד שהתוכן העיקרי מוצג ויציבות הפריסה תוך כדי טעינה.
- נגישות - Accessibility. בודק דברים כמו ניגודיות צבעים, alt לתמונות, תוויות לטפסים ותמיכה בקוראי מסך.
- שיטות עבודה מומלצות - Best Practices. בודק דברים כמו שימוש ב-HTTPS, גרסאות ספריות עם פרצות ידועות, ושגיאות בקונסול.
- SEO. בודק דברים בסיסיים כמו תגי meta description, כותרות תקינות, ואפשרות לסריקה על ידי מנועי חיפוש.
שיפורים קונקרטיים בקטגוריית ביצועים¶
זו הקטגוריה שהכי מבלבלת מתחילים, ורוב השיפורים בה חוזרים על עצמם כמעט בכל אתר:
- דחיסת ואופטימיזציית תמונות. תמונות כבדות הן לרוב הגורם המשמעותי ביותר לזמן טעינה איטי.
- דחיית טעינת JavaScript שלא קריטי. קובץ שלא נחוץ לרינדור הראשוני עדיף לטעון באיחור (defer) או רק כשצריך.
- מניעת קוד חוסם רינדור. קבצי CSS ו-JS גדולים שנטענים לפני שהדף מוצג משהים את התצוגה הראשונית.
- הגדרת מידות לתמונות ומדיה מראש. בלי מידות מוגדרות, הדפדפן "מזיז" את התוכן כשהתמונה נטענת, מה שפוגע ביציבות הפריסה.
שווה לציין שהמדדים המדויקים שעומדים מאחורי הציון הזה, כמו LCP ו-CLS, מוסברים לעומק במדריך נפרד על Core Web Vitals - כאן המיקוד הוא בכלי עצמו ובאיך לפעול לפי הדוח שלו.
שיפורים בקטגוריית נגישות ו-SEO¶
בניגוד לביצועים, שיפורים בנגישות וב-SEO הם לרוב מהירים ליישום: הוספת alt לתמונות, שימוש בכותרות HTML בסדר היררכי נכון, הוספת label לכל שדה טופס, וודאות שיש meta description לכל דף. אלה תיקונים קטנים שמניבים קפיצה מיידית בציון, ובמקביל משפרים באמת את החוויה למשתמשים עם מוגבלויות.
הטעות הכי נפוצה - לרדוף אחרי המספר¶
ציון 100 מרשים, אבל הוא לא המטרה בפני עצמה. יש מקרים שבהם שיפור נקודתי בציון לא משנה כלום לחוויה האמיתית של המשתמשים שלכם. עדיף להסתכל על הדוח ככלי אבחון שמצביע על בעיות אמיתיות, ולתעדף לפי מה שבאמת ישפיע - לא לפי כל נקודה אפשרית.
מאיפה ממשיכים ללמוד¶
הבנה עמוקה של ביצועים ונגישות דורשת בסיס טוב ב-HTML, CSS ו-JavaScript. אם אתם בונים את הבסיס הזה, יש לנו קורס צד לקוח בחינם שמלווה אתכם משלב ההתחלה.
לסיכום¶
Lighthouse הוא כלי אבחון מצוין, לא שופט מוחלט. תריצו אותו על production, תתעדפו לפי השפעה אמיתית על משתמשים, ותזכרו שציון גבוה הוא תוצאה של עבודה טובה, לא המטרה עצמה.
יש לכם דוח Lighthouse שלא מבינים למה הוא אדום? שתפו בקהילה.