MasterScripter

הכירו: PRELOAD – פיצ'ר חדש בHTML5

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

preload? על מה בכלל מדובר?!

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

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

בדרך כלל מנגנון כזה מושג בדרכים "עקיפות", או כמו שאצלנו אוהבים לומר – workaround-ים.
זה יכול להיות קובץ js אשר נטען ראשון והוא זה שקובע את סדר הטעינה בעמוד, או בקשות XMLHttpRequest כאשר תנאים מסויימים מתקיימים.
ישנם גם מקרים בהם המשאבים צריכים להיטען ASAP (הכי מהר שאפשר!!), אבל העיבוד והשימוש בהם נתון לדרישות מסויימות הנובעות מלוגיקת הטעינה המוכתבת מראש.

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

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

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

אבל היו כבר דברים כאלה, לא?

כן, בערך. לא בדיוק.
אז כן, היו לנו דברים דומים, אבל לא בדיוק אותו דבר:

Prefetch

כבודו מונח במקומו והוא קיים כבר לא מעט זמן, עם תמיכה רחבה וחוצה דפדפנים, במיוחד לעומת הpreload שנמצא בחיתוליו.
אבל, preftech הוא directive אשר נועד להכווין את הדפדפן לטעון משאבים שונים אשר השימוש בהם יעשה רק לאחר הניווט הבא.
במילים פשוטות, זה אומר שהטעינה של המשאבים תחת prefetch מקבלים את העדיפות הנמוכה ביותר בסדר הטעינה, שזה נחמד – אבל זה לא עוזר לנו לטפל בטעינת המשאבים לעמוד הנוכחי!

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

Subresource

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

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

אפשר להגיד שלום ל- subresource

עם יציאתו של preload, גוגל הכריזו על הפסקת התמיכה ב<link rel="subresource">. מעבר להודאתם בכישלון של subresource, החל מ- Chrome 50 לא יהיה יותר צורך בו, משום שאפשר להשיג את אותה פונקציונליות עם <link rel="preload"> רק ללא הבאגים..:)

preload – יתרונות

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

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

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

  • טעינת משאבים שאינם מתגלים ע"י הpreloader של הדפדפן
  • טעינה מוקדמת של פונטים
  • טעינת משאב שהשימוש בו הוא דינמי
  • טעינה א-סינכרונית מבוססת markup
  • טעינה רספונסיבית של משאבים

אבל לפני שנתחיל, חשוב להתייחס לתכונה קטנה וחשובה מאוד בpreload החדש שלנו:

תכונת as ב- preload

תכונת הas תחת <link rel="preload"> היא התכונה אשר מאותת לדפדפן איזה סוג של משאב הוא הולך לטעון, ואיך להתייחס אליו.

לדוגמא:

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

media, script, style, font, image, worker, embed, object ו- document, נכון לעכשיו.

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

סוג המשאב ערך תכונת as
Audio, Video as=media
Scripts as=script
CSS, CSS @import as=style
CSS @font-face as=font
Images, Pictures, SVGs as=image
Worker, SharedWorker as=worker
Embed as=embed
Object as=object
iframes, frames as=document

אז אחרי שכיסינו את as, אני יודע שאתם כבר מתרגשים. או שזה רק אני..שנתחיל?

טעינת משאבים חשובים אשר לא מתגלים בpreloader של הדפדפן

אז כמו שבוודאי חוויתם בעבר, מרבית הטעינות המוקדמות של הדפדפנים (preloader-ים) לא מבצעים JavaScript, מבצעים ניתוח שטחי בלבד של CSS, ועוד שלל פגמים כאלה ואחרים.
כאשר יש לנו דברים חשובים אשר "מתחבאים" בתוך קבצים כאלו, הרבה פעמים אנחנו מרגישים על בשרנו את הטעינה המאוחרת שלהם – כמו למשל ברינדור(render) של טקסט או בטעינת דברים ספציפיים בעמוד.
לא עוד! מעכשיו אפשר להכווין את הדפדפן לטעון את המשאבים הללו ראשונים:

טעינה מוקדמת של פונטים

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

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

טעינת משאב שהשימוש בו הוא דינמי

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

כעת, עם preload, תוכלו לבנות לוגיקת טעינת משאבים וביצועם מותאמת, ללא הביצוע המוקדם או העיכוב בטעינה, לדוגמא:

טעינה א-סינכרונית מבוססת markup

באמצעות תכונת הonload של preload, אפשר ליצור "טוען" א-סינכרוני מבוסס markupים.
לדוגמא, אם נרצה ליצור טוען א-סינכרוני של קבצי style:

בכך בעצם ביצענו מניפולציה ויצרנו טעינה א-סינכרונית של קבצי הstyle.

שימו לב שניתן לבצע את אותו הדבר גם על קבצי script, והתוצאה תהיה זהה לשימוש ב<script async>, אולם ההבדל הוא שהonload event של החלון לא ייחסם במקרה של שימוש בpreload, לעומת השימוש ב<script async>.

טעינה רספונסיבית של משאבים

פונקציונליות מגניבה נוספת של הpreload שלובה בעצם היותו קישור (link).
מכיוון שpreload הוא קישור, יש לו את תכונת הmedia, מה שמאפשר לנו לטעון משאבים בתנאי שהם עונים על הגבלות הmedia שלנו – בדיוק מה שאנחנו צריכים לטעינת משאבים רספונסיבית!

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

השימוש כאן הוא מאוד פשוט, ממש כמו בשימוש בmedia-query:

מה קורה כשpreload לא נתמך

כמו שציינתי בהתחלה, וחשוב להדגיש ולציין את זה שוב – preload הוא סטנדרט בשלב הטיוטה (draft).
מה זה אומר? זה אומר שהתמיכה בו מאוד מצומצמת, והוא נתמך כרגע רק בChrome 50 ומעלה, Opera 37 ומעלה, Android Browser 50 ומעלה, ו-Chrome for Android 50 ומעלה.

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

סיכום ומסקנות

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

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

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

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

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

מקורות

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

אם הגעת עד לפה, הגיע הזמן להירשם לניוזלטר!

Summary
Article Name
Preload - פיצ'ר חדש בHTML5
Description
הסברים ודוגמאות על Preload, סטנדרט WEB חדש שנותן למתכנתים יותר שליטה על טעינת משאבים וסדר הטעינה שלהם.
Author
Publisher Name
MasterScripter
Publisher Logo
תגיות: ,
אודות 
הי, זה שלומי :) ב2013 הקמתי את קבוצת סיזן ביחד עם שותפי היקר - יונתן נקסי נקסון. אני מתעסק בפיתוח ועיצוב אתרי אינטרנט, אפליקציות, וכל דבר מבוסס WEB. בין היתר אני מתעסק במיתוג ושיווק דיגיטלי, הקמת מיזמים שונים, שתיית קפה וצפייה במשחקי הכס. אם בא לכם להגיד לי משהו - לכו על זה, רק אל תעשו לי ספויילרים!

0 תגובות

השאר/י תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *