- Bundle size הוא המדד מספר 1 לחוויה — שאף ל-JS ראשוני מתחת ל-180KB gzipped.
- Lighthouse 90+ בכל הקטגוריות הוא יעד ריאלי לכל אפליקציה ב-2026.
- תלויות יקרות נסתרות: moment, lodash מלא, recharts. החלף ב-date-fns, lodash-es, או Recharts tree-shake-able.
- Sentry + Vercel Analytics + uptime monitor — לפני שמשיקים, לא אחרי.
- Headers בסיסיים שחייבים: CSP, HSTS, X-Frame-Options, Referrer-Policy.
שלב 1: Bundle Analysis
פתח את ה-bundle עם vite-bundle-visualizer או next/analyze. סמן את שלוש החבילות הכי גדולות. רוב הסיכויים שאחת מהן מיותרת או יכולה להיטען lazy. יעד: initial JS גזיפ מתחת ל-180KB ב-route ראשי. 250KB עוד סביר. 400KB+ זה דגל אדום.
| חבילה כבדה | חלופה רזה | חיסכון טיפוסי |
|---|---|---|
| moment (290KB) | date-fns / Day.js (12KB) | ~270KB |
| lodash (full, 70KB) | lodash-es + tree-shake | 50–60KB |
| recharts (170KB) | lazy import או visx | 0 ב-initial |
| framer-motion ב-root | Lazy בקומפוננטה ספציפית | 60KB |
| react-icons (כל הסט) | lucide-react עם tree-shake | 100KB+ |
| @mui/material מלא | Radix + Tailwind | 200KB+ |
הרץ npx vite-bundle-visualizer או npx -y bundle-buddy build/. ב-Next.js: ANALYZE=true next build. ב-5 דקות מקבלים מפת חום של כל החבילות.
שלב 2: Lighthouse + Core Web Vitals
הרץ Lighthouse ב-incognito על production deployment (לא dev). שאף ליעדים הבאים על מובייל:
| מדד | טוב | טעון שיפור | גרוע |
|---|---|---|---|
| LCP | < 2.5s | 2.5–4s | > 4s |
| INP | < 200ms | 200–500ms | > 500ms |
| CLS | < 0.1 | 0.1–0.25 | > 0.25 |
| TTFB | < 600ms | 600–1500ms | > 1.5s |
| Performance Score | ≥ 90 | 70–89 | < 70 |
שלב 3: תלויות חשודות
- npm-check-updates — לראות מה מיושן, אבל לא לעדכן הכל בו-זמנית לפני השקה.
- npm audit — לתקן רק high/critical. low/moderate אפשר לדחות.
- npx depcheck — מזהה חבילות לא בשימוש שעדיין יושבות ב-package.json.
- knip — מזהה exports, files ו-deps לא בשימוש (מהיר ומדויק יותר מ-depcheck).
- npx bundlephobia <package> — לפני הוספת חבילה חדשה.
שלב 4: ביצועים בצד שרת
- Time To First Byte: בדוק ב-WebPageTest מ-3 אזורים. מעל 800ms מסביר את עצמו לרוב כ-DB query איטי.
- Slow queries: ב-Supabase / Neon יש Query Performance. תפוס את ה-10 הכי איטיים, הוסף indexes.
- N+1 queries: ProfileLayout שטוען user, ואז מתי שעולה comments טוען user שוב. הימנע עם eager loading.
- Image optimization: כל תמונה דרך next/image או Cloudflare Images. אסור JPG/PNG מקורי בפרודקשן.
- Caching headers: עמודים סטטיים עם s-maxage=3600, stale-while-revalidate=86400.
שלב 5: ניטור (חייב להיות לפני ההשקה)
| סוג ניטור | כלי מומלץ | עלות |
|---|---|---|
| Error tracking | Sentry | חינם עד 5k אירועים |
| Uptime + status | BetterStack / UptimeRobot | חינם עד 10 monitors |
| Performance / RUM | Vercel Speed Insights / Sentry Performance | כלול |
| Product analytics | PostHog / Plausible | חינם בהיקפים קטנים |
| Log aggregation | Axiom / Logtail | 0.5GB חינם |
Sentry בלי source maps מציג שמות משתנים minified. הוסף sentryVitePlugin או הפעל את ה-source map upload — אחרת אתה מצוד באפלה.
שלב 6: אבטחה בסיסית
- HTTPS בלבד + HSTS עם max-age גדול.
- Content-Security-Policy לפחות עם default-src 'self' ולא 'unsafe-inline' בייצור.
- X-Frame-Options: DENY (מונע clickjacking).
- Rate limiting על endpoints רגישים (login, signup, password reset).
- Secrets ב-env vars בלבד — לא ב-git, לא ב-frontend. בדוק עם trufflehog לפני push.
- RLS פעיל על כל טבלה ב-Supabase. בדוק עם anon key מ-curl.
- Auth tokens ב-httpOnly cookies או secure storage — לא ב-localStorage.
שלב 7: SEO ו-meta
- title ייחודי לכל עמוד (< 60 תווים).
- meta description ייחודי לכל עמוד (< 160 תווים).
- og:image לכל עמוד שיכול להישתף.
- sitemap.xml ו-robots.txt — הגש ב-Search Console ביום ההשקה.
- JSON-LD מתאים: Organization בעמוד הבית, Article בבלוג, Product בחנות.
- Canonical tag על כל עמוד.
- תמונות עם alt משמעותי (לא 'image1.jpg').
שלב 8: צ׳ק-ליסט השקה
- ✅ Backup אוטומטי של DB מופעל ונבדק (לפחות restore אחד).
- ✅ הגדרת Hard Spend Cap בכל ספק (Vercel, OpenAI, Supabase).
- ✅ status page פעיל ומקושר לפוטר.
- ✅ contact form נשלח לפחות לשני מיילים שונים.
- ✅ 404 ו-500 מותאמים אישית — לא דף ברירת מחדל.
- ✅ נבדק בכל הדפדפנים הגדולים + iOS Safari.
- ✅ הצהרת נגישות, מדיניות פרטיות ותנאי שימוש קיימים.
- ✅ GA/PostHog מאמתים אירועים מ-production.
שאלות נפוצות
ל-route ראשון: 200KB gzipped JS זה הסף. 300KB עדיין עובד טוב על fiber, אבל מעל זה מובייל סלולרי באזורים חלשים סובל.
אם מצפים ליותר מ-500 משתמשים בו-זמנית — כן, עם k6 או Artillery. אחרת מספיק בדיקה ידנית של flows קריטיים.
התחל מה-LCP image (בדרך כלל זה הסיפור). אחר כך JS לא נחוץ ב-initial bundle. שיפור של 20 נקודות אפשרי בשעה–שעתיים.
כן, אם משתמשים ב-inline scripts או third-party widgets בלי nonce. התחל ב-Report-Only mode כדי לראות מה נחסם בלי לשבור משתמשים.
מעלים אתר לאוויר? תוודאו שהוא מוכן!
קבלו סריקת אבטחה ו-SEO מקצועית במחיר משתלם שתוכלו לישון בראש שקט
צרו קשר עכשיו ↗