חבר כתב בפייסבוק

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

לפי הסיפור הקרסר תיקן טעינה של פונטים, דחס תמונות, תיקן סדר טעינה ואחרי 15 דקות האתר הגיע לציון 100.

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

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

2. רק בגלל שמישהו מפרסם שקרסר הצליח להביא את האתר שלו לציון 100 ב Lighthouse לא אומר שהאתר שלו נטען יותר מהר או שאתם יכולים להגיע לתוצאה דומה על האתר שלכם. בביצועים יש כלל שהרבה יותר קל להגיע לשיפור של 90% מאשר לשיפור של 3% כי אם הורדת את זמן הטעינה ב 90% הקוד המקורי היה די גרוע. בדיקת ביצועים אמיתית דורשת שמירת זמני טעינה של גולשים אמיתיים וניתוח לאורך זמן.

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

4. קרסר לא שינה בצורה משמעותית את קוד האפליקציה. הוא לא תיקן שאילתות לא יעילות, לא החליף ספריות JavaScript בספריות קטנות יותר, לא יצר Cache-ים חדשים, לא יצר מחדש תמונות ברזולוציות שונות ולא הכניס לתוך המערכת מנגנונים של Responsive Images.

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