למה האפליקציה שבניתם עם בינה מלאכותית מרגישה איטית (ומה לעשות בקשר לזה)

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

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

הפוסט הזה הוא דף הרמאות.

למה “איטי” הוא בדרך כלל ארבעה דברים

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

1. הצביעה הראשונה איטית — הם לוחצים על קישור ובוהים במסך ריק שתי שניות לפני שמשהו מופיע.
2. רשימה ארוכה מסורבלת — גלילה, סינון, או טעינה של “כל הפרויקטים שלי” לוקחת יותר זמן מגלילה באינסטגרם.
3. פעולה לוקחת יותר מדי זמן בלי לומר להם מה קורה — הם לוחצים “שמור” או “שלח” ושום דבר לא מגיב באופן גלוי.
4. שואלים את מסד הנתונים יותר מדי שאלות — עמודים שמציגים נתונים מכמה מקומות שולפים כל חתיכה בנפרד וערמים את זמני ההמתנה.

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

סיבת איטיות #1: הצביעה הראשונה

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

מה בדרך כלל גורם לזה: האפליקציה טוענת כל חתיכת JavaScript שהיא אולי תצטרך לפני שהיא מראה לכם משהו. כלים נוטים לאגד בנדיבות — עדיף לכלול משהו מאשר לפספס אותו — והחבילה הזו נעשית גדולה יותר ככל שאתם מוסיפים פיצ’רים.

מה לבקש מהכלי שלכם: “טעינת העמוד הראשון מרגישה איטית. אתה יכול לפצל את חבילות ה-JavaScript לפי route כדי שעמוד הבית לא יצטרך להוריד את כל אזור הניהול?” או, בפשטות: “תוסיף lazy loading ל-routes שאינם עמוד הבית.” רוב ה-frameworks המודרניים תומכים בזה בשורה או שתיים של הגדרה. הבינה המלאכותית יודעת איך — אתם רק צריכים לבקש.

תוך כדי: “האם יש תמונות גדולות בעמוד הנחיתה שנוכל לבצע להן אופטימיזציה?” תמונת hero של 4 מגה-בייט תהרוס את המהירות הנתפסת יותר מכל בעיית קוד.

סיבת איטיות #2: הרשימה הארוכה

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

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

מה לבקש מהכלי שלכם: “רשימת הפרויקטים איטית כשיש הרבה פריטים. אנחנו יכולים להוסיף עימוד (pagination), או לעשות וירטואליזציה לרשימה כך שרק השורות הגלויות מצוירות?” עימוד (“הראה 20 לעמוד, עם כפתורי הבא/קודם”) הוא התיקון הקל ביותר. וירטואליזציה (“צייר רק את מה שעל המסך כשהמשתמש גולל”) מרגישה חלקה יותר אבל היא קצת יותר עבודה. כל אחת בסדר.

אם לרשימה יש גם חיפוש או סינון: “האם סינון החיפוש יכול לקרות בשרת במקום בדפדפן?” סינון בצד השרת אומר שהדפדפן אי פעם מחזיק רק את השורות המתאימות, לא את כל מערך הנתונים.

סיבת איטיות #3: ההמתנה השקטה

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

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

זו בעצם לא בעיית ביצועים. זו בעיית ביצועים נתפסת, ואלה לעיתים קרובות כואבות יותר מהאמיתיות. פעולה של 200 אלפיות שנייה בלי משוב מרגישה איטית יותר מפעולה של 2 שניות עם spinner, כי המוח של המשתמש בחושך.

מה לבקש מהכלי שלכם: “תוסיף מצב טעינה לכל כפתור שמפעיל פעולה. תראה spinner או טקסט ‘שומר…’ בזמן שזה עובד, ותשבית את הכפתור כדי שמשתמשים לא יוכלו ללחוץ פעמיים.” זה תיקון הביצועים עם התשואה הכי גבוהה בכל אפליקציה והוא עולה כמעט כלום.

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

סיבת איטיות #4: מסד הנתונים הפטפטן

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

מה בדרך כלל גורם לזה: העמוד טוען את הפרויקטים בשאילתה אחת, ואז טוען את ספירת המשימות לכל פרויקט בשאילתה נפרדת. עשרה פרויקטים? אחת-עשרה שאילתות. מאה פרויקטים? מאה ואחת. זה נקרא “שאילתת N+1”, וזה הבאג הכי נפוץ של ביצועי מסד נתונים באפליקציות שנבנו עם בינה מלאכותית, כי הבינה המלאכותית מבצעת אופטימיזציה לקוד שנקרא בבירור, לא לקוד שרץ ביעילות.

מה לבקש מהכלי שלכם: “העמוד הזה עושה שאילתה אחת לכל פריט. אנחנו יכולים לשלוף את כל הנתונים הקשורים בשאילתה אחת — join או aggregate?” אתם לא צריכים לדעת מה אחת מהמילים האלה אומרת. הבינה המלאכותית יודעת. להראות לה את העמוד האיטי ולומר “אני חושב שיש לזה בעיית N+1” זה בדרך כלל מספיק.

אתם יכולים לזהות בעיות N+1 בלי שום כלי: פתחו את העמוד, ספרו כמה זמן זה לוקח, ואז הוסיפו פי עשרה פריטים לרשימה הבסיסית. אם העמוד עכשיו פי עשרה איטי יותר, יש לכם N+1. אם הוא רק קצת איטי יותר, אין לכם.

מילה על אופטימיזציה מוקדמת מדי

מלכודת שבונים חדשים נופלים אליה: לנסות לעשות כל עמוד מהיר לפני שמישהו משתמש באפליקציה. אל תעשו זאת.

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

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

איך לדבר עם הכלי שלכם על מהירות

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

הנחיות טובות להעתיק:

• “כשאני פותח את עמוד ההגדרות, יש עיכוב של שנייה לפני שמשהו מופיע. אנחנו יכולים להבין מה חוסם את הצביעה הראשונה?”
• “לוח הבקרה לוקח יותר זמן להיטען מעמוד הבית למרות שהוא מציג פחות נתונים. אנחנו יכולים להסתכל איך הוא שולף את הנתונים שלו?”
• “כשאני לוחץ ‘שמור שינויים’ בעמוד הפרופיל, שום דבר לא קורה במשך שתי שניות. תוסיף מצב טעינה ותוודא שאי אפשר ללחוץ על הכפתור פעמיים.”
• “תבדוק את הרשימה הזו עם 500 פריטים מזויפים ותגיד לי איפה ההאטות.”

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

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