למה משאבים חוסמי עיבוד עדיין האויב הכי גדול של אתרים מהירים

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

זאת בעיית ביצועים שקיימת כבר יותר מעשור, והיא עדיין הדבר הראשון שמופיע באדום בבדיקות PageSpeed Insights או Lighthouse. הנה למה היא לא נעלמת, ומה באמת פותר אותה.

מה זה בעצם משאבים חוסמי עיבוד

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

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

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

למה זה עדיין חשוב לגבי Core Web Vitals

משאבים חוסמי עיבוד פוגעים ישירות בשניים משלושת מדדי Core Web Vitals:

• Largest Contentful Paint (LCP) - אם ה-CSS או ה-JS שלכם מעכבים את העיבוד, תמונת הכותרת או הכותרת הראשית לא יכולות להצטייר עד שהמשאבים החוסמים מסיימים. גוגל רוצה LCP מתחת ל-2.5 שניות.
• First Contentful Paint (FCP) - המדד הזה מודד את הפיקסל הראשון על המסך, והוא כמעט לגמרי תלוי בבקשות חוסמות עיבוד בנתיב הקריטי.

אתר עם 2-3 גיליונות עיצוב חוסמי עיבוד וכמה סקריפטים סינכרוניים של צד שלישי מאבד בדרך כלל בין 800 מילישניות ל-1.5 שניות לפני שמשהו נראה לעין. זה ההבדל בין ציון עובר לציון נכשל ב-Core Web Vitals, וזה סימן דירוג שגוגל באמת משתמש בו.

איך לזהות את המשאבים החוסמים אצלכם

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

• הריצו את כתובת האתר שלכם ב-Lighthouse או PageSpeed Insights ובדקו את הבדיקה "ביטול משאבים חוסמי עיבוד". היא מציגה כל קובץ בעייתי עם הערכת חיסכון במילישניות.
• פתחו את Chrome DevTools, עברו ללשונית Network, וסננו לפי CSS ו-JS. כל דבר שנטען לפני סימון "First Paint" בציר הזמן חשוד.
• השתמשו בתצוגת ה-waterfall של WebPageTest כדי לראות בדיוק אילו בקשות מעכבות את שורת תחילת העיבוד.

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

טכניקות לשיפור מהירות אתר שבאמת פותרות את זה

1. השתמשו ב-defer וב-async עבור ה-JavaScript

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

<script src="/analytics.js" async></script>
<script src="/app.js" defer></script>

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

2. הטמיעו CSS קריטי בתוך הדף, ודחו את השאר

אתם לא צריכים את כל גיליון העיצוב בגודל 200KB כדי לצייר את המסך הראשון. חלצו את ה-CSS הנדרש לתוכן שמופיע מעל לקיפול, הטמיעו אותו ישירות ב-<head> של ה-HTML, וטענו את השאר בצורה אסינכרונית ברגע שהעמוד כבר נראה. זו אחת הטכניקות היעילות ביותר לשיפור מהירות אתר, כי היא מאפשרת לדפדפן לצייר מיד במקום לחכות להורדת גיליון עיצוב מלא.

3. הסירו CSS שלא בשימוש

הרבה תבניות ובוני עמודים מגיעים עם ספריות CSS שבהן אתם משתמשים אולי ב-15% מהכללים. הסרת ה-85% שלא בשימוש מקטינה משמעותית את גודל הקובץ ומזרזת את בניית ה-CSSOM, שקורית לפני שכל עיבוד מתחיל.

4. כווצו ואחדו קבצים כשזה עוזר

פחות קבצים, קטנים יותר, אומר פחות מעברי רשת. כיווץ (minification) מסיר רווחים והערות, ואיחוד מקטין את מספר בקשות ה-HTTP, אם כי עם HTTP/2 זה פחות משמעותי ממה שהיה פעם.

5. דחו JavaScript לא חיוני עד לאינטראקציה של המשתמש

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

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

דוגמה מהחיים האמיתיים

קחו אתר WordPress טיפוסי: גיליון עיצוב של התבנית בגודל 180KB, Google Fonts שנטען דרך @import, וארבעה סקריפטים של תוספים ב-head בלי defer. לפני ייעול, ה-FCP נמצא סביב 2.8 שניות בחיבור 4G.

אחרי הטמעת CSS קריטי, דחיית גיליון העיצוב המלא, הוספת defer לכל הסקריפטים הלא חיוניים, והסרת כללי CSS לא בשימוש, אותו עמוד בדיוק לרוב יורד ל-1.1-1.4 שניות FCP. בלי שדרוג שרת, בלי שינוי CDN, רק הסרת החוסמים בין הדפדפן לפיקסלים.

איפה אחסון נכנס לתמונה

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

אם אתם רוצים להעמיק במדד שמודד את העיכוב הזה בצד השרת, כיסינו אותו בלמה ה-Time to First Byte שלכם עולה לכם בהמרות. ואם נפיחות ב-CSS היא הבעיה הספציפית שלכם, כדאי לקרוא גם את המאמר שלנו על איך caching מאיץ את WordPress.

לסיכום

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