מהו INP (Interaction to Next Paint) וכיצד לשפר אותו בוורדפרס

אם אתר הוורדפרס שלכם מגיב לאט כשמשתמשים לוחצים על כפתורים, פותחים תפריטים או ממלאים טפסים – אז דעו שיש מדד Core Web Vital שנועד למדוד בדיוק את זה. הוא נקרא INP, או בשמו המלא Interaction to Next Paint.

גוגל החליפו את המדד הקודם, FID (או First Input Delay), ב-INP ב-12 במרץ 2024. בעוד FID מדד רק את ההשהיה של האינטראקציה הראשונה בלבד, INP עוקב אחרי כל אינטראקציה שהמשתמש מבצע במהלך הביקור ומדווח על הגרועה מביניהן.

בפוסט זה אסביר מהו INP, במה הוא שונה מ-FID, כיצד למדוד אותו, ואילו תיקונים ספציפיים לוורדפרס תוכלו ליישם כבר היום.

מהו Interaction to Next Paint (INP)?

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

ערך ה-INP הסופי של ביקור בדף הוא האינטראקציה הארוכה ביותר שנצפתה לאורך כל הסשן (עם סינון חריגים בדפים שיש בהם אינטראקציות רבות).

ערכי INP טובים הם 200 מילישניות או פחות. ערכים גרועים הם מעל 500 מילישניות. – web.dev

הנה הספים:

• Good (טוב): 200 ms או פחות
• Needs Improvement (דורש שיפור): בין 200 ms ל-500 ms
• Poor (גרוע): מעל 500 ms

גוגל מודדים את INP באחוזון ה-75 של טעינות דף, בחלוקה בין מובייל לדסקטופ. אם 75% מהמבקרים שלכם חווים אינטראקציות מתחת ל-200 ms, הדף עובר.

ההבדל בין INP ל-FID

FID מדד רק את ה-input delay של האינטראקציה הראשונה בדף. כלומר הוא התעלם משני דברים חשובים.

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

שנית, FID מדד רק את ההשהיה לפני שהדפדפן התחיל לעבד את האירוע. הוא לא מדד כמה זמן לקח ל-event handler לרוץ, או כמה זמן הדפדפן צריך כדי לצייר את התוצאה.

בפועל, אתר יכול היה לעבור את FID בקלות (מכיוון שהאינטראקציה הראשונה קרתה כשה-main thread היה פנוי) ועדיין להרגיש איטי באינטראקציות מאוחרות יותר. INP תופס בדיוק את הבעיות האלה.

שלושת השלבים של INP

כל אינטראקציה ש-INP מודד עוברת שלושה שלבים נפרדים. הבנה שלהם תעזור לכם להבין היכן לרכז את מאמצי האופטימיזציה.

Input Delay

זהו הזמן שעובר בין רגע האינטראקציה של המשתמש (למשל לחיצה על כפתור) לבין הרגע שבו הדפדפן מתחיל להריץ את ה-event handler של אותה אינטראקציה.

Input delay קורה כשה-main thread עסוק בעבודה אחרת – בדרך כלל משימות JavaScript ארוכות. אם סקריפט אנליטיקס צד-שלישי מריץ משימה של 300 ms כשהמשתמש לוחץ, הדפדפן לא יכול להתחיל לעבד את הלחיצה עד שאותה משימה מסתיימת.

Processing Time

זהו הזמן שהדפדפן מקדיש להרצת ה-event handler callbacks עצמם. אם ה-click handler שלכם מבצע מניפולציית DOM מורכבת, שולף נתונים באופן סינכרוני, או מפעיל רנדור מחדש כבד – זמן העיבוד עולה.

אינטראקציה בודדת יכולה להפעיל מספר event handlers (למשל pointerdown, pointerup, click). זמן העיבוד הוא משך הזמן המשולב של כולם.

Presentation Delay

אחרי שה-event handlers מסיימים, הדפדפן עדיין צריך לחשב מחדש סגנונות, להריץ layout ולצייר את הפיקסלים המעודכנים. זהו ה-presentation delay.

עצי DOM גדולים, סלקטורי CSS מורכבים וחישובי layout מאולצים (layout thrashing) – כולם מגדילים את ה-presentation delay. אם בדף שלכם אלפי צמתי DOM, כל חישוב סגנונות מחדש לוקח יותר זמן.

כיצד למדוד INP

עומדים לרשותכם מספר כלים למדידה ואבחון של בעיות INP.

PageSpeed Insights (נתוני שטח)

הדרך הפשוטה ביותר לבדוק את ה-INP של האתר שלכם היא PageSpeed Insights. החלק ״Discover what your real users are experiencing״ בראש הדף מציג נתוני שטח מתוך Chrome User Experience Report (בקצרה CrUX).

אם לדף שלכם אין מספיק תנועה לנתוני CrUX, INP יציג ״N/A״. במקרה כזה, עברו לתצוגת ״Origin״ כדי לראות נתונים מצטברים על פני כל הדומיין.

PageSpeed Insights (אבחונים)

גללו מטה מעבר לציון Lighthouse כדי למצוא את חלק ה-Diagnostics. חפשו ערכים כמו ״Minimize main-thread work״, ״Reduce JavaScript execution time״ ו-״Avoid an excessive DOM size״ – אלה משפיעים ישירות על INP.

בעוד Lighthouse מודד Total Blocking Time (בקצרה TBT) ולא INP ישירות, TBT הוא פרוקסי מעבדתי חזק ל-INP. הפחתת TBT כמעט תמיד משפרת את INP.

למדריך מפורט יותר על קריאת דוחות PageSpeed, תנו מבט בפוסט שלי על מדריך Google PageSpeed למשתמשי וורדפרס.

Chrome DevTools Performance Panel

לדיבאג מעשי, פתחו את Chrome DevTools (F12), עברו ללשונית Performance, והקליטו סשן תוך כדי אינטראקציה עם הדף. חפשו את ה-״Interactions״ lane ב-timeline – הוא מציג את משך הזמן של כל אינטראקציה בפירוט לשלושת השלבים.

תוסף Web Vitals ל-Chrome

תוסף Web Vitals ל-Chrome מציג ערכי INP בזמן אמת תוך כדי גלישה. הוא שימושי לבדיקות מהירות בזמן פיתוח ובדיקות.

מה גורם ל-INP גרוע בוורדפרס

לאתרי וורדפרס יש דפוסים נפוצים שמובילים לציוני INP גרועים. הנה הגורמים השכיחים ביותר.

סקריפטים של צד שלישי

מעקבי אנליטיקס, ווידג'טים של צ'אט, רשתות פרסום, הטמעות רשתות חברתיות ופיקסלים שיווקיים – כולם מוסיפים JavaScript שרץ על ה-main thread. כשמשתמש מבצע אינטראקציה עם הדף בזמן שאחד הסקריפטים האלה רץ, הדפדפן לא יכול להגיב עד שהסקריפט מסיים.

Google Tag Manager לבדו יכול להוסיף עשרות תגיות, כל אחת מריצה JavaScript משלה. Facebook Pixel, הקלטות סשן של Hotjar וווידג'טים של צ'אט חי הם גם אשמים נפוצים.

תבניות ותוספים כבדים

בוני עמודים כמו Elementor ו-Divi טוענים כמויות משמעותיות של JavaScript ויוצרים עצי DOM גדולים. תוספי סליידר, תוספי מגה-מניו והרחבות WooCommerce – כולם תורמים לעומס על ה-main thread.

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

גודל DOM מוגזם

בוני עמודים לוורדפרס ידועים ביצירת מבני HTML מקוננים עמוקות. סקשן בודד של Elementor יכול לייצר עשרות אלמנטי div עוטפים. כשה-DOM חורג מ-1,500 צמתים, כל חישוב סגנונות מחדש וכל מעבר layout לוקח יותר זמן, מה שמגדיל את שלב ה-presentation delay.

לאסטרטגיות ספציפיות לטיפול בבעיה, תנו מבט במדריך שלי על ניהול גודל ה-DOM ותיקון Excessive DOM Size.

Event Handlers לא מותאמים

מאזיני scroll ללא throttling, מטפלי resize שמפעילים חישובי layout מחדש, ו-click handlers שעושים קריאות DOM סינכרוניות ואחריהן כתיבות (layout thrashing) – כולם מגדילים את זמן העיבוד.

כיצד לשפר INP בוורדפרס

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

דחייה והשהיה של JavaScript לא קריטי

הדבר המשפיע ביותר שתוכלו לעשות עבור INP הוא להוריד JavaScript מה-main thread בזמן טעינת הדף. יש כאן שתי גישות שונות.

דחייה (deferring) של סקריפט פירושה שהדפדפן מוריד אותו במקביל לניתוח ה-HTML ומריץ אותו אחרי שהמסמך נותח, אבל לפני אירוע ה-DOMContentLoaded. וורדפרס 6.3 ומעלה מאפשרת לעשות זאת באופן מובנה עם פרמטר ה-strategy של wp_enqueue_script:

wp_enqueue_script(
    'my-script',
    get_template_directory_uri() . '/js/my-script.js',
    array(),
    '1.0',
    array( 'strategy' => 'defer' )
);

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

התוסף החינמי Flying Scripts מטפל בזה היטב. מוסיפים מילות מפתח שמזהות סקריפטים להשהיה (למשל gtag, fbevents, hotjar), והם לא ירוצו עד לאינטראקציה הראשונה של המשתמש או timeout שהגדרתם.

תוספים פרימיום כמו WP Rocket ו-Perfmatters מציעים את אותה פונקציונליות עם בקרות נוספות. למידע נוסף על אופן הטיפול של WP Rocket בהחרגות סקריפטים, תנו מבט בפוסט שלי על החרגת סקריפטים מ-Load JS Deferred של WP Rocket.

הסרת JavaScript ו-CSS שאינם בשימוש

כל קובץ JavaScript ו-CSS שהדפדפן טוען הוא עבודה שה-main thread צריך לטפל בה. הסרת מה שאינכם צריכים מפחיתה הן את ה-input delay והן את ה-presentation delay.

השתמשו בתוסף כמו Asset CleanUp או Perfmatters כדי לבטל סקריפטים וסגנונות בדפים שבהם הם לא נדרשים. לדוגמה, אם אתם משתמשים ב-Contact Form 7, ה-JavaScript וה-CSS שלו נטענים בכל דף כברירת מחדל – אבל אתם צריכים אותם רק בדף יצירת הקשר.

צעדים לביקורת משאבים לא בשימוש:

1. פתחו את Chrome DevTools ועברו ללשונית Coverage (לחצו Ctrl+Shift+P, הקלידו ״coverage״)
2. לחצו על כפתור ה-reload כדי להתחיל להקליט
3. בדקו את העמודה ״Unused Bytes״ – כל דבר מעל 70-80% לא בשימוש הוא מועמד להסרה
4. השתמשו ב-Asset CleanUp בממשק הניהול של וורדפרס כדי לבטל את אותם משאבים בדפים שבהם הם לא נחוצים

הקטנת גודל ה-DOM

DOM קטן יותר פירושו חישובי סגנונות ומעברי layout מהירים יותר, מה שמפחית ישירות את ה-presentation delay.

אם אתם משתמשים בבונה עמודים, שקלו לעבור לבלוקים המובנים של וורדפרס עבור layouts פשוטים. עורך הבלוקים מייצר HTML נקי יותר עם פחות אלמנטים עוטפים.

עבור חנויות WooCommerce, דפי רשימת מוצרים יכולים להפוך לגדולים מאוד. הטמיעו פגינציה או ״טען עוד״ במקום להציג את כל המוצרים בבת אחת. שמרו על DOM מתחת ל-1,500 צמתים כשאפשר.

אופטימיזציית Event Handlers וסקריפטים של צד שלישי

אם אתם כותבים JavaScript מותאם אישית לאתר הוורדפרס שלכם, שמרו על event handlers רזים.

הגבילו מאזיני scroll ו-resize. במקום להריץ קוד על כל אירוע scroll (שיכול להתרחש מאות פעמים בשנייה), השתמשו ב-requestAnimationFrame או בפונקציית throttle:

let ticking = false;
document.addEventListener('scroll', () => {
    if (!ticking) {
        requestAnimationFrame(() => {
            // your scroll logic here
            ticking = false;
        });
        ticking = true;
    }
});

הימנעו מ-layout thrashing. אל תקראו מאפייני layout (כמו offsetHeight או getBoundingClientRect()) ואז מיד תכתבו ל-DOM בלולאה. קבצו את הקריאות שלכם, ואז קבצו את הכתיבות:

// Bad: causes layout thrashing
elements.forEach(el => {
    const height = el.offsetHeight; // read (forces layout)
    el.style.height = height + 10 + 'px'; // write
});

// Good: batch reads, then batch writes
const heights = elements.map(el => el.offsetHeight);
elements.forEach((el, i) => {
    el.style.height = heights[i] + 10 + 'px';
});

פיצול משימות ארוכות עם scheduler.yield()

משימות ארוכות (כל דבר מעל 50 ms) חוסמות את ה-main thread ומגדילות את ה-input delay. ה-API של scheduler.yield() מאפשר לפצל משימה ארוכה לחלקים קטנים, ונותן לדפדפן הזדמנות לטפל באינטראקציות משתמש ביניהם.

async function processItems(items) {
    for (const item of items) {
        doWork(item);

        // Yield to the browser so it can handle interactions
        await scheduler.yield();
    }
}

חלופה ישנה יותר שעדיין עובדת בכל מקום היא setTimeout(callback, 0), שמפנה מקום לדפדפן אבל לא שומרת על עדיפות המשימה כמו ש-scheduler.yield() עושה.

שאלות נפוצות

שאלות נפוצות על אופטימיזציית INP לוורדפרס:

סיכום

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

כדי לשפר INP באתר הוורדפרס שלכם, התמקדו בשלושת השלבים: הפחיתו input delay על ידי דחייה והשהיה של סקריפטים לא קריטיים, מזערו processing time על ידי שמירה על event handlers רזים, וקצצו presentation delay על ידי הקטנת גודל ה-DOM. התחילו עם התוסף החינמי Flying Scripts כדי להשהות סקריפטים של צד שלישי, בצעו ביקורת על התוספים שלכם לגבי JavaScript לא בשימוש, ובדקו את ספירת צמתי ה-DOM. שינויים קטנים וממוקדים מצטברים מהר.