מדריך מקיף לנושא מהירות טעינה באתרי אינטרנט בכללותו

ביצועי תוכנה (באנגלית: Software performance) אני מגדיר כתחום פיתוח תוכנה במסגרתו הופכים תהליכי טעינה באפליקציה לאסתטיים ומהירים יותר; בסדרת מאמרים זו אתאר ביצועי תוכנה בעיקר בהקשר אפליקציית אינטרנט (ובזה גם אתר ווב).

רקע

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

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

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

עמוד אינטרנט

עמוד אינטרנט (באנגלית נפוץ הביטוי הכללי Node) אני מגדיר ככל מסמך היפרטקסט באפליקציית אינטרנט.

דוגמאות בולטות לעמוד אינטרנט הן למשל:

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

באופן כללי, דפדפני ווב מציגים כל עמוד אינטרנט כדף ווב מבוסס קוד HTML הכולל גם עם קוד JavaScript וקוד CSS אשר כל אחד מהם אחראי בעיקרו על מאפיין אחר ← מבנה, התנהגות ועיצוב בהתאמה.

זמן עד בייט ראשון

זמן עד בייט ראשון ובראשי תיבות TTFB (ראשי תיבות באנגלית של Time To First Byte) זה מדד מתחום ביצועי תוכנה המייצג בהקשר זה כמה זמן עבר עד שהבייט הראשון של עמוד אינטרנט נטען, בין אם מדובר בטעינה ישירות על מערכת ההפעלה או בין אם מדובר על טעינה בתווך כמו טעינת דף ווב בדפדפן ווב.

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

שני שלבים עיקריים לטעינת עמוד אינטרנט

טעינת עמוד אינטרנט מורכבת באופן כללי משני שלבים:

1. שלב בקשת שרת (המידע שהלקוח מבקש על ידי פעולה מסוימת)
2. שלב תגובת שרת הכולל שני תתי שלבים:

• שלב הפירסור (Parsing); בשלב זה נוצרים מבנים בסיסיים של עמוד אינטרנט; כלומר, ייטען קוד שפת מבנה (Markup) מאחורי הקלעים או ייבנה מתוך הרצה של קוד שפת התנהגות מאחורי הקלעים (המשתמש לא יראה מבנים נטולי עיצוב על המסך). הטעינה תכלול גם הופעתם של קוד התנהגות וקוד שפת עיצוב הקשורים בתג מבנה אחד או יותר לפניכן. כמו כן, יורדו משאבים כגון קבצי קוד עיצוב וקבצי קוד התנהגות, אם היו כאלה (אך בינתיים לא יהיו שימושיים).
• שלב הרינדור (Rendering); בשלב זה המבנים השונים מרונדרים, כלומר מתחילים להופיע בעמוד תוך שהם מקבלים עיצוב (Style) והתנהגות מקבצים חיצוניים שירדו בשלב הפרסור (מידע שלא נכלל בתגי מבנה ← בהינתן והיו קבצים כאלה). בתום שלב זה, המבנים יופיעו מעוצבים במלואם למשתמש. אם כי בעיה אפשרית בשלב זה היא שבפועל פורסר רק חלק מן ה Markup למרות שבשל הגעה לשלב הרינדור נחשוב שכל ה Markup זמין.

אורך זמן טעינה ראשוני בעמוד אינטרנט

ראשית יש להבחין בין זמן עד בייט ראשון לבין שני שלבים עיקריים לטעינת עמוד אינטרנט ← זמן עד סוף הפירסור וזמן עד סוף הרינדור (שלושה סיווגי טעינה שונים).

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

טיפול

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

מצב בו לוקח לדף להיטען טעינה ראשונית יותר משנייה בממוצע מעיד, באופן כללי, על בעיות של אי התאמת התוכן לסביבת השרתים הנוכחית ומסכן את בעלי האפליקציה בנטישת משתמשים ובמיקום נמוך במנועי חיפוש; אורכים כמו 5 שניות או הרבה יותר מכך - 15 שניות וכדומה, מעידים, מניסיוני, על אסון אפשרי.

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

• בנייה איטית של Markup בשל קוד יצירת-Markup לא יעיל (בהינתן וה-Markup נבנה מקוד חיצוני ולא מוצג ישירות ולא פותח ישירות)
• שליפת מידע איטית מבסיס נתונים
• היעדר מיניפיקציה (מחיקת תווים מיותרים מקבצים מוגשים)
• היעדר אגרגציה (איחוד קבצים לקובץ אחד)
• תוכנת שרת לא עדכנית (גרסה מאיורית ישנה)
• בעיית אבטחה שמכבידה על השרת (תקיפות תכופות המעמיסות על שרת ווב)
• היעדר שימוש בכלי רשת העברת תוכן (content delivery network)
• היעדר קאשינג בשכבה נתונה וכדומה
• אי ספיקת חומרה
• ועוד

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

איך לשפר טעינת אתר ווב

ישנן מספר דרכים לשפר טעינת אתר ווב כגון:

• שיפור חומרה
• שימוש בקוד מקור עדכני יותר שיכול לכלול קיצורי דרך (sugar syntax)
• שימוש במטמון (cache)
• שיפור התקשורת עם בסיס הנתונים (אם רלוונטי)
• מיניפקציה לקבצי קוד מקור
• אגרגציה לקבצי קוד מקור
• קומפרציה לתמונות
• וכדומה

מיניפיקציה

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

• הערות קוד
• אינדנטציות (כגון רווחים, טאבים וירידות שורה)
• קוד משוכפל (נדיר)

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

אגרגציה

בביצועי תוכנה, אגרגציה (באנגלית: Aggregation ; "צירוף") אני מגדיר כטכניקת שיפור ביצועים שמהותה צירוף או איחוד של שניים או יותר קבצי מידע לקובץ אחד (במקום לטעון המון קבצים קטנים בשבילים שונים נטען רק קובץ אחד שנוצר מכבר בשביל אחד).

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

קומפרציה

המונח קומפרציה (באנגלית: Compression) ; לחלופין גם "כיווץ מידע" או "דחיסת נתונים" הוא מונח מתחום המחשוב שאני אישית מוצא כמטעה ואקדיש מאמר זה בעיקר להסביר מדוע.

משמעות

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

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

דוגמה

כיווץ נתונים במחשוב או דחיסת נתונים במחשוב ניתן לתאר במונח יעיל יותר "אחסון נתונים חסכוני יותר" וזה יכול להיות מושג בשתי דרכים שיכולות לחפוף.

• הקטנה יחסית (smallscaling): לשנות פיסת מידע לקטנה יותר באופן שלא ישנה את המסר שלה (לא ישפיע על מטרתה המקורית); למשל, אם יש לנו מודל מכונית ברוחב 4.5 מטר ונשנה את רוחבה ל 4.0 מטר (ניצור מודל שזהה בכל מלבד מאפיין זה) באופן כללי נוכל להגדיר שזו אותה מכונית רק בדגם חדש ויעיל יותר שיש סיכוי גדול יותר להחנות בחנויות קטנות (אותו דבר עם גדלים במוצרי תוכנה). בתוכנה דומה הדבר להקטנת גודל טקסט
• הסרת יתירות (redundancy removal): לשנות פיסת מידע לבעלת פחות יתירות; כלומר, להסיר ממנה כל מה שהוגדר כמיותר; כך למשל בחלק משפות התקשורת הכלליות יש את ביטוי ה' הידיעה (The וכדומה) ובחלק אין; ניתן להגדיר אותו כמיותר וליצור גרסה של שפה שלא כוללת אותו ובכך כביכול פחותה ביתירותה ולכן מאפשרת בטווח הארוך לשמור נתונים בצורה "יעילה" יותר; זו כמובן דוגמה פילוסופית פשטנית שבאה להעביר עיקרון ובפרטיקה מבני מידע הרבה יותר מורכבים וחוזרניים (משפטים שלמים או חלקם) אולי יוגדרו כמיותרים ויוסרו

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

בשתי הדרכים ניתן לטעון לתהליך שהוא non-lossy, כלומר ללא אובדן מידע כלל או lossy, כלומר עם מידה חלקית של אובדן מידע ומה יהיה נכון תלוי בהקשר.

מחשוב

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