דילוג לתוכן
חיפוש באתר

ביצועים

משאבים חוסמי רינדור ו-Critical CSS: למה האתר מציג מסך לבן

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

· עודכן: · 1 צפיות ·

משאבים חוסמי רינדור (Render-blocking resources) הם קבצי CSS ו-JavaScript שהדפדפן חייב להוריד ולעבד לפני שהוא מצייר משהו על המסך. כל עוד הם בדרך, הגולש רואה מסך לבן. Critical CSS (עיצוב קריטי) היא אחת הדרכים לטפל בזה: מכניסים לראש העמוד רק את העיצוב שנחוץ לחלק הנראה הראשון, ומעכבים את השאר. לפני שמגיעים לטכניקות מתקדמות כאלה, חשוב להבין מה בדיוק חוסם — כי ברוב האתרים הפתרון פשוט יותר.

מה נחשב חוסם

לפי התיעוד של Lighthouse, שני סוגי משאבים נחשבים חוסמי רינדור:

  • סקריפט בראש העמוד (head) בלי defer ובלי async.
  • קובץ עיצוב שאין לו מאפיין disabled, ושמאפיין ה-media שלו מתאים למכשיר — כולל media="all".

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

סקריפטים: defer או async

סקריפטים הם המקום שבו יש הכי הרבה מה להרוויח. לפי MDN, סקריפט בלי async, defer או type="module" נטען ומורץ מיד, והדפדפן מפסיק לקרוא את העמוד עד שזה נגמר.

מאפיין הורדה הרצה סדר
בלי כלום עוצרת את קריאת העמוד מיד לפי העמוד
async במקביל ברגע שהקובץ הגיע לא מובטח
defer במקביל אחרי שהעמוד נקרא לפי העמוד
type="module" במקביל כמו defer כברירת מחדל לפי העמוד

כלל אצבע: סקריפט של האתר עצמו, שעובד עם מבנה העמוד — defer. סקריפט עצמאי, כמו אנליטיקה — async. בוורדפרס אפשר להגדיר את זה ישירות כשמוסיפים את הסקריפט בתבנית, בלי תוסף.

באתר הזה, הסקריפטים של התבנית נטענים עם defer, ותג האנליטיקה עם async. אף סקריפט לא חוסם את התצוגה הראשונה.

עיצוב: לצמצם, לפצל, ורק אז Critical CSS

1. להוריד עיצוב שלא בשימוש

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

2. לפצל לפי media

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

3. Critical CSS

לפי web.dev, הטכניקה מחלצת את העיצוב של החלק העליון של העמוד ומכניסה אותו ישירות ל-style בראש ה-HTML, כך שהעמוד מצויר בלי לחכות לקובץ חיצוני. web.dev ממליצה לשמור את התוכן של החלק העליון מתחת ל-14KB דחוסים, כדי שייכנס בסבב הראשון של החיבור. השאר נטען בלי לחסום.

אבל web.dev גם מזהירה: זו טכניקה מתקדמת שעלולה לגרום לבאגים, ורוב האתרים יכולים לעמוד ביעדי הביצועים בלעדיה. עיצוב שמוטמע בכל עמוד לא נשמר במטמון בנפרד, ואם מטמיעים יותר מדי — "אם הכול בעדיפות, שום דבר לא בעדיפות". הבאג הקלאסי: עיצוב קריטי שחולץ מדף הבית ולא מתאים לעמוד מוצר, וגורם לקפיצה כשהעיצוב המלא מגיע.

4. גופנים

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

הסדר שאני עובד לפיו

  1. סקריפטים: כל מה שלא חייב לרוץ לפני התצוגה מקבל defer או async.
  2. עיצוב: מורידים קבצים של תוספים ורכיבים שלא בשימוש בעמוד.
  3. מה שנשאר — קובץ עיצוב אחד או שניים, מכווצים ודחוסים. ראו מיניפיקציה ודחיסה.
  4. רק אם אחרי כל זה התצוגה הראשונה עדיין איטית — Critical CSS, עם בדיקה בכל סוג עמוד.

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

שאלות נפוצות

Lighthouse מסמן קובץ עיצוב כחוסם. חייבים לתקן?

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

תוסף מהירות יכול לעשות את זה אוטומטית?

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

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

אהבתם את המאמר?

בואו נבנה יחד!

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

חיפוש באתר