זה לא Case-Study של לקוח. זה האתר שלי. בניתי אותו בעצמי, השקעתי בו המון אפקטים ואנימציות, ונהניתי מכל פיקסל. ואז הוא הרגיש איטי בנייד. הסיפור הזה הוא איך לקחתי משהו שאני אוהב ועיצבתי בידיים שלי, וגרמתי לו להיות גם מהיר, בלי לוותר על העיצוב אפילו קצת. אבל יותר מזה, זה הסיפור של איך האבחנה שלי השתנתה לגמרי בדרך. מה שחשבתי שמאט את האתר בהתחלה, התברר כלא נכון בכלל. ובכל צעד, מדידה אחת שינתה לי את כל ההבנה.
המצב לפני
המצב אחרי
מילון מונחים קצר
לאורך הכתבה אני משתמש בכמה מונחים מקצועיים באנגלית. הנה ההגדרה של כל אחד, שורה אחת לכל מונח, כדי שתוכל לקרוא בלי להיתקע:
- LCP (Largest Contentful Paint): הזמן שבו הרכיב המרכזי בעמוד מסיים להופיע על המסך. זה המדד שהכי קרוב לתחושת המהירות.
- FCP (First Contentful Paint): הזמן שבו מופיע הפיקסל הראשון של תוכן אמיתי.
- TBT (Total Blocking Time): כמה זמן הדפדפן היה תפוס ולא הגיב לך בזמן הטעינה.
- CLS (Cumulative Layout Shift): מדד יציבות, עד כמה התוכן קופץ וזז תוך כדי טעינה.
- TTFB (Time To First Byte): הזמן עד שהשרת מחזיר את הבייט הראשון של העמוד.
- DOM: עץ הרכיבים שמרכיב את העמוד, וכמה גדול ומורכב הוא.
- Render-delay: הזמן שבו הרכיב כבר ירד מהרשת אבל עוד לא צויר על המסך, כי משהו אחר תפס את הדפדפן.
- Main thread: הליבה שבה הדפדפן מצייר את העמוד ומריץ קוד. כשהיא תפוסה, שום דבר לא מצויר.
- Reflow: חישוב מחדש של פריסת העמוד. אם קוד מבקש מידות פריסה תוך כדי אנימציה, הדפדפן נאלץ לעצור ולחשב הכול שוב.
- PageSpeed Insights ו-Lighthouse: כלי המדידה של גוגל, שמריצים בדיקת מעבדה ונותנים ציון.
- DevTools: כלי הפיתוח המובנים בדפדפן, שמאפשרים לתעד את הטעינה צעד אחר צעד.
- HAR: קובץ שמתעד את כל הבקשות שהעמוד שלח, מתי כל אחת יצאה וכמה היא שקלה.
- Throttling: האטה מלאכותית של מעבד ורשת, כדי לדמות מכשיר וחיבור איטיים.
- Lab מול Field: בדיקת מעבדה בתנאים מבוקרים מול נתוני שדה ממשתמשים אמיתיים.
- CrUX (Chrome User Experience Report): נתוני השדה של גוגל ממשתמשים אמיתיים, אלה שמשפיעים על הדירוג.
- Speed Index: מדד למהירות שבה תוכן העמוד מתמלא ויזואלית.
לפני שמתחילים: שתי החלטות שהנחו את כל הדרך
שתי החלטות עמדו ברקע של כל צעד, אז כדאי לומר אותן מראש. הראשונה: את אופטימיזציית הביצועים עשיתי אחרונה, אחרי שהאתר כבר עלה לאוויר. וזו לא הייתה התרשלות, זו הייתה בחירה. מדידה אמיתית קורית על פרודקשן, לא על סביבה מקומית. כשמודדים אתר על המחשב שלי, המספרים יפים ומשקרים: אין שם את ההשהיה של שרת אמיתי, אין את הרשת האמיתית, ואין את ההתנהגות של מכשיר נייד אמיתי תחת עומס. רק כשהאתר חי, מול תנאים אמיתיים, התמונה האמיתית מתחילה להופיע.
ההחלטה השנייה: כל אפקט נשאר. הצבתי לעצמי גבול ברור עוד לפני שנגעתי במשהו: שום דבר מהעיצוב לא הולך לאיבוד. קל מאוד לעשות אתר מהיר אם מוחקים ממנו את כל מה שכבד. זה לא אתגר, זה ויתור. האתגר האמיתי הוא לקחת אזור פתיחה עשיר ומונפש ולגרום לו להופיע מהר וחלק, בלי לכבות אותו. ואני רוצה לפרק כאן מיתוס: אתה לא חייב לבחור בין יופי למהירות. אפשר להחזיק את שניהם. צריך רק לאבחן נכון ולתקן את הסיבה, לא את התסמין. הכתבה הזו היא בעצם הסיפור של איך מצאתי את הסיבה האמיתית, אחרי כמה אבחנות שגויות בדרך.
צעד 1: האתר נראה מצוין, אבל הרגיש איטי בנייד
הכול התחיל מתחושה. במחשב האתר עף, אבל בנייד אזור הפתיחה לקח כמה שניות עד שהתייצב, ומשהו פשוט הרגיש כבד.
ההנחה הטבעית הראשונה שלי הייתה בדיוק זו שיש לכל אחד: האתר כנראה כבד מדי. יותר מדי בייטים, יותר מדי תמונות, אולי שרת איטי. זה ההסבר ההגיוני, וזה בדיוק ההסבר שהתברר כלא נכון. אבל בשלב הזה לא ידעתי את זה עדיין. ידעתי רק שצריך למדוד, לא לנחש.
צעד 2: המדידה הראשונה הפכה לי את ההנחה
מדדתי את האתר על פרודקשן, חציון של חמש הרצות בנייד, לא הרצה בודדת. עמוד השירות, הגרוע מכולם, יצא עם LCP של כ-8.8 שניות, ובדיקה אחר בדיקה הוא קפץ בין מהיר לאיטי. אבל הדבר שבאמת תפס אותי לא היה המספר, אלא מה שהוא הצביע עליו. הרכיב שקבע את ה-LCP, כלומר הדבר האחרון שהמשתמש מחכה שיופיע, לא היה תמונה ולא קובץ כבד. זו הייתה כותרת ה-H1, טקסט פשוט. והטקסט הזה כבר היה מוכן: הוא לא חיכה לרשת, הוא חיכה למשהו שתפס את הדפדפן.
זו הייתה ההפתעה הראשונה. כל ההנחה שלי על בייטים ועל משקל קרסה במדידה אחת. הבעיה לא הייתה כמה האתר שוקל, אלא מתי הוא מצייר. רוב ה-LCP היה render-delay: הטקסט מוכן, אבל לא מצויר על המסך, כי המעבד עסוק במשהו אחר. בנקודה הזו עוד לא ידעתי במה בדיוק הוא עסוק. ידעתי רק שכיוונתי לכיוון הלא נכון.
צעד 3: ניסיון התיקון הראשון יצא ניטרלי, וזה לימד אותי הכי הרבה
למרות ההפתעה, עדיין רציתי לסגור את חזית הבייטים, ולו כדי לפסול אותה. אז בניתי צנרת בנייה מודרנית שמכווצת את קבצי האתר ומפיקה אותם בשמות ממוספרים, כך ששמירה אגרסיבית במטמון לעולם לא תגיש גרסה ישנה. הקטנתי את התמונות לגודל הנכון ולפורמט מודרני וקליל. במילים אחרות, עשיתי בדיוק את מה שכולם ממליצים כשאתר איטי: הקטנתי, כיווצתי, ייעלתי.
ואז מדדתי שוב. ה-LCP לא זז. הוא נשאר תקוע על אותם 8.8-9.2 שניות, שטוח לגמרי. וזו לא הייתה אכזבה, זו הייתה ההוכחה שחיכיתי לה. אם הקטנתי משמעותית את המשקל וה-LCP לא זז אפילו עשירית שנייה, אז הבעיה היא לא המשקל. נקודה. המדידה הניטרלית הזו פסלה סופית את חזית הבייטים והפנתה אותי בדיוק למקום הנכון: שרשרת הציור והרינדור, לא הרשת. לפעמים תיקון שלא משנה כלום בציון הוא בדיוק המידע הכי שווה שתקבל.
צעד 4: ירדתי לעומק, וגיליתי שהאשם הוא האנימציה שעבדתי עליה קשה
עכשיו ידעתי לאן לחפור. תיעדתי את הטעינה ב-DevTools, פריים אחרי פריים, והוספתי קובץ HAR שמראה בדיוק אילו בקשות יצאו ומתי. ה-HAR סגר עוד דלת: כל ה-HTML, ה-CSS והגופנים סיימו לרדת מהר מאוד. הרשת לא הייתה צוואר הבקבוק. הצוואר היה ה-main thread.
וכאן הגיעה ההפתעה השנייה, הכואבת יותר. הציור של הכותרת היה חסום על ידי תפיסת המעבד, ומי שתפס אותו היה אזור הפתיחה המונפש שלי. בדיוק האנימציה היפה שהשקעתי בה הכי הרבה. היא רצה בזמן הקריטי של הטעינה, וגרוע מזה: הקוד שלה ביקש מהדפדפן מידות פריסה שוב ושוב תוך כדי ריצה, מה שאילץ אותו לעצור ולחשב מחדש את כל הפריסה, פעם אחר פעם (reflow). זו הייתה משימה ארוכה שתקעה את הדפדפן בדיוק כשהוא היה אמור לצייר את הכותרת. האשם לא היה הרשת ולא השרת. האשם היה הדבר היפה ביותר באתר, וזה בדיוק מה שהפך את התיקון למעניין: לא יכולתי פשוט למחוק אותו.
צעד 5: ניסוי המטמון, והכלל שאני נושא איתי מאז
בדרך נתקלתי בתופעה שבלבלה אותי. כשהפעלתי את שכבת המטמון, ה-LCP דווקא נעשה גרוע ולא יציב, ואילו בלי מטמון הוא היה איטי יותר בשרת אבל עקבי לגמרי. זה נגד האינטואיציה: מטמון אמור להאיץ, לא להאט. אז עשיתי ניסוי מבוקר, A/B אמיתי: מדדתי את העמוד בלי מטמון, ואז עם שתי גישות מטמון שונות, חמש הרצות לכל מצב.
התוצאה הייתה חד-משמעית. בלי מטמון: LCP עקבי, אם כי השרת איטי יותר. עם מטמון, לא משנה איזה: שרת מהיר, אבל LCP שקפץ בין מהיר לאיטי. החלפת גישת המטמון לא שינתה כלום, ולכן הבעיה לא הייתה בשום כלי מטמון מסוים. המנגנון התברר ככה: מטמון מהיר מקצר את זמן התגובה של השרת (TTFB) עד כמעט אפס, וזה דווקא מושך את הפעילות המאוחרת בצד הדפדפן, אותה אנימציה, אל תוך החלון שבו ה-LCP עוד נמדד, וגורם למרוץ. המטמון לא יצר את הבעיה. הוא רק חשף בעיית תזמון שכבר הייתה שם.
זה היה חידוד אבחנתי, לא תיקון. הכלל שיצא לי מזה, ושאני נושא איתי לכל עבודת ביצועים מאז: מטמון חושף בעיות תזמון, הוא לא יוצר אותן. אז תקן את צד הדפדפן, ואל תרדוף אחרי כלי מטמון. השארתי את המטמון בדיוק במקומו.
צעד 6: התיקון האמיתי, בלי לוותר על אף אפקט
עכשיו, כשהאבחנה הייתה מדויקת, התיקון היה ברור. לא נגעתי בעיצוב. תיקנתי את התזמון. דחיתי את כל האנימציות שאינן קריטיות אל מחוץ למסלול הקריטי, כך שהעמוד מצויר מהר ורק אחר כך מתעשר. את אזור הפתיחה תיקנתי בקפידה מיוחדת: הנחתי תמונת רקע סטטית מתחת לאנימציה החיה, כך שהיא מחזיקה את המקום ומופיעה מיד, היא בעצם הופכת לרכיב ה-LCP. ברגע שהפריים הראשון של האנימציה החיה מוכן באמת, יש מעבר רך אליה. והאנימציה הכבדה עצמה נטענת מהרשת רק כשמתקרבים אליה, לא בהתחלה. כך אזור הפתיחה אף פעם לא נשאר ריק, והפער של כארבע שניות שהשאיר אותו ריק פשוט נעלם.
לצד זה סגרתי גם את צד השרת והמטמון, אבל הפעם נכון: הגדרתי שמירה ארוכת טווח לקבצים הקבועים של האתר ברמת השרת, עם תוקף ארוך מאוד בדפדפן, כך שמבקר חוזר כמעט לא מוריד אותם שוב. הצנרת עם השמות הממוספרים מצעד 3 היא בדיוק מה שהפך את השמירה האגרסיבית הזו לבטוחה. כל זה בלי להסיר אפילו אלמנט עיצובי אחד. תיקנתי את הסיבה, לא את התסמין, והעיצוב נשאר שלם.
צעד 7: מה שלמדתי על מדידה, כשהמספרים סתרו זה את זה
לאורך כל הדרך הכלים לא תמיד הסכימו ביניהם, וזה החלק שלימד אותי הכי הרבה. בדיקת המעבדה של גוגל מדמה את ההאטה באופן מחושב, לא אמיתי, ולכן היא יכולה להציג LCP מוקצן או לא יציב, במיוחד כשמטמון מהיר מקצר את זמן התגובה של השרת. כשבדקתי באותו עמוד עם DevTools בהאטה מיושמת, האטה אמיתית של מעבד ורשת, קיבלתי כ-2.4 שניות, בעוד בדיקת המעבדה המדומה הראתה מספר גבוה בהרבה. כששתי הבדיקות נחלקו, סמכתי על הבדיקה המיושמת בכל מה שנוגע לחוויית המשתמש, כי היא קרובה יותר למה שמבקר אמיתי מרגיש.
ומעל הכול, יש את ה-Field. גוגל לא מדרג לפי ציון המעבדה. הדירוג נשען על נתוני שדה אמיתיים, ה-CrUX, באחוזון ה-75 בחלון של 28 יום. כשאין מספיק תנועה כתוב שם פשוט No Data, וזה לא כישלון, רק חוסר נתונים. ושינוי באתר לוקח בערך ארבעה שבועות עד שהוא מופיע בשדה. לכן עבדתי לפי שלושה כללים: מדדתי חציון של כמה הרצות ולא ציון בודד, כי מדידה אחת בנייד היא רעש ולא אות, וחציון גם חושף שני אשכולות של תוצאות שמסגירים תזמון לא יציב; מדדתי על פרודקשן, כי שם האמת; ורדפתי אחרי הבעיה הנכונה, לא אחרי המספר שהכי קל למדוד. השתמשתי בכמה כלים בכוונה, כי כל כלי רואה דבר אחר, ואף אחד מהם לבדו לא נותן את התמונה המלאה. בסוף בחרתי לא לרדוף אחרי ציון המעבדה המדומה. שיפרתי את החוויה האמיתית, ונתוני השדה יתעדכנו בקצב שלהם.
צעד 8: התוצאות, במספרים אמיתיים מפרודקשן
אלה המספרים שנמדדו על עמוד השירות שבחרתי כדוגמה, לפני ואחרי, בהאטה מיושמת:
| מדד | לפני | אחרי |
|---|---|---|
| LCP, הזמן להופעת התוכן המרכזי | 8.8 שניות | 2.4 שניות |
| משקל העמוד הראשוני | 2.1MB | 679KB |
| מספר הרכיבים בעמוד (DOM) | 2,267 | 816 |
| TBT, זמן חסימת הדפדפן | 230ms | אפס כמעט מוחלט |
| CLS, יציבות הפריסה | 0 | 0 |
| הפער שבו אזור הפתיחה נשאר ריק | כ-4 שניות | נעלם |
| חוסר היציבות של ה-LCP בבדיקת המעבדה | בימודלי, קפיצות עד 8 שניות | נעלם |
| אזור הפתיחה המונפש | נשאר במלואו | נשאר במלואו |
והדבר החשוב מכול: אזור הפתיחה המונפש העשיר נשאר במלואו. שום אפקט לא הוקרב. נקודה אחת של יושרה: ציון ה-LCP בבדיקת המעבדה של גוגל עדיין מציג מספר גבוה יותר מהמציאות, כי הוא תוצר של סימולציה. בחרתי לא לרדוף אחריו. שיפרתי את החוויה האמיתית, ונתוני השדה יתעדכנו בקצב שלהם.
מה זה אומר לאתר שלך
אתר מהיר הוא לא מותרות טכניות. הוא הדבר שמחזיק את המבקר בפנים במקום לאבד אותו בשנייה הראשונה, והוא משדר רצינות עוד לפני שקראת מילה אחת. ואם יש דבר אחד שהמסע הזה לימד אותי, הוא זה: התשובה הראשונה כמעט תמיד שגויה. חשבתי שזה המשקל, וזה היה התזמון. חשבתי שזה המטמון, וזה היה צד הדפדפן. רק מדידה נכונה, על פרודקשן, שלב אחר שלב, הביאה אותי לסיבה האמיתית. והבשורה הטובה: כמעט תמיד אפשר להגיע לשם בלי לוותר על העיצוב שאהבת. צריך רק לתקן את הסיבה, לא את התסמין.
רוצה לדעת כמה מהר האתר שלך באמת
אם האתר שלך מרגיש איטי בנייד, או שאתה פשוט לא בטוח כמה מהר הוא באמת, אשמח להציץ. אני מודד את האתר שלך בתנאים אמיתיים, מאתר מה באמת מאט אותו, ומתקן את הסיבה בלי לפגוע בעיצוב. בקש בדיקת מהירות לאתר או צור קשר ב-WhatsApp.
אני גרי חלימסקי, מומחה וורדפרס עצמאי עם 10 שנות ניסיון. אני מתמחה באבחון תקלות, אבטחה, ושיפור ביצועים של אתרי וורדפרס לעסקים קטנים ובינוניים בישראל. בעת הצורך נעזר במומחים מהימנים (עיצוב, שיווק, אנליטיקה). פרטים על השירותים.
