מהו FCP?
המדד 'הצגת תוכן ראשוני (FCP)' מודד את הזמן שחלף מהרגע שהמשתמש ניווט לדף בפעם הראשונה ועד לרגע שבו חלק כלשהו מתוכן הדף עובר רינדור במסך. במדד הזה, 'תוכן' מתייחס לטקסט, לתמונות (כולל תמונות רקע), לאלמנטי <svg>
או לאלמנטי <canvas>
שאינם לבנים.
בציר הזמן של הטעינה המתואר בתמונה הקודמת, שיטת FCP מתרחשת בפריים השני. באותו זמן, רכיבי הטקסט והתמונה הראשונים עוברים עיבוד למסך.
תוכלו לראות שחלק מהתוכן עבר עיבוד, אבל לא כולו עבר רינדור. זוהי הבחנה חשובה בין First הצגת תוכן מבוסס-תוכן לבין המהירות שבה נטען Largest Contentful Paint (LCP), שהמטרה שלה היא למדוד את הטעינה של התוכן הראשי.
מהו ציון FCP טוב?
כדי לספק חוויית משתמש טובה, באתרים צריך לשאוף לזמן של 1.8 שניות או פחות ל-First Contentful Paint. כדי לוודא שאתם עומדים ביעד הזה עבור רוב המשתמשים, סף טוב למדידה הוא האחוזון ה-75 של טעינות דפים, המפולחים במכשירים ניידים ובמחשבים.
איך מודדים FCP
אפשר למדוד את FCP במעבדה או בשטח, והוא זמין בכלים הבאים:
כלים לשטח
- PageSpeed Insights
- הדוח לגבי חוויית המשתמש ב-Chrome
- Search Console (דוח מהירות)
- ספריית JavaScript של
web-vitals
כלים לשיעור Lab
מדידת אירועי FCP ב-JavaScript
כדי למדוד FCP ב-JavaScript, אפשר להשתמש ב-Paint Timing API. בדוגמה הבאה מוסבר איך ליצור PerformanceObserver
שמקשיב לרשומה paint
בשם first-contentful-paint
ומתעדה אותה במסוף.
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
console.log('FCP candidate:', entry.startTime, entry);
}
}).observe({type: 'paint', buffered: true});
בקטע הקוד הקודם, הרשומה first-contentful-paint
ביומן מציינת מתי בוצע הציור של הרכיב הראשון בעל התוכן. עם זאת, במקרים מסוימים הרשומה הזו לא תקפה למדידת FCP.
בקטע הבא מפורטים ההבדלים בין הדוחות של ה-API לבין אופן החישוב של המדד.
ההבדלים בין המדד לבין ה-API
- ה-API ישלח רשומה
first-contentful-paint
לדפים שנטענו בכרטיסייה ברקע, אבל צריך להתעלם מהדפים האלה כשמחשבים את ה-FCP (צריך להביא בחשבון את זמני ה-first paint רק אם הדף היה בחזית כל הזמן). - ה-API לא מדווח על רשומות
first-contentful-paint
כשהדף משוחזר ממטמון לדף הקודם/הבא, אבל צריך למדוד את ה-FCP במקרים כאלה, כי המשתמשים חווים אותן כביקורים נפרדים בדף. - יכול להיות שה-API לא ידווח על תזמוני צביעה מ-iframes ממקורות שונים, אבל כדי למדוד כראוי את זמן הטעינה הראשוני, צריך להביא בחשבון את כל המסגרות. תמונות משנה יכולות להשתמש ב-API כדי לדווח על תזמוני הצגת הצבעים למסגרת ההורה לצורך צבירה.
- ה-API מודד FCP מתחילת הניווט, אבל בדפים שעברו עיבוד מראש צריך למדוד FCP מ-
activationStart
כי זה תואם לזמן ה-FCP כפי שחווים את המשתמש.
במקום לשנן את כל ההבדלים הקלים האלה, מפתחים יכולים להשתמש בספריית ה-JavaScript של web-vitals
כדי למדוד FCP, שמטפל בהבדלים האלה בשבילכם (ככל האפשר – שימו לב שהבעיה iframe לא נכללת בה):
import {onFCP} from 'web-vitals';
// Measure and log FCP as soon as it's available.
onFCP(console.log);
בקוד המקור של onFCP()
תוכלו למצוא דוגמה מלאה למדידת FCP ב-JavaScript.
איך משפרים את FCP
כדי ללמוד איך לשפר את FCP באתר ספציפי, אפשר להריץ בדיקת ביצועים של Lighthouse ולשים לב להזדמנויות או לאבחון ספציפיות שהביקורת מציעה.
כדי לקבל מידע על שיפור FCP באופן כללי (בכל אתר), אפשר לעיין במדריכים הבאים בנושא ביצועים:
- הסרת משאבים שחוסמים את העיבוד
- צמצום קוד CSS
- הסרת CSS שאינו בשימוש
- הסרת JavaScript שלא נמצא בשימוש
- יצירת קישור מראש למקורות נדרשים
- קיצור זמני התגובה של השרת (TTFB)
- הימנעות מהפניות אוטומטיות מרובות לדפים
- טעינה מראש של בקשות למפתחות
- נמנעים ממטענים ייעודיים (payloads) עצומים ברשת
- הצגה של נכסים סטטיים באמצעות מדיניות מטמון יעילה
- הימנעות מנפח DOM גדול מדי
- צמצום עומק הבקשות הקריטיות
- מוודאים שהטקסט נשאר גלוי במהלך טעינת ה-webfont
- יש לצמצם ככל האפשר את מספר הבקשות ואת גודל ההעברות
יומן שינויים
מדי פעם מתגלים באגים בממשקי ה-API שמשמשים למדידת מדדים, ולפעמים גם בהגדרות של המדדים עצמם. לכן, לפעמים צריך לבצע שינויים, והשינויים האלה יכולים להופיע בדוחות הפנימיים ובלוחות הבקרה שלכם כשיפורים או נסיגות.
כדי לעזור לכם לנהל את זה, כל השינויים בהטמעה או בהגדרה של המדדים האלה יופיעו ביומן השינויים הזה.
אם יש לכם משוב על המדדים האלה, אתם יכולים לשלוח אותו בקבוצת Google בנושא web-vitals-feedback.