אופטימיזציה של FID (השהיית קלט ראשונית) עבור 1C-Bitrix
נתקלנו בפרויקטים שבהם INP הגיע ל-1500 אלפיות השנייה בחנות Bitrix טיפוסית. לחיצה על כפתור "קנייה" — והמשתמש ממתין יותר משנייה. כל 100 אלפיות השנייה של עיכוב מפחיתות את ההמרה ב-7%. זה אובדן הכנסות ישיר. הניסיון שלנו מראה: אופטימיזציה מוגדרת כראוי של FID/INP מניבה INP < 200 אלפיות השנייה תוך 5–10 ימים במפתח מלא. נבחן את הפרויקט שלך בחינם.
FID (השהיית קלט ראשונית) — הזמן מהאינטראקציה הראשונה ועד לתגובת הדפדפן, המתואר בתקני ביצועי האינטרנט (ראה ויקיפדיה). גוגל החליפה את FID ב-INP (אינטראקציה לציור הבא), המודד את כל האינטראקציות. ספים: FID < 100 אלפיות השנייה, INP < 200 אלפיות השנייה. באתרי Bitrix כבדים, INP יכול להגיע ל-500–1500 אלפיות השנייה. אופטימיזציה מפחיתה את זמן ההשהיה פי 2.5 בעת יישום פיצול קוד.
למה INP חשוב לעסקים
כל אלפית שנייה נוספת של עיכוב משמעותה אובדן לקוח. מחקר של גוגל מראה שאם INP עולה על 200 אלפיות השנייה, הסבירות לנטישה עולה ב-32%. עבור חנות מסחר אלקטרוני על Bitrix, זה אומר עשרות הזמנות אבודות ביום. באחד הפרויקטים שלנו, הפחתנו את INP מ-800 ל-150 אלפיות השנייה — ההמרה עלתה ב-15%. ההשקעה באופטימיזציה מחזירה את עצמה תוך 2-3 חודשים.
למה הדפדפן לא מגיב ללחיצות
הדפדפן הוא חד-חוטי: בזמן שהחוט הראשי עסוק בביצוע JavaScript, הוא לא יכול לעבד אירועי קלט. המשתמש לוחץ על כפתור — הלחיצה נכנסת לתור וממתינה ש-JS יסיים את המשימה הנוכחית. משימות ארוכות עם משך > 50 אלפיות השנייה הן הגורם העיקרי ל-INP גבוה.
מקורות למשימות ארוכות ב-Bitrix:
- טעינה וניתוח של חבילות JS גדולות: jQuery + תוספים + רכיבים = 500 KB – 1 MB
- אתחול של סליידרים, שדות מסכה, מפות, ווידג'טים ב-
DOMContentLoaded - מטפלי אירועים כבדים: פילטר קטלוג, חישוב מחדש של עגלה
- בקשות AJAX סינכרוניות (חוסמות את החוט)
איך לאבחן משימות ארוכות: מדריך שלב אחר שלב
- פתח את Chrome DevTools (F12) ועבור ללשונית Performance.
- לחץ על כפתור Record (סמל עיגול).
- בצע אינטראקציה עם הדף: גלול, לחץ על כפתור.
- עצור את ההקלטה וחפש פסים אדומים מעל ציר הזמן — אלה משימות ארוכות > 50 אלפיות השנייה.
- לחץ על משימה כדי לראות את מחסנית הקריאות: איזה סקריפט תפס את החוט הראשי.
עבור INP, הפעל 'Web Vitals' ב-DevTools וחזור על האינטראקציה. ניתן גם להשתמש בניטור קונסולה:
const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.duration > 50) { console.warn('Long task:', entry.duration.toFixed(1) + 'ms', entry); } } }); observer.observe({ type: 'longtask', buffered: true }); // Пример ленивой загрузки слайдера if (document.querySelector('.main-slider')) { import('./swiper.min.js').then(({ default: Swiper }) => { new Swiper('.main-slider', { /* ... */ }); }); } מה זה פיצול קוד ואיך הוא עוזר
Bitrix סטנדרטי טוען את כל ה-JS בכל עמוד: jQuery, תוספי קטלוג, סקריפטים של עגלה, סליידרים, מפות — הכל בבת אחת. עמוד עם 1 MB JS מבצע את כל זה בטעינה. פיצול קוד מפחית את INP ל-200 אלפיות השנייה לעומת 500+ אלפיות השנייה בלעדיו — זה פי 2.5 מהר יותר.
בהקשר של Bitrix — דרך const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.duration > 50) { console.warn('Long task:', entry.duration.toFixed(1) + 'ms', entry); } } }); observer.observe({ type: 'longtask', buffered: true }); // Пример ленивой загрузки слайдера if (document.querySelector('.main-slider')) { import('./swiper.min.js').then(({ default: Swiper }) => { new Swiper('.main-slider', { /* ... */ }); }); } בתבניות רכיב ספציפיות, לא ב-\Bitrix\Main\Page\Asset::addJs().
Defer ו-Async עבור סקריפטים
<!-- Синхронный — блокирует парсинг HTML --> <script src="/bitrix/js/plugin.js"></script> <!-- defer — загружается параллельно, выполняется после парсинга HTML --> <script src="/bitrix/js/plugin.js" defer></script> <!-- async — загружается и выполняется как можно раньше --> <script src="/bitrix/js/analytics.js" async></script> header.php — עבור סקריפטים שצריכים את ה-DOM (אתחול רכיבים). <!-- Синхронный — блокирует парсинг HTML --> <script src="/bitrix/js/plugin.js"></script> <!-- defer — загружается параллельно, выполняется после парсинга HTML --> <script src="/bitrix/js/plugin.js" defer></script> <!-- async — загружается и выполняется как можно раньше --> <script src="/bitrix/js/analytics.js" async></script> — עבור סקריפטים עצמאיים (אנליטיקה, תגי פרסום). ב-Bitrix, קבצי JS שנוספו דרך defer מוצגים ללא async. כדי להוסיף את התכונה — יישום מותאם אישית דרך ה-hook של \Bitrix\Main\Page\Asset::addJs() או דריסת תבנית פלט הסקריפט.
מטפלי אירועים כבדים
מטפל לחיצה שמבצע חישובי DOM סינכרוניים על 200 אלמנטים חוסם את החוט למשך הזמן. INP יהיה שווה לזמן המטפל. Debounce יכול להפחית את זמן ההשהיה בעד 300 אלפיות השנייה.
דפוסי שיפור: Debounce עבור אירועים תכופים (קלט חיפוש, שינוי פילטר):
let debounceTimer; searchInput.addEventListener('input', function() { clearTimeout(debounceTimer); debounceTimer = setTimeout(() => { doSearch(this.value); }, 300); }); שבירת פעולות כבדות דרך defer או OnEndBufferContent:
async function processLargeList(items) { for (let i = 0; i < items.length; i += 50) { const chunk = items.slice(i, i + 50); processChunk(chunk); await new Promise(resolve => setTimeout(resolve, 0)); } } Web Workers עבור חישובים: אם מטפל אירועים דורש חישובים כבדים (מיון, סינון מערכים גדולים) — העבר ל-Web Worker. רץ בחוט נפרד, לא חוסם את ממשק המשתמש.
סקריפטים של צד שלישי
JivoSite, MetrikaTag, Google Analytics, פיקסלים של מדיה חברתית — כל אחד מוסיף JS שמתבצע על החוט הראשי. עם 5–10 סקריפטים של צד שלישי, עומס האתחול הכולל יכול להיות 200–500 אלפיות השנייה של משימות ארוכות.
אסטרטגיה:
- טען סקריפטים של צד שלישי עם
let debounceTimer; searchInput.addEventListener('input', function() { clearTimeout(debounceTimer); debounceTimer = setTimeout(() => { doSearch(this.value); }, 300); });או אחרי אירועsetTimeout - השתמש ב-
scheduler.postTaskעבור סקריפטים לא קריטיים - בדוק אם כל הווידג'טים המחוברים נחוצים — לעתים קרובות יש כאלה שאינם בשימוש
// Загрузить аналитику после idle window.addEventListener('load', () => { requestIdleCallback(() => { const script = document.createElement('script'); script.src = 'https://analytics-provider.com/tag.js'; script.async = true; document.head.appendChild(script); }); }); טעויות נפוצות באופטימיזציה של INP
- יישום פיצול קוד אבל השארת סקריפטים סינכרוניים בתבנית — האפקט אובד.
- טעינת כל הסקריפטים עם
async function processLargeList(items) { for (let i = 0; i < items.length; i += 50) { const chunk = items.slice(i, i + 50); processChunk(chunk); await new Promise(resolve => setTimeout(resolve, 0)); } }— סדר הביצוע לא מובטח, באגים פוטנציאליים. - אי אימות לאחר אופטימיזציה: INP עשוי לעלות בגלל ווידג'טים חדשים.
- שכחת רינדור בצד השרת (TTFB) — אם השרת איטי, אופטימיזציית JS לא תעזור.
מה כלול בעבודת האופטימיזציה
| תוצר | תיאור |
|---|---|
| ביקורת משימות ארוכות | ניתוח ביצועים מלא, רשימת גורמים |
| פיצול קוד | פיצול חבילות, טעינה עצלה |
| המרה ל-Defer/Async | הגדרת תכונות עבור כל הסקריפטים |
| Debounce/רפקטורינג | אופטימיזציה של מטפלי אירועים |
| דחיית צד שלישי | דחיית סקריפטים לא קריטיים |
| תיעוד והדרכה | מדריך תחזוקה |
לוחות זמנים לאופטימיזציה
| משימה | משך | אפקט |
|---|---|---|
| ביקורת משימות ארוכות דרך DevTools | 0.5 יום | הבנת הבעיה |
| המרת סקריפטים ל-defer | יום אחד | INP יורד ב-50–200 אלפיות השנייה |
| דחיית סקריפטים של צד שלישי | 0.5 יום | INP יורד ב-100–300 אלפיות השנייה |
| Debounce לחיפוש ופילטרים | יום אחד | INP של פילטר יורד ב-200–500 אלפיות השנייה |
| פיצול קוד לרכיבים כבדים | 3–5 ימים | INP של עמוד קטלוג יורד ב-200–500 אלפיות השנייה |
| רפקטורינג למטפלי אירועים כבדים | 2–5 ימים | INP < 200 אלפיות השנייה |
תוצאה טובה לחנות Bitrix היא INP < 200 אלפיות השנייה. זה מושג כאשר חבילת ה-JS הכוללת < 200 KB (לאחר ניתוח) ואין משימות ארוכות > 100 אלפיות השנייה באינטראקציה.
אנחנו צוות עם ניסיון של 10+ שנים ב-Bitrix, מומחים מוסמכים. השלמנו 50+ פרויקטים של אופטימיזציית מהירות. אנו מבטיחים השגת INP < 200 אלפיות השנייה או המשך עידון על חשבוננו. אנו מספקים רשימת בדיקה וניטור לאחר היישום.
צור קשר להערכה חינמית של הפרויקט שלך. הזמן ביקורת ביצועים היום וקבל ייעוץ על אופטימיזציית FID/INP לאתר ה-Bitrix שלך.







