בוחרים לפי הצורך
השירותים שלנו
מחליטים מתוך הבנה
אסטרטגיה וצמיחה
מוצאים את הפתרון
אתר יכול להיראות טעון ועדיין להרגיש תקוע כשמבקר לוחץ, מקליד או פותח תפריט.
מערכת AI Click · עודכן בספטמבר 2026 · כ־6 דקות קריאה
INP בוחן את הזמן מרגע אינטראקציה ועד שהדפדפן מציג תגובה, ומייצג תגובתיות לאורך הביקור, תוך התחשבות באינטראקציות האיטיות. המדד אינו זמן טעינת שרת, אינו מדד גלילה ואינו FID הישן. מדריך זה הופך את המספר לתהליך: משחזרים פעולה אמיתית, מפרקים את הזמן, מוצאים long task או קוד צד שלישי, נותנים משוב מיידי בלי להעמיד פנים שפעולה עסקית הושלמה, ובודקים מחדש. יעד טוב הוא INP עד 200 מילישניות באחוזון 75, בפילוח נייד ומחשב. אין להסתפק בשאלה אם הדף נטען: צריך לשאול מה קורה ברגע שהמבקר מנסה להתקדם. בדיקה טובה כוללת מסלול שימוש מוגדר, קלט שאינו מידע אמיתי, ותיעוד של התוצאה הנראית. כך אפשר לשפר את הממשק בלי להקריב אמינות, נגישות, אבטחה או שלמות עסקה.
INP מתייחס לאינטראקציות כמו click, tap והקלדה, מרגע שהמשתמש מפעיל אותן עד שהדפדפן מצייר את הפריים הבא. הוא אינו מודד כמה זמן לקח הדף להיטען, אינו ציון על גלילה, ואינו מודד לבדו זמן תגובת API או שרת. אם לחיצה מפעילה בקשת רשת, INP בוחן את הזמן עד שהממשק מציג תגובה, ולא את כל ההמתנה האסינכרונית עד שהשרת סיים את העסקה. לכן כפתור יכול להציג מצב טעינה מיד ועדיין להמתין לתוצאה עסקית. היעד הטכני צריך להישמר לצד שימושיות: תגובה נראית, מצב פוקוס, הודעת שגיאה ויכולת להמשיך.
מפרקים אינטראקציה לשלושה שלבים. input delay הוא זמן שבו הדפדפן לא התחיל לטפל באירוע, לרוב כי משימה אחרת חסמה את ה־main thread. processing duration הוא הזמן שבו handlers וקוד שהופעלו בעקבות האירוע מעבדים עבודה. presentation delay הוא הזמן מסיום העיבוד עד שהעדכון נצבע ומוצג. אותה תחושה של כפתור איטי יכולה להגיע מכל אחד מהם. הקטנת JavaScript לא בהכרח מתקנת input delay אם תוסף צד שלישי מריץ long task לפני הלחיצה, וייעול handler לא יתקן presentation delay שנגרם מ־layout או CSS. מודדים את השלבים לפני בחירת תיקון.
פותחים את האתר במכשיר ובדפדפן שמייצגים מבקרים, מבצעים ביקור רגיל, ואז לוחצים, מקישים ומקלידים בפעולות מוגדרות. רושמים URL, viewport, סוג מכשיר, מצב cache, התחברות, פעולה ותוצאתה. נתוני שטח נאספים מאוכלוסייה לאורך חלון זמן, ולכן אינם זהים להרצה אחת במעבדה. המעבדה מועילה ל־trace שחושף long task וסדר סקריפטים, אך אינה הוכחה שכל משתמש חווה אותו דבר. בודקים נייד ומחשב בנפרד, ומסמנים אם הפעולה התרחשה לאחר טעינה, אחרי פתיחת תפריט או בזמן רכיב דינמי. כך נמנעת מסקנה שמבוססת על לחיצה אקראית אחת.
בחרו מסלול קצר שמבקר אמיתי מבצע: פתיחת תפריט מובייל, מעבר באקורדיון, בחירת מסנן, הקלדה בשדה חיפוש, פתיחת חלונית, שינוי כמות או מעבר בין שדות טופס עם מקלדת. בכל פעולה שאלו מה המשתמש אמור לראות מיד: תפריט שנפתח, סימון בחירה, spinner, הודעת בדיקה או פוקוס שנשמר. בדקו גם click וגם keyboard, כי handler שמחובר רק לעכבר פוגע בנגישות ובמדידה. אין לשלוח ליד אמיתית, לבצע הזמנה או לשנות נתוני לקוח בבדיקה. משתמשים בסביבת בדיקה, בקלט דמה ובשלב עצירה לפני פעולה בלתי הפיכה.
Long task הוא מקטע עבודה ארוך שחוסם את ה־main thread ומונע מהדפדפן להגיב. ב־trace מחפשים מי הפעיל אותו: bundle של האתר, בניית DOM, חישוב סגנונות, אנליטיקה, צ׳אט, מפה או תג שיווקי. הפתרון אינו תמיד מחיקה; לעיתים מפצלים עבודה, דוחים קוד שאינו נחוץ לאינטראקציה, או מאפשרים לדפדפן לקבל תור בין חלקי עבודה. yielding יכול להחזיר שליטה לממשק, אך אם המשתמש ממתין לתוצאה אין להציג הצלחה מזויפת. מפתחים מתעדים איזה task חולק, מה קורה אם המשתמש לוחץ שוב, ומה מצב הביטול. בדיקת הקבלה דורש שהפעולה עדיין תושלם נכון, לא רק שתיראה מהירה.
סקריפט צד שלישי יכול להוסיף listeners, לבצע מדידה או לבנות רכיבים בדיוק בזמן לחיצה. השוו trace עם ובלי הסקריפט בסביבת בדיקה, בדקו מתי הוא נטען ומה ערכו העסקי, ואז בחרו דחייה, טעינה לפי צורך או הסרה. אין להכריז שכל analytics הוא אויב, מפני שמדידה עשויה להיות דרישה עסקית מוצדקת. מתעדים בעלים, מטרה, תנאי טעינה והשפעה על נייד. אם דחיית צ׳אט משפרת INP אך מונעת שירות חשוב, מחפשים תנאי טעינה שאינו חוסם את הפעולה עצמה או מסלול נגיש חלופי. כל שינוי צריך להיות הפיך ולכלול בדיקת consent, מעקב ואירועי שגיאה.
בטופס בודקים מעבר שדה, validation בזמן הקלדה, הודעה אחרי blur ולחיצה על שליחה עם קלט שגוי. במסנן בודקים בחירה אחת, בחירות רצופות, איפוס והצגת מספר תוצאות. בתפריט מובייל בודקים פתיחה, סגירה, תתי־תפריטים, Escape, Tab וגלילה כשהתפריט פתוח. רושמים אם כל עיכוב מגיע מעבודה מקומית או מבקשת רשת. תגובה מיידית יכולה להיות שינוי aria-expanded, פוקוס או מצב טעינה; היא אינה אישור שהליד נשלח. אין לבצע שליחת ליד או הזמנה אמיתית כחלק מהבדיקה. אם פעולה תלויה בשרת, מנסחים בדיקת הקבלה נפרד לממשק ולתוצאה העסקית.
דוגמה להמחשה: באתר קטלוג, לחיצה על מסנן לוקחת 850 מילישניות. ה־trace מראה input delay של 500 בגלל תג צ׳אט שמריץ long task, processing של 120 לבניית רשימה, ו־presentation של 230 בגלל עדכון DOM גדול. הקטנת זמן ה־API לא הייתה מתקנת את רוב ההמתנה, כי INP אינו זמן שרת. צוות אחד דוחה את תג הצ׳אט, מציג בחירה מיד, ומעדכן רשימה במנות; צוות אחר מעמיס פחות פריטים בבת אחת. בודקים שלא נעלמו תוצאות, שהמקלדת נשארת פעילה, ושספירת התוצאות נכונה. אם המשתמש לוחץ פעמיים, אין שתי בקשות או מצב שקרי.
כדי להפריד בין עיכוב הממשק לבין ההמתנה לתוצאות, רושמים שני זמנים שונים: מתי נראה שהבחירה נקלטה, ומתי הרשימה סיימה להתעדכן. לקוח עשוי לקבל תגובה חזותית מהירה ועדיין להמתין זמן רב למוצרים. במקרה כזה לא מסיימים את הטיפול רק משום ש־INP השתפר. בוחנים את הבקשה, גודל התשובה ומצב השגיאה בנפרד, ומציגים הודעה ברורה כאשר העדכון נכשל. שמירת המסנן הקודם מאפשרת למבקר להבין מה הוא רואה גם בזמן ההמתנה.
לפני שינוי שומרים baseline של האינטראקציה, trace, מדדי שטח, שגיאות JavaScript ותקינות פעולה. משנים גורם אחד, למשל דחיית widget או פיצול handler, ולא אוסף הגדרות שקשה לייחס. אחרי פרסום השינוי בודקים במכשיר חלש, במחשב, עם מקלדת, עם cache ריק וחם, ובמסלול שבו אין תוצאה. בדיקת הקבלה כולל תגובה נראית, הודעת כשל אמינה, focus נכון, מניעת double submit ואי־פגיעה באנליטיקה הנחוצה. אם INP השתפר אך הפעולה איבדה משוב או נגישות, מחזירים. חזרה לגרסה הקודמת מוגדר מראש: ביטול feature flag, החזרת bundle או שחזור תנאי טעינה, עם בדיקה שהגרסה הישנה שוב פעילה.
INP טוב יותר מפחית תחושת תקיעות ברגע שבו מבקר מנסה להתקדם, אבל אינו מבטיח המרה או דירוג. בעל אתר צריך לקבל רשימת אינטראקציות, אוכלוסייה, מכשירים, מקור העיכוב, שינוי שבוצע ותופעות לוואי. אין להשתמש בציון 100 או בהרצה יחידה כהוכחה לחוויה יציבה. אם שיפור דורש לבטל הודעת שגיאה, להסתיר מצב טעינה או לאשר עסקה לפני תשובת שרת, זה תיקון מסוכן. המטרה היא ממשק שמכיר בקלט מיד, מציג מצב אמיתי ומסיים פעולה נכונה. מדידה מחזורית של פעולות מרכזיות חשובה יותר מרדיפה אחרי מספר מנותק מהמסלול העסקי.
לא. גלילה וריחוף אינם נכללים במדד; לחיצות, הקשות והקלדה נכללות. עדיין חשוב לבדוק שגלילה מרגישה חלקה.
לא. הוא מודד תגובת ממשק עד הצגה. בקשת שרת עשויה להמשיך אחרי משוב מיידי למשתמש.
לא. בודקים גם tap, הקלדה, Tab, Enter ו־Escape במסלולים מרכזיים ונגישים.
עד 200 מילישניות באחוזון 75 נחשב יעד טוב, בפילוח נייד ומחשב, אך צריך לבדוק פעולה אמיתית.
בחרו עמוד אחד או תהליך אחד מהמדריך, תעדו את המצב הקיים ובדקו מה דורש טיפול. אם צריך עזרה באבחון ובהחלטה מה לקדם קודם, אפשר לפנות עם הכתובת והבעיה שמצאתם.