התשובה הקצרה
ביצועים גרועים ב-Salesforce הם תסמין מצטבר: Record Page עם 14 רכיבים, שלוש אוטומציות שרצות על אותו Save, שאילתה שסורקת מיליון רשומות ואינטגרציה שמושכת נתונים בשעת שיא. הדרך היחידה לשפר בלי לבזבז תקציב היא למדוד לפי שכבות, לזהות את השכבה הדומיננטית, ולטפל בה — ואז למדוד שוב.
חמש השכבות ומה מודדים בכל אחת
| שכבה | תסמין אופייני | כלי מדידה | טיפול נפוץ |
|---|---|---|---|
| דפדפן ורשת | איטיות רק אצל חלק מהמשתמשים | Lightning Usage App לפי משתמש | Latency ארגוני, גרסת דפדפן, VPN |
| מסך ורכיבים | EPT גבוה בעמוד רשומה מרכזי | EPT per Page, Debug Mode | צמצום רכיבים, טעינה מדורגת, Tabs |
| אוטומציה | Save איטי, Timeout בעדכון המוני | Debug Logs, Flow Interviews | איחוד Flows, מעבר לאסינכרוני |
| נתונים ושאילתות | דוחות שנופלים, List View תקוע | Query Plan, Apex Jobs | סינון סלקטיבי, Index, ארכוב |
| אינטגרציה | שיאי עומס בשעות קבועות | Event Monitoring, API Usage | Bulk API, חלונות ריצה, Throttling |
עבודה עם נפחי נתונים גדולים
מעל כמיליון רשומות ב-Object, כללי המשחק משתנים. Data Skew — למשל 200 אלף Accounts שמשויכים לאותו Owner או Parent — יוצר נעילות שורה ומאט כל עדכון המוני. הפתרון הוא פיזור בעלות, ולא הוספת חומרה, שממילא אינה בשליטתכם. במקביל כדאי לבחון ארכוב: רשומות סגורות מלפני חמש שנים שאיש אינו קורא מייקרות כל שאילתה שמבצעת סריקה.
מסכים: פחות זה מהר יותר
Record Page ממוצע בארגון ותיק צובר רכיבים בקצב של שניים-שלושה בשנה, כי כל בעל עניין מבקש "עוד ווידג'ט אחד". כל רכיב Lightning מבצע קריאות משלו. שתי פעולות מייצרות את מרבית הרווח: העברת רכיבים משניים ל-Tabs נפרדים שנטענים רק בלחיצה, והחלת Component Visibility לפי Record Type או תפקיד, כך שמשתמש רואה רק את מה שרלוונטי לו. שילוב השניים מוריד EPT בעשרות אחוזים בלי שינוי בקוד.
סדר הפעולות שעובד
מתחילים בשבוע מדידה בלי שינויים, כדי לקבוע Baseline אמין לחמישה מסכים מרכזיים ולשלושה תהליכים מרכזיים. אחר כך מטפלים במסכים — זה הזול והמהיר. בשלב השלישי מאחדים אוטומציות לפי Object, ורק בשלב הרביעי נוגעים בשאילתות ובמודל הנתונים. אינטגרציות מטופלות במקביל, אם המדידה הראתה שהן הגורם.
ההיגיון בסדר הזה כלכלי: השכבות הראשונות זולות והפיכות, האחרונות יקרות ומחייבות בדיקות רגרסיה. הרחבה בנושא מופיעה בSalesforce Health Check ובסימנים לשדרוג מערכת.
סיכונים נפוצים ופעולות מניעה
הסיכון הגדול הוא אופטימיזציה בלי Baseline: מבצעים עשרה שינויים, המשתמשים עדיין מתלוננים, ואין דרך לדעת מה עזר. מדידה לפני ואחרי לכל שינוי משמעותי היא תנאי, לא מותרות.
סיכון שני הוא טיפול בסימפטום הקולני. המסך שעליו מתלוננים הכי הרבה אינו בהכרח האיטי ביותר — לפעמים הוא פשוט זה שנפתח הכי הרבה פעמים ביום. סיכון שלישי הוא שינוי אוטומציות בלי כיסוי בדיקות: איחוד Flows הוא הפעולה עם הפוטנציאל הגבוה ביותר לשבירה שקטה של לוגיקה עסקית.
כיצד מודדים הצלחה
ארבעה מדדים מספיקים: EPT ממוצע בחמשת המסכים המרכזיים, זמן Save בתהליך העסקי הראשי, מספר כשלי Timeout ו-Governor Limit בחודש, ושיעור שאילתות שנמשכות מעל חמש שניות. מדד חמישי — משלים ולא טכני — הוא מספר תלונות ביצועים ב-Service Desk, שאמור לרדת עם השיפור בפועל.