תחביר תיאורי

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

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

תיאור הצפיפות באמצעות x

<img> עם רוחב קבוע יתפוס את אותה אזור של אזור התצוגה בכל הקשרי גלישה, ללא קשר לצפיפות של התצוגה של המשתמש – מספר הפיקסלים הפיזיים שיוצרים את המסך. לדוגמה, תמונה ברוחב מובנה של 400px תתפוס כמעט את כל אזור התצוגה של הדפדפן ב-Google Pixel המקורי וגם ב-Pixel 6 Pro חדש יותר – בשני המכשירים יש אזור תצוגה רחב של 412px פיקסל לוגי מנורמל.

ל-Pixel 6 Pro יש מסך חד בהרבה. עם זאת, למכשיר Pixel 6 Pro יש רזולוציה פיזית של 1440 × 3120 פיקסלים, ואילו Pixel הוא 1,080 × 1,920 פיקסלים - כלומר, מספר הפיקסלים של החומרה שמרכיבים את המסך עצמו.

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

כלומר, שיעור ה-DPR של ה-Pixel המקורי הוא 2.6, ואילו ה-DPR של Pixel 6 Pro הוא 3.5.

ב-iPhone 4, המכשיר הראשון עם ערך DPR גדול מ-1, מדווח על יחס פיקסלים של 2 במכשיר – הרזולוציה הפיזית של המסך כפולה מהרזולוציה הלוגית. ערך ה-DPR של כל מכשיר לפני ה-iPhone 4 היה 1: פיקסל לוגי אחד לפיקסל פיזי אחד.

אם רואים את התמונה לרוחב 400px במסך עם ערך DPR של 2, כל פיקסל לוגי מעובד בארבעה מהפיקסלים הפיזיים של המסך: שני פיקסלים אופקיים ושני אנכיים. התצוגה בצפיפות גבוהה של התמונה לא מועילה – היא תיראה בדיוק כמו במסך עם DPR של 1. כמובן, כל דבר ש"צייר" על ידי מנוע העיבוד של הדפדפן - טקסט, צורות CSS או SVG, לדוגמה - יישלף כך שיתאים לתצוגה בצפיפות גבוהה יותר. אבל כמו שלמדתם מImage Formats and Compression, תמונות מסוג רסטר הן רשתות קבועות של פיקסלים. זה לא תמיד מובן מאליו, אבל תמונה בפורמט רסטר שמותאמת לתצוגה בצפיפות גבוהה יותר תיראה ברזולוציה נמוכה בהשוואה לדף שמסביב.

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

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

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

כפי שאולי ניחשת, מכשירים ניידים עם ערך DPR 1 הם נדירים ונעלמים, אם כי הם עדיין נפוצים בהקשרים של גלישה 'מחשב'. לפי הנתונים ששותפו על ידי מאט הובס, כ-18% מסשנים של הגלישה ב-GOV.UK מנובמבר 2022 מדווחים על DPR של 1. תמונות בצפיפות גבוהה ייראו כמו שהמשתמשים עשויים לצפות להן, אבל רוחב הפס ועלות העיבוד שלהן יהיו גבוהים בהרבה, במיוחד למשתמשים במכשירים ישנים יותר ופחות חזקים שעדיין עשויים לכלול מסכים בצפיפות נמוכה.

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

המאפיין srcset מזהה מועמד אחד או יותר לעיבוד תמונה, שמופרדים בפסיקים. כל אפשרות מורכבת משני דברים: כתובת URL, בדיוק כמו שמשתמשים ב-src, ותחביר שמתאר את המקור של התמונה. כל אלמנט אפשרי ב-srcset מתואר לפי רוחב מטבעו ('תחביר w') או לפי צפיפות מיועד ('תחביר x').

התחביר x הוא קיצור של "המקור הזה מתאים למסך עם הצפיפות הזו" – מועמד ואחריו 2x מתאים לתצוגה עם DPR של 2.

<img src="low-density.jpg" srcset="double-density.jpg 2x" alt="...">

דפדפנים שתומכים ב-srcset יוצגו עם שני מועמדים: double-density.jpg, שמתאר את 2x כמתאים לצגים עם DPR של 2 ו-low-density.jpg במאפיין src – האפשרות שנבחרה נמצאת אם אין אפשרות מתאימה יותר ב-srcset. בדפדפנים שאין תמיכה ב-srcset, המערכת תתעלם מהמאפיין ומהתוכן שלו — בקשות לתוכן של src יתבקשו כרגיל.

אפשר להטעות בקלות את הערכים שצוינו במאפיין srcset לקבלת הוראות. ה-2x הזה מודיע לדפדפן שקובץ המקור המשויך מתאים לשימוש במסך עם DPR של 2 – מידע על המקור עצמו. הקוד לא מנחה את הדפדפן איך להשתמש במקור הזה, אלא רק מודיע לו איך אפשר להשתמש במקור. זו הבחנה עדינה אבל חשובה: מדובר בתמונה בצפיפות כפולה, ולא תמונה לשימוש בתצוגה בצפיפות כפולה.

ההבדל בין תחביר שבו כתוב "המקור הזה מתאים לצגים של 2x" לתחביר "השתמש במקור הזה במסכים של 2x" הוא קטן בדפוס, אבל צפיפות התצוגה היא רק אחד מתוך מספר עצום של גורמים מקושרים בין-כיווניים שהדפדפן משתמש בהם כדי להחליט על המועמד לעיבוד, שרק אתם יודעים את חלקם. לדוגמה, באופן פרטני, אפשר לקבוע שמשתמש הפעיל העדפת דפדפן לחיסכון ברוחב פס באמצעות שאילתת המדיה prefers-reduced-data, ולהשתמש בה כדי להגדיר תמיד למשתמשים תמונות בצפיפות נמוכה, בלי קשר לצפיפות התצוגה שלהם - אבל אם לא תטמיעו אותה באופן עקבי, על ידי כל מפתח, בכל אתר, לא יועיל למשתמש הרבה. יכול להיות שהם יכבדו את ההעדפה שלהם באתר מסוים, ובאתר הבא הם ייתקלו בקיר תמונות משמיד רוחב פס.

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

תיאור הרוחב באמצעות w

ב-srcset ניתן להשתמש בסוג שני של מתאר למועמדים של מקור התמונה. זו אפשרות הרבה יותר חזקה - ולמטרות שלנו, הרבה יותר קל להבין את המשמעות שלה. במקום לסמן מועמד שיש לו את המימדים המתאימים לצפיפות תצוגה נתונה, התחביר w מתאר את הרוחב המובנה של כל מקור מועמד. שוב, כל מועמד זהה במידות שלו – אותו תוכן, אותו חיתוך ואותו יחס גובה-רוחב. אבל במקרה הזה, אתם רוצים שהדפדפן של המשתמש יבחר בין שני מועמדים: small.jpg, מקור עם רוחב מובנה של 600px ו-large.jpg, מקור עם רוחב מובנה של 1200px.

srcset="small.jpg 600w, large.jpg 1200w"

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

תיאור השימוש עם sizes

לדפדפן יש ביצועים יוצאים מן הכלל בכל הנוגע להעברת תמונות. בקשות לנכסי תמונות יישלחו הרבה לפני בקשות לגיליונות של סגנונות או ל-JavaScript – לעיתים קרובות אפילו לפני שתגי העיצוב ינותחו באופן מלא. כשהדפדפן שולח את הבקשות האלה, אין לו מידע על הדף עצמו מלבד תגי העיצוב. ייתכן שהוא עדיין לא הגיש בקשות לגיליונות סגנונות חיצוניים, או שלא החיל אותם. כשהדפדפן מנתח את תגי העיצוב ומתחיל לשלוח בקשות חיצוניות, הוא מכיל רק מידע ברמת הדפדפן: גודל אזור התצוגה של המשתמש, דחיסות הפיקסלים של תצוגת המשתמש, העדפות המשתמש וכו'.

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

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

הטקסט הזה אולי יישמע קצת מסובך, אבל הרבה יותר קל להבין אותו בפועל:

<img
 sizes="80vw"
 srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
 src="fallback.jpg"
 alt="...">

כאן, הערך sizes מודיע לדפדפן שהמרחב בפריסה שלנו img תופס רוחב של 80vw—80% מאזור התצוגה. חשוב לזכור: זו לא הוראה, אלא תיאור של גודל התמונה בפריסת הדף. לא כתוב "להפוך תמונה זו לתופסת 80% מאזור התצוגה", אלא "בסופו של דבר התמונה הזו תתפוס 80% מאזור התצוגה לאחר עיבוד הדף."

כמפתח, העבודה שלך הושלמה. תיארת במדויק רשימה של מקורות אפשריים ב-srcset ואת רוחב התמונה ב-sizes, ובדיוק כמו עם התחביר x ב-srcset, כל השאר תלוי בדפדפן.

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

הודעת לדפדפן שהתמונה הזו תתפוס 80% מאזור התצוגה הזמין. לכן, אם נבצע רינדור של img במכשיר עם אזור תצוגה ברוחב של 1,000 פיקסלים, התמונה תתפוס 800 פיקסלים. לאחר מכן הדפדפן לוקח את הערך הזה ומחלק אותו בהתאם לרוחב של כל אחד מהמועמדים למקור התמונה שציינו ב-srcset. למקור הקטן ביותר יש גודל מובנה של 600 פיקסלים, כלומר: 600÷800=0.75. התמונה הבינונית היא ברוחב 1,200 פיקסלים: 1,200÷800=1.5. התמונה הגדולה ביותר היא ברוחב 2,000 פיקסלים: 2,000÷800=2.5.

התוצאות של החישובים האלה (.75, 1.5 ו-2.5) הן למעשה אפשרויות של DPR שמותאמות במיוחד לגודל אזור התצוגה של המשתמש. מאחר שלדפדפן יש גם מידע על צפיפות התצוגה של המשתמש, הוא מקבל מספר החלטות:

בגודל של אזור התצוגה הזה, האפשרות small.jpg נמחקת ללא קשר לצפיפות התצוגה של המשתמש – אם ה-DPR המחושב נמוך מ-1, המקור הזה ידרוש התאמה לעומס (scaling) עבור כל המשתמשים, כך שהוא לא מתאים. במכשיר עם DPR של 1, medium.jpg מספק את ההתאמה הכי קרובה – המקור הזה מתאים להצגה בDPR של 1.5, כך שהוא קצת יותר גדול מהנדרש, אבל חשוב לזכור שהקטנת קנה המידה היא תהליך חלק מבחינה חזותית. במכשיר עם ערך DPR של 2,large.jpg היא ההתאמה הקרובה ביותר, ולכן היא תיבחר.

אם אותה תמונה תעובד באזור תצוגה רחב של 600 פיקסלים, התוצאה של כל החישובים האלה תהיה שונה לחלוטין: הגודל של 80vw הוא 480px. כשמחלקים את ערכי הרוחב של המקורות בערך הזה, מקבלים 1.25, 2.5 ו-4.1666666667. בגודל של אזור התצוגה הזה, small.jpg ייבחר במכשירים אחד ו-medium.jpg יתאים בשני מכשירים.

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

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

למרבה המזל, כאן ניתן להשתמש ב-calc() — כל דפדפן עם תמיכה מובנית בתמונות רספונסיביות יתמוך גם ב-calc(), וכך נוכל לשלב יחידות CSS ולהתאים אותן - לדוגמה, תמונה שתופסת את כל רוחב אזור התצוגה של המשתמש, פחות שוליים של 1em מכל צד:

<img
    sizes="calc(100vw-2em)"
    srcset="small.jpg 400w, medium.jpg 800w, large.jpg 1600w, x-large.jpg 2400w"
    src="fallback.jpg"
    alt="...">

תיאור של נקודות עצירה (breakpoint)

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

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

  <img
     sizes="(min-width: 1200px) calc(80vw - 2em), 100vw"
     srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
     src="fallback.jpg"
     alt="...">

אם אזור התצוגה של המשתמש גדול מ-1200 פיקסלים, calc(80vw - 2em) מתאר את רוחב התמונה בפריסה שלנו. אם התנאי (min-width: 1200px) לא תואם, הדפדפן עובר לערך הבא. מכיוון שאין תנאי מדיה ספציפי שמקושר לערך הזה, 100vw משמש כברירת מחדל. אם כותבים את המאפיין sizes באמצעות max-width שאילתות מדיה:

  <img
     sizes="(max-width: 1200px) 100vw, calc(80vw - 2em)"
     srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
     src="fallback.jpg"
     alt="...">

בשפה פשוטה: "האם (max-width: 1200px) תואם? אם לא, ממשיכים. הערך הבא – calc(80vw - 2em) – לא כולל תנאי מתאים, ולכן זה הערך שנבחר.

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

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

השארת המילה האחרונה בדפדפן מאפשרת שיפורי ביצועים רבים בהרבה מאלה שהיינו יכולים לנהל באמצעות תחביר מכוון בלבד. לדוגמה: ברוב הדפדפנים, img עם התחביר srcset או sizes אף פעם לא יפריע לבקש מקור עם מימדים קטנים יותר מזה של המשתמש שכבר קיים במטמון הדפדפן. מה המטרה לשליחת בקשה חדשה למקור שייראה זהה, כשהדפדפן יוכל להוריד בקלות את קנה המידה של מקור התמונה שכבר יש לו? אבל אם המשתמש משנה את אזור התצוגה שלו עד למקום שבו צריך תמונה חדשה כדי למנוע התאמה לעומס (scaling), הבקשה הזו עדיין תתבצע, כך שהכול ייראה כמו שציפיתם.

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

שימוש ב-sizes וב-srcset

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

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

קצת יותר קשה לבצע אוטומציה של sizes. כידוע, הדרך היחידה שבה מערכת יכולה לחשב את גודל התמונה בפריסה מעובדת היא לעבד את הפריסה. למרבה המזל, צלחו מספר כלים למפתחים כדי לפשט את תהליך הכתיבה הידנית של מאפייני sizes - עם יעילות שאף פעם לא יכולת להתאים. לדוגמה, respImageLint הוא קטע קוד שמטרתו לבדוק את הדיוק של מאפייני sizes ולספק הצעות לשיפור. הפרויקט Lazysizes משפיע על המהירות של היעילות על ידי דחיית בקשות לתמונות עד אחרי יצירת הפריסה, וכך JavaScript יכול ליצור בשבילכם ערכי sizes. אם אתם משתמשים ב-framework לעיבוד נתונים בצד הלקוח, כמו React או Vue, יש כמה פתרונות ליצירה ו/או ליצירה של מאפייני srcset ו-sizes. עם זאת, נרחיב בנושא הזה במערכות ניהול תוכן ומסגרות.