ביצועי React בפרודקשן: מהאתר הכבד לציון 95 ב-Lighthouse

למה ביצועים הם פיצ'ר

גוגל מדרגת אתרים לפי Core Web Vitals. משתמשים נוטשים אחרי 3 שניות טעינה. ומנועי AI מעדיפים להמליץ על אתרים מהירים. ביצועים הם לא שלב ליטוש — הם דרישת מוצר.

כל פרויקט שיוצא מהסטודיו נמדד מול יעד: LCP מתחת ל-2.5 שניות, INP מתחת ל-200ms, CLS מתחת ל-0.1.

1. Code Splitting אגרסיבי

הבעיה הנפוצה ביותר באפליקציות React: bundle אחד ענק שנטען כולו בכניסה הראשונה.

• פיצול לפי ראוט —

  React.lazy

  לכל דף שאינו דף הבית
• פיצול לפי תנאי — פאנל אדמין? מודאל כבד? נטענים רק כשנפתחים
• ספריות כבדות בנפרד — עורכי טקסט, גרפים וספריות תלת-ממד אף פעם לא ב-bundle הראשי

2. ניהול רנדורים

רנדור מיותר הוא הרוצח השקט של INP:

1. הרמת state למטה — state שרלוונטי לקומפוננטה אחת לא יושב בהורה
2. memo בנקודות אסטרטגיות — לא על הכל, רק על תתי-עצים כבדים
3. useRef לערכים שלא משפיעים על UI — מונים, מדידות גלילה, מיקומי עכבר
4. אנימציות מחוץ ל-React — גלילה ועכבר דרך rAF ומוטציית DOM ישירה

3. אופטימיזציית מדיה

תמונות הן בדרך כלל 60%+ ממשקל הדף:

• WebP/AVIF לכל תמונה — חיסכון של 30-50% מול JPEG
• טעינה עצלה מובנית —

  loading="lazy"

  ו-

  decoding="async"

• מידות מוצהרות — width/height תמיד, למניעת CLS
• וידאו עם poster ו-preload="none" — הווידאו נטען רק בהתקרבות אליו

4. אסטרטגיית קאשינג

• Cache-first לנתונים סטטיים-יחסית — הצגה מיידית מהקאש ואז רענון שקט
• ETag בפונקציות שרת — הדפדפן לא מוריד מחדש מה שלא השתנה
• Preload חכם — טעינה מוקדמת של הדף הבא שהמשתמש כנראה ילחץ עליו

5. מדידה רציפה

ציון Lighthouse הוא תמונת מצב — לא תעודת ביטוח. אנחנו מודדים גם field data אמיתי.

• Lighthouse CI על כל דיפלוי
• בדיקות על מכשיר אמצע-שוק, לא רק על מחשב פיתוח
• ניטור Web Vitals אמיתיים ממשתמשים

סיכום

ביצועים טובים הם תוצאה של מאות החלטות קטנות: עוד תמונה שנדחסה, עוד קומפוננטה שפוצלה, עוד רנדור שנחסך. כשהמשמעת הזו מובנית בתהליך העבודה — ציון 95 הוא לא הישג חד-פעמי אלא ברירת המחדל.