אתר Laravel 11 עם Next.js 14 פעל בצורה חלקה עד שלאחר פריסת תכונה חדשה, LCP קפץ מ-1.8 ל-4.2 שניות ו-INP עלה על 300ms. האשם — סקריפט אנליטיקה כבד שנטען ללא defer. תרחיש זה מוכר לרבים: הרס ביצועים נובע לעיתים קרובות מרגרסיות עדינות. שירות אופטימיזציית מהירות האתר שלנו מתמקד בתיקון רגרסיית ביצועים ובשיפור Core Web Vitals. המהנדסים שלנו עם ניסיון של 10+ שנים אבחנו מאות מקרים כאלה והחזירו את המדדים לנורמה.
זיהוי נקודות הרס אופייניות
השלב הראשון הוא לאתר את מסגרת הזמן של הרס הביצועים. אנו משתמשים ב-Google Search Console (Core Web Vitals על פני 28 ימים), Grafana עם מדדי RUM, Lighthouse CI ב-CI/CD, ו-git log. הפקודה git log --oneline --since="2 weeks ago" --until="today" מציגה את כל הפריסות. אם LCP גדל, אנו מצלבים את התאריך עם הקומיטים. פעם אחת, ההרס עלה בקנה אחד עם עדכון ספריית swiper — החזרת הגרסה לאחור פתרה את הבעיה תוך 15 דקות.
גורמים נפוצים:
- רגרסיית JavaScript. הוספת סקריפט ללא
defer/asyncחוסמת את הרינדור. אבחון: Chrome DevTools → Performance → לכידת trace → מציאת משימות ארוכות מ-50ms על ה-thread הראשי. - גופן חדש ללא
curl -I -H "Accept: image/webp" https://site.ru/img.jpg | grep content-type. ללא זה, הדפדפן מסתיר טקסט עד שהגופן נטען, מה שמגדיל את LCP. גוגל ממליצה להשתמש תמיד ב-swap. - תמונות לא דחוסות לאחר שינוי CMS. אנו בודקים אספקת WebP באמצעות curl:
בדיקת תמיכת WebP עם curl
curl -I -H "Accept: image/webp" https://site.ru/img.jpg | grep content-type - CLS מאלמנטים ללא ממדים. תמונות ללא width/height גורמות לשינוי פריסה. אנו שומרים מקום באמצעות מאפיינים או aspect-ratio.
השוואת כלי אבחון
| כלי | מה הוא מודד | מתי להשתמש |
|---|---|---|
| WebPageTest | Trace מלא, LCP, CLS | כאשר חושדים ברגרסיית תמונות |
| Chrome DevTools Performance | Thread ראשי, משימות ארוכות | לניתוח INP ומשימות JS |
| Lighthouse CLI | מדדים לפני/אחרי | לבדיקות A/B של שינויים |
| Coverage | JS/CSS לא בשימוש | מציאת מועמדים לפיצול קוד |
WebPageTest טוב פי 2 לניתוח חזותי מאשר DevTools, בעוד ש-DevTools טוב פי 3 לניפוי עמוק של נתיב הרינדור הקריטי. אנו משלבים את שניהם כדי לזהות במדויק את הגורם להרס הביצועים.
אבחון מהיר ומלכודות נפוצות
קחו את דוח Lighthouse CI האחרון והשוו אותו לקודם. אם המדדים ירדו ביותר מ-10%, אנו מחפשים רגרסיה. השתמשו ב-git bisect כדי למצוא אוטומטית את הקומיט הבעייתי. זה מקצר את האבחון לכמה שעות גם בפרויקט גדול. השיטה שלנו מהירה פי 3 מבדיקה ידנית של git log.
גורם נפוץ להחמרת מדדים לאחר עדכונים הוא הוספת סקריפטים של צד שלישי ללא התחשבות בביצועים. לדוגמה, ווידג'ט צ'אט חדש עשוי לטעון 500+ KB של JS ולחסום את ה-thread הראשי. אנו מנתחים כל שינוי באמצעות תקציב ביצועים ב-CI. אם התקציב נחצה — הבנייה נכשלת, והרס הביצועים לעולם לא מגיע לייצור.
כיצד אנו מתקנים הרס: תהליך שלב-אחר-שלב
- אבחון. איסוף מדדים: LCP, INP, TTFB באמצעות WebPageTest ו-DevTools. ניתוח git log למציאת רגרסיה. רישום יומני שאילתות איטיים של מסד הנתונים.
- תיקון בעיות אופייניות. גופנים, תמונות, טעינת JS דחויה. חיסכון באספקת CDN — עד 30% מזמן הטעינה.
- מקרים מורכבים. שאילתות N+1, משימות ארוכות על ה-thread הראשי. פיצול למשימות-מיקרו באמצעות
scheduler.yield(). - בדיקות. הרצת Lighthouse CI במקביל לעומס ייצור.
- אחריות. מתן דוח עם השינויים ואחריות של שבועיים על שחזור המדדים. אם ההרס חוזר, אנו מבצעים אבחון חוזר בחינם.
מה כלול
- דוח אבחון עם גרפי מדדים
- זיהוי הגורם המדויק לרגרסיה
- אופטימיזציית קוד, גופנים ותמונות
- ביקורת חוזרת לאחר התיקונים
- אחריות של שבועיים על מדדים משוחזרים
- מחירים תחרותיים: אבחון מ-$500, אופטימיזציה מלאה מ-$1,000
אופטימיזציית Core Web Vitals
LCP הוא לעיתים קרובות תמונה גדולה או בלוק טקסט. לתמונות, השתמשו ב-fetchpriority="high" ו-preload:
Preload לתמונת LCP
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high"> אם LCP הוא טקסט, טעינת הגופן מאטה אותו. פתרון: preload לגופן עם <link rel="preload" as="image" href="/hero.webp" fetchpriority="high"> ו-crossorigin. יישמו resource hints כמו preconnect למקורות של צד שלישי כדי להפחית את זמן החיבור. השתמשו ב-font-display: swap לתמונות מתחת לקפל כדי לדחות טעינה.
INP > 200ms אומר שהמשתמש ממתין לתגובה. סיבה אופיינית: פעולה סינכרונית ב-handler. אנו מתקנים זאת על ידי פיצול למשימות-מיקרו באמצעות scheduler.yield() או setTimeout(0). למדו עוד על yield.
אם TTFB גדל — הבעיה היא בשרת. השוו localhost לייצור באמצעות curl. אם localhost הוא 150ms והייצור הוא 2s — הבעיה היא ברשת או ב-CDN. אם גם localhost גבוה — שאילתת מסד נתונים איטית או API חיצוני.
בפרויקט אחד, TTFB גדל מ-200ms ל-1.2s לאחר הוספת Redis caching. התברר שפסילת המטמון התרחשה בכל בקשה. הגדרת TTL נכון פתרה את הבעיה.
תוצאות והשקעה
| מדד | לפני | אחרי |
|---|---|---|
| LCP | 4.2 s | 1.5 s |
| INP | 320 ms | 180 ms |
| TTFB | 1.8 s | 0.9 s |
| CLS | 0.12 | 0.02 |
אבחון מ-$500, תיקון אופייני מ-$1,000, מקרים מורכבים עד $3,000. המהנדסים שלנו עם ניסיון של 10+ שנים ולמעלה מ-500 פרויקטים מוצלחים מבטיחים תוצאות. צרו קשר לייעוץ — ונחזיר את מהירות האתר שלכם.