איך לשפר ביצועים וזמן טעינה באתר שנבנה עם בייס44 (Base44): מדריך מלא

אתר איקומרס שנבנה עם בייס44 (Base44) נטען לאט בגלל שתי סיבות שקורות בו זמנית: הדפדפן מוריד יותר נתונים ותמונות ממה שהוא צריך להציג ברגע הראשון, והשרת מחזיר יותר רשומות ממה שהעמוד באמת מציג. התיקון עצמו לא מסובך, אבל הוא לא נקודתי. הוא מחייב לטפל בארבע שכבות בבת אחת: תמונות, טעינה עצלה, קריאות API, ומסד הנתונים.

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

למה אתר איקומרס שנבנה עם בייס44 נוטה להיות איטי

בייס44 מייצר אתר כאפליקציית React רגילה, עם ניתוב בצד הלקוח, כלומר כל דף מקבל כתובת משלו והדפדפן עצמו מחליט מה להציג, בלי טעינה מחודשת של השרת בכל מעבר, לפי סקירת מחסנית הטכנולוגיה של בייס44 (נבדק ב-2026-09-26). המשמעות המעשית: כל דף, כולל דף מוצר, שולף בעצמו את הנתונים שלו מהשרת ברגע שהוא נפתח, ואם הוא שולף יותר ממה שצריך, ההמתנה מורגשת בכל מעבר, לא רק בטעינה הראשונה.

מסד הנתונים עצמו הוא NoSQL תואם MongoDB, כלומר אפשר להשתמש באופרטורים של MongoDB דרך ה-SDK, לפי תיעוד ה-Entities הרשמי (נבדק ב-2026-09-26). זה נותן גמישות, אבל גם אומר שהסכימה לא נאכפת ואין מפתחות זרים בין טבלאות, כפי שמתואר בפירוט טכני על הבקאנד והמסד של בייס44 (נבדק ב-2026-09-26): קשרים בין רשומות נשמרים כהפניה ל-ID, והאפליקציה עצמה, לא מסד הנתונים, זו שאוכפת את הקשר.

בקיצור: הבעיה כמעט אף פעם לא "התמונות" בלבד. היא שילוב של תמונות כבדות, דף שמבקש יותר שדות ממה שהוא מציג, וקריאות API שחוזרות על עצמן.

שלב 1: לאבחן לפני שמתקנים

לפני שנוגעים בקוד או בהגדרות, כדאי לדעת בדיוק איפה הזמן הולך לאיבוד.

1. מריצים בדיקת Core Web Vitals על דף הבית ועל דף מוצר טיפוסי, עם כלי כמו PageSpeed Insights. שלושת המדדים שחשוב לבדוק: LCP, CLS ו-INP.
2. משווים לתקן שבייס44 עצמה קבעה. לפי התיעוד הרשמי לביצועים (נבדק ב-2026-09-26), היעד הוא LCP של 2.5 שניות או פחות, CLS עד 0.1, ו-INP עד 200 מילישניות.
3. בודקים אם הבעיה בטעינה הראשונה או במעבר בין דפים. אם דף הבית מהיר אבל דף מוצר איטי, החשד עובר לתמונות ולשאילתות של אותו דף ספציפי. אם כל מעבר בין דפים איטי באותה מידה, החשד עובר לקריאות API חוזרות ולמסד הנתונים.
4. סופרים כמה קריאות רשת יוצאות בכל טעינת דף, דרך כלי הפיתוח של הדפדפן (Network). מספר גבוה של קריאות קטנות הוא הסימן הכי ברור לבעיה ב-API, לא בתמונות.

שלב 2: תמונות וטעינה עצלה, השכבה שרואים ראשונה

דף מוצר הוא בדרך כלל הדף הכי עשיר בתמונות באתר, ולכן הוא הראשון שמרגיש כבד.

1. דוחסים ומשנים גודל לתמונות לפני ההעלאה, ולא אחריה. זו ההמלצה המפורשת בתיעוד הרשמי של בייס44 לביצועים.
2. מפעילים טעינה עצלה על כל מה שמתחת לקיפול הדף. אפשר לבקש את זה ישירות מה-AI של בייס44 בפרומפט כמו "Apply lazy loading to images and videos below the fold", והוא מוסיף את התגיות והמאפיינים הנדרשים בעצמו.
3. קובעים גובה ורוחב קבועים לכל מדיה, כדי שהדף לא יזוז כשהתמונה נטענת. זו הדרך למנוע CLS גבוה.
4. מעבירים סרטונים לאירוח חיצוני כמו Vimeo או YouTube במקום קובץ מקומי, ומוסיפים loading="lazy" לכל iframe.
5. בודקים שה-CDN עובד בשבילכם, לא רק בשבילכם. בייס44 מגישה קבצים דרך Cloudflare CDN באופן אוטומטי, אבל לפי אותו תיעוד אין כרגע אפשרות לנקות ידנית את המטמון של ה-CDN, ולכן שינוי בתמונה עלול להופיע רק אחרי כמה דקות.

פרומפט מקיף אחד שכדאי לשמור: "Optimize my app for faster LCP and INP". לפי התיעוד, ה-AI מפעיל בעצמו טעינה עצלה ודחיית סקריפטים במקומות הרלוונטיים.

שלב 3: לצמצם קריאות API, השכבה שרוב האנשים לא רואים

זו השכבה שאחראית למעברים איטיים בין דף לדף, כי בניגוד לתמונות היא בלתי נראית בעין.

בייס44 מתמחרת קריאות לאינטגרציות במסגרת מכסה חודשית לפי תוכנית, ולפי עמוד התמחור הרשמי (נבדק ב-2026-09-26): התוכנית החינמית כוללת 100 קריאות אינטגרציה בחודש, Starter ב-16 דולר לחודש כוללת 2,000, Builder ב-40 דולר לחודש כוללת 10,000, Pro ב-80 דולר לחודש כוללת 20,000, ו-Elite ב-160 דולר לחודש כוללת 50,000 (מחירים בחיוב שנתי). מכסה כזו נחצית מהר הרבה יותר כשכל רכיב ברשימת מוצרים שולח קריאה משלו, או כשרכיב מתעדכן על טיימר.

1. מאחדים כמה שאילתות לאחת. במקום חמש קריאות נפרדות שרצות בטעינת עמוד, בונים שאילתה אחת שמחזירה בבת אחת את כל מה שהעמוד צריך, לפי הדוגמה ממדריך לתיקון חריגה ממכסת הקריאות (נבדק ב-2026-09-26).
2. מבטלים רענון אוטומטי (polling). רכיב שמתעדכן כל חמש או עשר שניות מצטבר למהר לאלפי קריאות ביום. עדיף רענון לפי פעולת משתמש, כמו לחיצה על כפתור.
3. שומרים בזיכרון האפליקציה נתונים סטטיים, כמו רשימת קטגוריות שכמעט לא משתנה, ושולפים אותם פעם אחת בתחילת הביקור, במקום בכל ניווט בין דפים.
4. מוסיפים השהיה (debounce) לשדות חיפוש וסינון. לפי מדריך אופטימיזציה של LOW/CODE (נבדק ב-2026-09-26), השהיה של 200 עד 400 מילישניות לפני שליחת הבקשה מונעת קריאה על כל הקשה במקלדת.

שלב 4: מסד הנתונים, והאינדקס שאי אפשר להגדיר בעצמכם

זו השכבה שהכי הרבה שאלות עולות עליה, כי היא גם הכי פחות מתועדת.

לפי תיעוד ניהול הנתונים הרשמי (נבדק ב-2026-09-26), החל מ-27 בנובמבר 2025 קיימת מגבלה של 5,000 פריטים לכל בקשה, כדי לשמור על ביצועים יציבים, ובייס44 עצמה ממליצה לטעון נתונים בקבוצות של 50 עד 200 פריטים בכל פעם, ולא את כל הטבלה בבת אחת. לפי אותו תיעוד, טבלה עם יותר מ-5,000 רשומות עדיין שומרת את כל הנתונים, אבל הדשבורד מציג רק את המקסימום הזה.

וכאן הנקודה הכי חשובה, ולרוב לא מדוברת: לפי תיעוד סכימת ה-Entities (נבדק ב-2026-09-26), בייס44 לא תומכת באילוצי ייחודיות על שדות, ואין בממשק שום מסך שמאפשר להגדיר אינדקס ידני על טבלה. כלומר, בניגוד למסד נתונים כמו Postgres שבו מוסיפים אינדקס בשורת קוד אחת, בבייס44 אין כפתור כזה. המשמעות המעשית: השיפור לא בא מהגדרת אינדקס, אלא מהקטנת מה שהשאילתה בכלל צריכה לסרוק.

1. מסננים בצד השרת, לא בצד הלקוח. מבקשים מהמסד רק את הרשומות שמתאימות לתנאי, במקום למשוך את כל הטבלה ולסנן אותה בדפדפן.
2. שולפים רק את השדות שמוצגים בעמוד, ולא את הרשומה המלאה. חשוב במיוחד בטבלת מוצרים עם שדות תיאור ארוכים או קבצים מצורפים.
3. מוסיפים עימוד (pagination) לכל רשימה, כולל קטלוג המוצרים ותוצאות חיפוש. לפי מדריך LOW/CODE, עימוד לבדו יכול לקצר את זמן הטעינה ביותר מ-90 אחוז ברשימות שהיו טוענות אלפי רשומות כדי להציג עשרים.
4. מארכבים רשומות ישנות או לא פעילות, כדי שהשאילתות היומיומיות יסרקו פחות נתונים. לפי אותו מקור, ירידה מורגשת בביצועים מתחילה בדרך כלל בטווח של עשרת אלפים עד חמישים אלף רשומות בטבלה בודדת.
5. מעבירים חישוב כבד לפונקציית בקאנד. בייס44 מריצה קוד שרת מותאם אישית ב-Deno דרך Backend Functions (נבדק ב-2026-09-26), ופעולה שדורשת סינון מורכב או צירוף בין כמה טבלאות עדיפה שם, לא ברכיב שרץ בדפדפן.

טבלה מסכמת: סדר העדיפויות

טעויות נפוצות

• לתקן רק תמונות ולעצור שם. אם המעברים בין דפים עדיין איטיים, הבעיה בקריאות API או במסד הנתונים, לא בתמונות.
• לטעון טבלת מוצרים שלמה כדי להציג עשרים פריטים. זו הטעות הבודדת עם ההשפעה הגדולה ביותר.
• לחכות לאינדקס שלא קיים. בייס44 לא חושפת הגדרת אינדקס ידנית, כך שהזמן משתלם יותר בהקטנת השאילתה.
• רענון אוטומטי על טיימר קצר, שצורך מכסת אינטגרציות מהר בלי תועלת אמיתית למשתמש.
• לבדוק ביצועים רק על דף הבית. דף מוצר, עגלת קניות ותוצאות חיפוש הם הדפים שסובלים ראשונים כשהקטלוג גדל.

מתי הבעיה כבר לא נפתרת בתוך בייס44

אם אחרי כל השלבים האלה קטלוג המוצרים עדיין כבד, שווה לדעת את התקרה בכנות. מגבלת 5,000 הפריטים לבקשה, וחוסר היכולת להגדיר אינדקס ידני, הם מגבלות מבניות של הפלטפורמה, לא הגדרות שאפשר לשנות בממשק. במקרה כזה שווה לשקול חלוקת קטלוג ענק לכמה טבלאות לפי קטגוריה, או מעבר חלק מהלוגיקה הכבדה לפונקציית בקאנד ייעודית. סקירה רחבה יותר של מה בייס44 בנויה לעשות טוב, ומה לא, יש במדריך המלא לבייס44 (Base44). ולמי שבודק בכלל אם לבנות איקומרס מחוץ לבייס44, יש השוואה מפורטת במדריך לבניית חנות דיגיטלית עם קלוד קוד, כולל עגלה נטושה בלי עמלות פלטפורמה.

לפני שמפרסמים תיקון ביצועים, כדאי גם לוודא שהאתר תקין מבחינת פרטיות ונגישות, נושא שנוגע ישירות באתרים שנבנו עם AI, מפורט במדריך מדיניות פרטיות ונגישות באתרי Vibe Coding.

מי שרוצה לעבור על כל התהליך הזה שלב אחר שלב, כולל תרגול על אפליקציה אמיתית, מוזמן לקורס בייס44 (Base44) 2026: מאפיון לאפליקציה שעובדת ב-9.90 שקלים.

שורה תחתונה

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

מקורות

• Optimizing App Performance, תיעוד רשמי של בייס44 (נבדק ב-2026-09-26)
• Managing your app data, תיעוד רשמי של בייס44 (נבדק ב-2026-09-26)
• Entities Overview, תיעוד רשמי של בייס44 (נבדק ב-2026-09-26)
• Entity Schemas, תיעוד רשמי של בייס44 (נבדק ב-2026-09-26)
• Backend Functions, תיעוד רשמי של בייס44 (נבדק ב-2026-09-26)
• עמוד התמחור הרשמי של בייס44 (נבדק ב-2026-09-26)
• Base44 Tech Stack Overview, LOW/CODE (נבדק ב-2026-09-26)
• Optimize Base44 App Performance, LOW/CODE (נבדק ב-2026-09-26)
• Base44 Rate Limit Exceeded, AppStuck (נבדק ב-2026-09-26)
• Base44 Backend and Database, EscapeBase44 (נבדק ב-2026-09-26)