ToCode

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

f1ed4259c fix
75e825f62 fix
c388772ec remove unnecessary env group

1cc57ce33 fix sizing of logo
d26a25c47 fix sizing

f510e4f5d update
89007aad9 update
0d9701a14 updates to workflow

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

41a1948 fix
0a197d4 fix
e7572cf remove unnecessary env group
daf174b initial commit

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

$ git reset HEAD~3
Unstaged changes after reset:
M       textfile.txt

$ git add .
$ git commit -m 'remove unnecessary env group'

הפרויקט כעת נמצא באותו מצב של קומיט 41a1948 אבל הלוג הוא:

622a0da remove unnecessary env group
daf174b initial commit

ומי שיסתכל בלוג יראה בתוך קומיט 622a0da את כל השינויים של כל שלושת הקומיטים המקוריים. נ.ב. יש מערכות שמכריחות אותך לעשות Push כדי להפעיל CI Pipeline. שינוי קומיטים אחרי דחיפה הוא תהליך הרבה פחות ידידותי ויכול לבלבל מפתחים אחרים שכבר משכו את הקומיטים הקודמים. במצבים כאלה אני אוהב ליצור ענף נפרד לצורך הפעלת ה CI ואז אחרי שסיימתי לבדוק אני ממזג את הענף ומוחק את הקומיטים המיותרים עם ריבייס.

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

שלושה טריקים ששיפרו לי משמעותית את ציון הביצועים ב Page Speed אחרי משחקי הביצועים אתמול חשבתי שיהיה מעניין לבדוק גם את הבלוג שלי פה בטוקוד ולראות מה Page Speed חושב עליו והאם אפשר לשפר. האמת שבאתי מאוד אופטימי לבדיקה כי בראש חשבתי שמדובר בסך הכל באתר סטטי כמעט בלי JavaScript ושרת שרוב הזמן מגיב מהר. לא נעים לשתף מה Page Speed חשב עליו, אבל בואו רק נגיד שזה לא תאם לציפיות. מסתבר שלאורך השנים הוספתי לאתר פיצ'רים קטנים בלי לחשוב על ההשפעה שלהם על זמני הטעינה, ובלי לחשוב עד הסוף אם אני מוסיף אותם בדרך הטובה ביותר. הטעויות הקטנות האלה מצטברות ומשפיעות. אלה שלושת הטריקים שיישמתי כדי לשפר משמעותית את ציון ה Page Speed שעכשיו עומד על 94 לדף של פוסט מהבלוג: טעינת נכסים סטטיים דרך Apache האתר רץ על Rails וההמלצה באתרי ריילס היא לא להעמיס על השרת עם נכסים סטטיים (כלומר קבצי תמונות, js, css וכן הלאה). מספיק שבגלל עומס על השרת ייקח לו 3 שניות להיזכר שהוא צריך לשלוח קובץ CSS והאתר נטען לאט אצל מישהו. שרתי Apache ו nginx או CDN-ים למיניהם הרבה יותר טובים בשליחת קבצים סטטיים לגולשים, לכן הטריק הראשון היה להוריד משרת האפליקציה את המשימה הזאת ולהעביר אותה לשרת ה Apache שעומד לפניו. השהיית טעינת JavaScript עד שנצטרך אותו קופסת ה Comments שנמצאת פה מתחת לכל פוסט מגיעה מ disqus וה JavaScript שלהם הוא פח. נגן הוידאו שמשתמשים בו כדי לראות את הסרטים בקורסים מגיע מ Spotlightr ויש גם כמה אלמנטים של UI שמגיעים מספריית flowbite. את כל אלה העברתי לטעינה מושהית כך שייטענו רק כשנצטרך אותם, כלומר אם גולש באמת קורא את הפוסט וגולל עד למטה את העמוד אז נטען את תיבת ה Comments, אחרת אין טעם לטעון את ה JS שלהם. אם יש בעמוד סרט אפשר לטעון את הנגן של ספוטלייטר, אבל בטח לא צריך לטעון אותו בכל דף. השינוי הזה מאוד שימח את Page Speed שמודד כמה זמן מעבד ה JavaScript של העמוד לקח. מחיקת JavaScript שלא צריך בהמשך להשהייה שמתי לב שיש גם ספריות JS שפעם השתמשתי בהן והיום כבר לא. הבולטת בהן היא Google Analytics ממנה נפרדתי לטובת Simple Analytics, אבל היו עוד כמה ספריות של UI שלא היה צריך. מחיקה של JavaScript תמיד משמחת את Page Speed וכך קיבלתי אצלם עוד כמה נקודות. נקודות להמשך אחרי השיפור בדפי הבלוג העבודה עדיין רחוקה מלהסתיים. יש עדיין קבצי JavaScript שאני חושב שאפשר לוותר עליהם, ה Page Speed חושב שעדיין יש לי יותר מדי CSS ואפשר לקצץ גם שם ועוד לא נגעתי בעמוד הבית או בדפי הקורסים. ועדיין יצאתי מהמשחק מחוזק ואופטימי לגבי שיפורים שעוד אפשר יהיה ליישם בהמשך. הנקודה המרכזית שהיתה לי מעניינת בניסוי הזה היא שמושגים כמו הנתיב הקריטי ונכסים שחוסמים Render כבר מוטמעים בתוך הפריימוורקס וכמעט לא הייתי צריך לגעת בסדר הטעינה של דברים. גם מהירות הרשת היא מאוד טובה ואפשר לשלוח קבצים גדולים יותר בלי לפגוע בביצועים. האתגר המרכזי שעדיין נשאר הוא לכתוב ולשלוח פחות JavaScript, כי זמן הריצה הופך להיות צוואר הבקבוק של אתרים.

צריך לאהוב צריך היא אחת המלכודות הכי מרושעות כשאנחנו באים ללמוד מיומנות חדשה: ברור שעשיתי את השיעורים, צריך בשביל להצליח. ברור שבאתי לשיעור, צריך להשקיע בשביל להצליח. ברור שלמדתי למבחן, צריך ללמוד בשביל להצליח. "צריך בשביל להצליח" זה משהו שאנחנו לומדים מגיל צעיר בבית ספר. אתה לא צריך לאהוב מתמטיקה אבל אם תפתור מספיק תרגילים משעממים תצליח לקבל 100 בחמש יחידות ולהתקדם. הבעיה עם "צריך בשביל להצליח" היא כפולה - קודם כל הכח של "צריך" נחלש עם השנים. ככל שיש יותר דברים שצריך לעשות (עבודה, ילדים, כלים) ככה כל אחד מהם מקבל פחות תשומת לב. אבל הסיפור היותר משמעותי הוא ש"צריך בשביל להצליח" מסתיר מאיתנו את הדרך השנייה, זו שמביאה לתוצאות טובות בהרבה, הדרך שנקראת "לאהוב בשביל להצליח". "אני אוהב לתכנת" הוא משפט שמאוד קשה להגיד כשאנחנו בתחילת הדרך. הוא פותח דלת לשיחות שאין לך מושג איך להמשיך כמו "באיזה שפות אתה אוהב לתכנת?" (שפות? אני מכיר רק אחת וגם בה רק כמה פקודות) או "איזה סוג מערכות אתה אוהב לכתוב?" (מערכות? לקח לי שבוע להדפיס Hello World עשר פעמים על המסך, מה קשור מערכות עכשיו). הוא גם פותח דלת לשאלות מוזרות לעצמך כמו "אם אני כל כך אוהב את זה למה כל פעם שאני פותח את ה IDE אני בורח ליוטיוב?", ו"בשביל מה אני צריך לאהוב משהו שלעולם לא אהיה טוב בו?". הנה כמה דרכים לחשוב על זה, גם כשאנחנו בתחילת הדרך: 1. אני אוהב לתכנת, אפילו שזה קשה ואני עדיין לא טוב בזה. 2. כשאני מתעייף מכתיבת קוד אני יכול להנות גם מערוצי יוטיוב של מתכנתים (אפילו אם לא מבין כל מה שקורה שם). 3. מעניין מה יקרה אם אכתוב את זה... 4. מעניין באיזה שפת תכנות השתמשו בשביל לבנות את הכלי הזה... נ.ב. המחשבה "אבל אני לא אוהב לתכנת" יכולה להטעות. "צריך לאהוב את זה" לא אומר שאנחנו עכשיו אוהבים את זה, אלא שאנחנו צריכים ללמוד לאהוב את מה שרוצים ללמוד כדי להצליח. אני פעם לא אהבתי קפה והיום לא יכול להעביר יום בלעדיו. אנשים משתנים. המטרה היא לזהות איך ליצור את השינוי הזה באופן יזום. נ.ב.ב. המחשבה "לא צריך לאהוב את זה בשביל להצליח" יכולה להטעות. בגילאים צעירים או כשיש אילוצים חיצוניים או אם אתם אנשים מאוד מיוחדים אולי תצליחו להסתדר לעשות משהו שאתם לא אוהבים מספיק טוב כדי להצליח, אבל אין ספק שהרבה יותר קל להצליח להתמיד במשהו שאוהבים. בעולם התחרותי שלנו ובמיוחד בפיתוח תוכנה, אהבה לתחום זה ייתרון שחבל לוותר עליו.

שלוש סיבות שגורמות לנו לבנות ארכיטקטורה לא נכונה חבר רצה לבנות מערכת בקלאוד כדי להתמודד טוב יותר עם עומסים. חצי שנה מאוחר יותר הוא גילה שבעיות העומסים שהיו לו לא נפתרו ובסך הכל עברו למקומות אחרים. איך זה קורה? והאם זה יכול לקרות לכל אחד? אני חושש שכן והנה שלוש סיבות למה בנייה של מערכת מאפס בדרך כלל לא פותרת לנו את הבעיות: מפתחים מחליפים סטאק בין פרויקטים אתגר ראשון בשכתוב מערכת כדי להתמודד עם בעיות הוא שבגירסה החדשה נשתמש בסטאק טכנולוגי חדש. במקרה של החבר זה היה מעבר לקלאוד. אנחנו בוחרים סטאק טכנולוגי חדש כי אנחנו בטוחים שהבעיות שיש לנו כל כך גדולות שאי אפשר לפתור אותן עם הסטאק הקיים, ואנחנו שומעים את כל הסיפורים מסביב על אנשים שבחרו את הסטאק החדש והמלהיב ולהם אין בעיות בכלל. הבעיה כמובן שלכל סטאק יש בעיות, וכשאנחנו חדשים לגמרי עם טכנולוגיה מסוימת אנחנו נעשה טעויות ונגלה אותן רק הרבה יותר מדי מאוחר. התחלה מחדש אומרת שאני מפסיד את כל הידע הארגוני והטכני שצברתי ומתחיל מאפס. מימוש פונקציונאליות ישנה יכול להיות מאתגר חבר אחר התחיל לבנות מערכת Front End בריאקט שתחליף מערכת jQuery ישנה. אחרי שדברים התחילו לעבוד הוא גילה שיש בעיה של SEO כי כל העמוד נבנה מתוך JavaScript ורצה להוסיף Server Side Rendering. התוספת של רינדור צד שרת הוסיפה בעיות ביצועים שהוא לא ראה בתחילת הפיתוח וב POC-ים הראשונים. יותר מזה, בגלל שהיא התגלתה בשלב מאוחר כבר היה קשה לשנות חלקים יותר בסיסיים במערכת והביצועים נפגעו כי אי אפשר היה לבנות את התוספת בצורה הטובה ביותר. ברור שאם היינו כותבים מראש רשימה של כל הדרישות של המערכת הישנה לפני השידרוג מצבנו היה טוב, אבל בגלל שהשיכתוב הוא לסטאק חדש עד שאנחנו בכלל מזהים שמשהו הוא דרישה זה כבר מאוחר מדי. בונים לבד רק בשביל לפתור בעיה האתגר האחרון קשור ל Mindset של מפתחים ולהמרה בין פריימוורקים. אם אני מגיע עם הבנה של סטאק טכנולוגי מסוים ואני מנסה לממש מנגנונים דומים בסטאק טכנולוגי אחר לפעמים הכל יעבוד אבל יהיו מנגנונים שלא מתאימים לסטאק החדש, כי שיטת העבודה איתו שונה באופן מהותי בהיבט של אותו מנגנון. במצב כזה אנחנו רואים מפתחים שבונים לבד מנגנונים שעוקפים את שיטת העבודה המקובלת בסטאק החדש בו הם בחרו רק בשביל להצליח לבנות את הדבר שהם מכירים או רגילים אליו. התוצאה היא רכיבים במערכת שלא עובדים מספיק טוב או מספיק טוב יחד ובאגים שקשה לזהות בזמן אמת ויצוצו רק כשהמערכת תגיע לפרודקשן. אין ספק שלפעמים צריך להחליף רכיבי תשתית במערכת אבל החלום להחליף הכל במכה אחת ולבנות מערכת חדשה לגמרי בסטאק טוב יותר כמעט אף פעם לא נגמר טוב. עדיף להפריד את שתי המשימות - לפתור את בעיות הביצועים בתוך העולם הנוכחי, ובמקביל לשדרג ולהחליף חלקים בסטאק לתחליפים טובים יותר, אבל בקצב שיאפשר לנו ללמוד לעומק את ההבדלים בין הרכיבים הקיימים לחדשים ולהשתמש בצורה נכונה ברכיבים החדשים שבחרנו.

טיפ פייתון: הרצה משורת הפקודה עם uv אחד הקשיים בהרצת סקריפטים בפייתון משורת הפקודה הוא הספריות (התלויות) של הסקריפט. בעיה אחת זה שלא תמיד יש לסקריפט קובץ requirements.txt מסודר, אבל אפילו אם יש כשמתחילים להתקין תלויות אנחנו מלכלכים את ספריית ההתקנה הראשית של פייתון. כן יש אנשים מסודרים שיוצרים לעצמם סביבה וירטואלית לכל הסקריפטים או סביבה וירטואלית שונה לכל סקריפט, אבל אם גם אתם קצת עצלנים מדי בשביל זה תשמחו לשמוע ש uv ישמח לעשות את העבודה בשבילכם. הכלי uv הוא סוג של מנהל גירסאות ומריץ פייתון, הוא יכול להחליף את pyenv וחבריו אבל בשימוש שנראה היום הוא פשוט חוסך לי התקנה של תלויות לתוך תיקיית הפייתון הכללית. נניח שיש לי קוד שנראה כך:

import pandas

mydataset = {
          'cars': ["BMW", "Volvo", "Ford"],
            'passings': [3, 7, 2]
            }

myvar = pandas.DataFrame(mydataset)

print(myvar)

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

* !/usr/bin/env -S uv run --script *
* /// script *
* requires-python = ">=3.12" *
* dependencies = [ *
* "pandas", *
* ] *
* /// *

import pandas

mydataset = {
          'cars': ["BMW", "Volvo", "Ford"],
            'passings': [3, 7, 2]
            }

myvar = pandas.DataFrame(mydataset)

print(myvar)

ועכשיו אפשר להפעיל את הקסם:

ynonp@Ynons-MacBook-Air ~/tmp $ uv run pandas-demo-uv.py

Reading inline script metadata from \pandas-demo-uv.py\
Installed 6 packages in 38ms
    cars  passings
0    BMW         3
1  Volvo         7
2   Ford         2

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

$ brew install uv

אבל אפשר גם להתקין אותו עם pip:

pip install uv

ויש לו גם דף תיעוד מרשים בכתובת: https://docs.astral.sh/uv/

העתקת טקסט ותמונות ל Clipboard מתוך JavaScript הממשק navigator.clipboard מאפשר לנו להעתיק דברים ל Clipboard באפליקציית ווב מתוך קוד JavaScript והאמת שהעבודה איתו הפתיעה אותי לטובה. הנה שתי דוגמאות וכמה טיפים על דברים שיכולים להסתבך. העתקת טקסט מהקוד ל Clipboard אם אתם צריכים לבנות כפתור "העתק ל Clipboard" או סתם לדחוף לאנשים ל Clipboard דברים בלי שהם יבקשו תשמחו לשמוע שכל הסיפור הוא בסך הכל קריאת פונקציה אחת: navigator.clipboard.writeText. לדוגמה אם יש לי אלמנט input בעמוד הקוד הבא יגרום לכל שינוי של הטקסט ב input להיות מועתק אוטומטית ל Clipboard של המשתמש כדי שיהיה קל להדביק את זה במקומות אחרים:

input.addEventListener('input', async (ev) => {
  navigator.clipboard.writeText(ev.target.value);
});

העתקת תמונה מהקוד ל Clipboard העסק קצת מסתבך כשעוברים לדבר על העתקת דברים מסוגים שונים. ה Clipboard תומך במגוון של פריטים ובכתיבה אליו אנחנו יכולים להעביר את "סוג המידע" בצירוף הביטים של המידע והכל יעבוד. האתגר מתוך JavaScript הוא שלא תמיד קל לנו להגיע למידע. ניקח לדוגמה העתקה של תמונה מאלמנט img ל Clipboard של המשתמש. בשביל להגיע לביטים של התמונה אנחנו צריכים שהתמונה תיטען מהדומיין שלנו או מדומיין שמאפשר גישה לביטים באמצעות כותרות CORS. אפילו אם נעשה את זה צריך לשים לב שלא כל מערכות ההפעלה תומכות בכל סוגי התמונות ולדוגמה אצלי במק לא הצלחתי להעתיק JPEG ל Clipboard אלא רק png. אם אנחנו מוכנים לחיות עם המגבלות הקוד כדי להעתיק תמונה ל Clipboard הוא (באדיבות ChatGPT):

async function copyImageFromImgElement() {
  const img = document.getElementById('image-to-copy');

  // Ensure that the image is fully loaded and the src attribute is set
  if (!img.complete || !img.src) {
    console.error('Image not fully loaded or missing src attribute.');
    return;
  }

  try {
    // Fetch the image as a blob
    const response = await fetch(img.src);
    const blob = await response.blob();

    // Create a ClipboardItem using the image blob
    const clipboardItem = new ClipboardItem({ [blob.type]: blob });

    // Write the ClipboardItem to the system clipboard
    await navigator.clipboard.write([clipboardItem]);
    
    console.log('Image copied to clipboard successfully!');
  } catch (err) {
    console.error('Failed to copy image:', err);
  }
}

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

async function copyImageFromCanvas() {
  const img = document.getElementById('image-to-copy');

  // Ensure the image is loaded
  if (!img.complete || !img.naturalWidth) {
    console.error('Image not fully loaded or invalid.');
    return;
  }

  // Create a canvas element
  const canvas = document.createElement('canvas');
  canvas.width = img.naturalWidth;
  canvas.height = img.naturalHeight;
  const ctx = canvas.getContext('2d');
  
  // Draw the image onto the canvas
  ctx.drawImage(img, 0, 0);

  // Convert the canvas content to a Blob
  canvas.toBlob(async (blob) => {
    if (!blob) {
      console.error('Failed to create blob from canvas.');
      return;
    }

    try {
      // Create a ClipboardItem
      const clipboardItem = new ClipboardItem({ [blob.type]: blob });

      // Write it to the clipboard
      await navigator.clipboard.write([clipboardItem]);
      console.log('Image copied to clipboard successfully from canvas!');
    } catch (err) {
      console.error('Failed to copy image from canvas:', err);
    }
  }, 'image/png'); // second parameter is optional; 'image/png' is default
}

שיפור זמני טעינת עמוד ב 2025 העולם משתנה כל הזמן וגם אצלנו בווב יש חידושים ובמיוחד בכל מה שקשור לארכיטקטורה של מערכות וההשפעה של אותה ארכיטקטורה על זמני טעינת העמוד. ממש בכניסה ל 2025 אני רוצה לחדד כמה רעיונות ישנים שעדיין עובדים ולזרוק את אלה שכבר לא רלוונטיים. אלה 10 טיפים שהייתי מאמץ גם לשנה הבאה בשביל לבנות אתרים שנטענים מהר: 1. פחות זה יותר - קובץ HTML קטן שנטען מ CDN יעלה הכי מהר אצל הלקוחות. חישבו טוב כל פעם שמכניסים פיצ'ר למערכת איך הוא משפיע על זמני טעינת העמוד והאם ניתן לבנות מנגנון דומה עם פחות קוד. 2. הקפידו לבקש את ה Cache - ההורדה הכי מהירה היא הורדה שלא קורית כי הקובץ כבר אצל הלקוח. שימו לב שאתם מגדירים Cache לכמה שיותר קבצים בעמוד. הקפידו לארגן את ה Assets של הדף שלכם כך שאפשר יהיה לשמור כמה שיותר ממנו ב Cache, כלומר השתמשו בשמות קבצים עם מזהים שאפשר לשמור ב Cache וחלקו את הקבצים כך ששינוי בקובץ אחד ישפיע רק על מעט קוד. 3. הגודל כן קובע - פעם המלצנו לאנשים לחבר יחד כמה שיותר קבצי JS או CSS לקובץ אחד כי היתה מגבלה על כמה קבצים דפדפן יכול להוריד במקביל וכל הורדה של קובץ נוסף דרשה Round Trip לשרת למשוך את הקובץ. כל זה לא רלוונטי יותר בזכות התפתחות בפרוטוקולי התקשורת. מצד שני דפדפנים לא התפתחו באותה מהירות כמו הרשת ולכן קובץ JS גדול יכול להשפיע לרעה בצורה מאוד משמעותית על זמן טעינת העמוד. בטאב Performance בדפדפן אפשר לראות את כל הקבצים שהעמוד טוען ובאיזו מידה כל קובץ משפיע על העבודה ב Main Thread. שימו לב למספרים האלה ושברו קבצי JS גדולים. 4. אבל לא תמיד - שימו לב שגם קבצים קטנים יכולים להשפיע על זמן העבודה של ה Main Thread, לפעמים אפילו יותר מקבצים גדולים. כן יש JavaScript שלדפדפן יותר קשה להריץ. אם ראיתם כאלה קבצים שברו גם אותם, ואם אלה קבצים של ספריית צד שלישי אל תתביישו לחפש ספרייה אחרת. 5. זמן התגובה של השרת היה ונשאר פקטור בסיסי בשיפור ביצועים. ה HTML צריך להישלח חזרה תוך פחות מחצי שניה, עדיף לכיוון ה 200 מילי. 6. לא צריך לעשות היום מה שאפשר לדחות למחר - נשלח לגולש רק את הקוד שהוא צריך, ורק את הגדרות העיצוב שהוא צריך. אם מישהו ניסה להגיע לדף "אודות" באתר הוא לא צריך לחכות שדף הבית ייטען. קודם תנו לבן אדם את מה שהוא רצה, אחרי זה תשתמשו ב preload כדי לטעון דפים אחרים ברקע אם לדעתכם יש בזה צורך. 7. ספריות צד שלישי יכולות להכביד. עדיף לבנות לבד אתר נגיש מאשר להטמיע תוסף נגישות. אם אתם לא מסתכלים ב Analytics לא צריך להוסיף את הסקריפט שלהם לעמוד. 8. תמונות ריספונסיביות זה עדיין רעיון טוב. אין טעם לשלוח תמונה גדולה ולהקטין אותה ב CSS. 9. טענו מראש (preload) את קבצי הפונטים, תמונות רקע וכל משאב אחר שה CSS שלכם עוד מעט יבקש כבר ב HTML. 10. הקשיבו למשתמשים - רוב שירותי האנליטיקס מאפשרים לשמור כמה זמן לקח למשתמשים אמיתיים לטעון את העמוד שלכם. זה המדד הכי טוב כדי להבין אם יש או אין בעיות ביצועים. היו ערניים לשינויים במדד זה והקפידו לצעוק כששינויי קוד מסוימים גורמים למשתמשים לחוות האטה בזמני הטעינה.

טיפ פייתון: איך לשלוח סקריפט בלי להראות את הקוד חבר שואל - איך אני שולח סקריפט פייתון למשתמשים בלי שיוכלו לראות את הקוד? מסתבר שיש פיתרון פשוט ומובנה בפייתון: קומפילציה. במקום לתת את הסקריפט תוכלו לבקש מפייתון לקמפל אותו ותקבלו קובץ pyc. נותנים ללקוח את קובץ ה pyc ורובם לא ידעו איך לקרוא אותו. בשביל לקמפל סקריפט בשם demo.py אני מפעיל:

python -m compileall demo.py

זה יוצר תיקייה בשם __pycache__ ובתוכה קובץ בשם demo.cpython-313.pyc. בשביל להריץ צריך להפעיל:

python __pycache__/demo.cpython-313.pyc

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

3. הספריה vueuse שכוללת המון קוד Vue גנרי מסודר כפונקציות קטנות שאפשר להפעיל מתוך קומפוננטות שלכם (או להסתכל בקוד כי רוב הפונקציות שם ממש פשוטות). 4. הספריה Tanstack Query שעוזרת למשוך מידע משרתים ולנהל אותו בתוך יישום Vue.