אופטימיזציית FID/INP עבור 1C-Bitrix: האצת תגובת האתר

אופטימיזציית FID (השהיית קלט ראשונה) עבור 1C-Bitrix נתקלנו בפרויקטים שבהם INP הגיע ל-1500 אלפיות השנייה בחנות Bitrix טיפוסית. לחיצה על כפתור "קנה" - והמשתמש ממתין יותר משנייה. כל עיכוב של 100 אלפיות השנייה מפחית את ההמרה ב-7%. זהו אובדן הכנסה ישיר. הניסיון שלנו מראה: א
השירותים שאנו מציעים
מציג 1 מתוך 1כל 1626 השירותים
אופטימיזציית FID/INP עבור 1C-Bitrix: האצת תגובת האתר
בינוני
~1-2 שבועות

הכישורים שלנו:

שאלות נפוצות

העבודות האחרונות

  • image_website-b2b-advance_0.webp
    פיתוח אתר חברה B2B ADVANCE
    1456
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    פיתוח אתר לחברת FIXPER
    1018
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    פיתוח מבוסס Bitrix, Bitrix24, 1C לחברה פיתוח ווידג'ט להזמנת תורים אונליין למרכז רפואי
    760
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    פיתוח על בסיס 1C Enterprise עבור MIRSANBEL
    879
  • image_crm_dolbimby_434_0.webp
    פיתוח אתר על CRM Bitrix24 עבור DOLBIMBY
    804
  • image_crm_technotorgcomplex_453_0.webp
    פיתוח על בסיס Bitrix24 עבור חברת TECHNOTORGKOMPLEKS
    1162

אופטימיזציה של 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 סינכרוניות (חוסמות את החוט)

איך לאבחן משימות ארוכות: מדריך שלב אחר שלב

  1. פתח את Chrome DevTools (F12) ועבור ללשונית Performance.
  2. לחץ על כפתור Record (סמל עיגול).
  3. בצע אינטראקציה עם הדף: גלול, לחץ על כפתור.
  4. עצור את ההקלטה וחפש פסים אדומים מעל ציר הזמן — אלה משימות ארוכות > 50 אלפיות השנייה.
  5. לחץ על משימה כדי לראות את מחסנית הקריאות: איזה סקריפט תפס את החוט הראשי.

עבור 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 אלפיות השנייה של משימות ארוכות.

אסטרטגיה:

  1. טען סקריפטים של צד שלישי עם let debounceTimer; searchInput.addEventListener('input', function() { clearTimeout(debounceTimer); debounceTimer = setTimeout(() => { doSearch(this.value); }, 300); }); או אחרי אירוע setTimeout
  2. השתמש ב-scheduler.postTask עבור סקריפטים לא קריטיים
  3. בדוק אם כל הווידג'טים המחוברים נחוצים — לעתים קרובות יש כאלה שאינם בשימוש
// Загрузить аналитику после 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 שלך.