ביקורת ביצועי אתר (Lighthouse/PageSpeed)
לעתים קרובות אנו רואים אתרים שמאבדים 30-50% מההמרות עקב טעינה איטית. Lighthouse — כלי הביקורת האוטומטי של Google — מציג מספרים אך אינו מסביר מה לעשות. הביקורת שלנו לא רק נותנת ציון; היא מאתרת את הגורמים המדויקים למדדים ירודים ומספקת תוכנית תיקון. המהנדסים שלנו השלימו למעלה מ-50 פרויקטים מוצלחים של האצת ביצועי אתרים. תרחיש טיפוסי: דסקטופ טס, אבל במובייל עם 3G הדף נטען ב-8 שניות, LCP עולה על 4 שניות, ו-CLS אדום כל הזמן. האשמים: תמונות לא מותאמות, צרורות JS כבדים, ואין פיצול קוד. ללא ביקורת מפורטת, תנחשו מה מאט אתכם.
צרו קשר לייעוץ מקדים — נעריך את מורכבות האתר שלכם תוך יום אחד.
כיצד להריץ Lighthouse נכון
בדיקות הסינתטיות של Lighthouse מדמות מכשיר Moto G4 על 4G עם האטת CPU פי 4. זהו מכשיר הנייד החציוני — המספרים בדסקטופ יהיו טובים יותר. לתוצאות יציבות:
- הריצו במצב אנונימי ללא תוספים (תוספים משפיעים על המדדים);
- בצעו 3-5 ריצות וקחו את החציון (Lighthouse יכול לנוע ±10-20 נקודות);
- השוו עם מתחרים באמצעות אותה מתודולוגיה.
# Lighthouse CLI — стабильнее DevTools: разброс на 15-20% меньше
npm install -g lighthouse
for i in 1 2 3; do
lighthouse https://mysite.ru \
--output json \
--output-path "run-$i.json" \
--chrome-flags="--headless" \
--throttling-method=simulate \
--preset=mobile
done אילו מדדים משפיעים על המהירות?
| מדד | משקל בציון | מה הוא מודד |
|---|---|---|
| LCP | 25% | טעינת האלמנט הגדול ביותר |
| TBT (זמן חסימה כולל) | 30% | זמן חסימת ה-thread הראשי |
| CLS | 25% | שינויי פריסה |
| FCP | 10% | ציור ראשון של תוכן |
| מדד מהירות | 10% | מהירות מילוי ויזואלי |
ל-TBT יש המשקל הגבוה ביותר והוא מתאם עם INP בתנאים אמיתיים. אתרים עם צרורות JS גדולים ללא פיצול קוד תמיד יהיו עם TBT גבוה. נתונים סינתטיים של Lighthouse טובים, אבל CrUX (דוח חוויית המשתמש של Chrome) מהעולם האמיתי הוא בעל ערך רב יותר — הוא מראה מה משתמשים חווים בפועל.
השוואה: Lighthouse לעומת CrUX
| מאפיין | Lighthouse | CrUX |
|---|---|---|
| סוג | סינתטי | משתמשים אמיתיים |
| תנאים | מבוקרים (Moto G4) | מכשירים/רשתות שונים |
| נתונים | בדיקה בודדת | מצטבר ל-28 יום |
| ישימות | כל אתר | דורש >1000 מבקרים ייחודיים |
שילוב שני המקורות נותן תמונה מלאה: Lighthouse מראה בעיות פוטנציאליות, CrUX מראה חוויה אמיתית.
למה TBT הוא המדד המסוכן ביותר
TBT מקושר ישירות למשימות ארוכות (>50ms) על ה-thread הראשי. אנו משתמשים ב-DevTools Performance ו-Treemap לניתוח צרורות. אשמים טיפוסיים: moment.js (67KB), lodash ללא tree-shaking, ייבוא מלא כמו # Lighthouse CLI — стабильнее DevTools: разброс на 15-20% меньше npm install -g lighthouse for i in 1 2 3; do lighthouse https://mysite.ru \ --output json \ --output-path "run-$i.json" \ --chrome-flags="--headless" \ --throttling-method=simulate \ --preset=mobile done . ניתוח צרורות עם import * as Icons from 'react-icons' חושף מה ניתן להסיר. אופטימיזציה יכולה לקצץ בעלויות אירוח עד 30% על ידי הפחתת עומס השרת.
# webpack-bundle-analyzer npm run build -- --profile npx webpack-bundle-analyzer dist/stats.json כיצד לשפר LCP
אלמנט LCP הוא לעתים קרובות התמונה הגדולה ביותר או טקסט. בעיות טיפוסיות:
<!-- Проблема: lazy-loading на LCP-элементе -->
<img src="hero.jpg" loading="lazy" ...>
<!-- Исправление: eager + fetchpriority -->
<img src="hero.webp" loading="eager" fetchpriority="high" width="1200" height="500" alt="LCP hero image">אם LCP הוא תמונת רקע CSS, Lighthouse לא יראה אותה כ-webpack-bundle-analyzer. פתרון: לעבור ל-# webpack-bundle-analyzer npm run build -- --profile npx webpack-bundle-analyzer dist/stats.json או להוסיף <!-- Проблема: lazy-loading на LCP-элементе --> <img src="hero.jpg" loading="lazy" ...> <!-- Исправление: eager + fetchpriority --> <img src="hero.webp" loading="eager" fetchpriority="high" width="1200" height="500" alt="LCP hero image"> . לפי Lighthouse ב-GitHub, הוספת img יכולה להפחית LCP ב-15-20%.
כיצד לטפל ב-CLS
גורמים לשינוי פריסה:
- תמונות ללא
<img>/<link rel="preload">; - באנרים/מודעות שהוכנסו דינמית;
- גופנים הגורמים ל-FOUT (הבזק טקסט ללא עיצוב);
- מסכי שלד עם מידות שגויות.
אבחון דרך DevTools → Rendering → Layout Shift Regions (מודגש בירוק). טעויות טיפוסיות הגורמות ל-CLS:
- חסר מידות תמונה (תמיד ציינו
fetchpriority="high"ו-widthאו השתמשו ב-height). - הכנסת מודעות ללא שטח שמור — הגדירו גובה מינימלי למיכל.
- תוכן דינמי שנטען לאחר רינדור — השתמשו ב-
widthאו בשלד.
אוטומציה עם PageSpeed Insights API
לניטור אוטומטי לאחר פריסה, השתמשו ב-API:
PSI_KEY="YOUR_GOOGLE_API_KEY"
URL="https://mysite.ru/"
curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=${URL}&key=${PSI_KEY}&strategy=mobile" | \
jq '{ lcp: .lighthouseResult.audits["largest-contentful-paint"].displayValue, tbt: .lighthouseResult.audits["total-blocking-time"].displayValue, cls: .lighthouseResult.audits["cumulative-layout-shift"].displayValue, score: .lighthouseResult.categories.performance.score }' מה כלול בעבודה
- דוח מפורט עם ציונים ב-4 קטגוריות Lighthouse (ביצועים, נגישות, שיטות מומלצות, SEO);
- רשימת משימות ממוינת לפי עדיפות עם השפעה/מאמץ (ניצחונות מהירים, רמה בינונית, רפקטורינגים גדולים);
- קבצי תצורה (Lighthouse CLI, webpack) לניטור עצמי;
- המלצות לאופטימיזציה של Core Web Vitals עם דוגמאות קוד;
- ייעוץ ותמיכה ב-Q&A למשך שבועיים לאחר המסירה.
לוחות זמנים משוערים
ביקורת מלאה (Lighthouse, ניתוח DevTools trace, ניתוח צרורות, נתוני CrUX, רשימת משימות ממוינת): 1-2 ימים. לאתרים גדולים עם סוגי דפים מרובים (דף בית, קטלוג, מוצר, תשלום) — 2-3 ימים. התמחור אישי. קבעו ייעוץ — צרו קשר. אנו מבטיחים שאחרי יישום ההמלצות האתר שלכם יקבל ציון 90+ ב-Lighthouse ו-LCP, TBT ו-CLS ייכנסו לאזור הירוק. הזמינו ביקורת כדי להפסיק לנחש — נראה לכם מה לתקן ואיך.







