תחביר תיאורי

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

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

תיאור הצפיפות עם x

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

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

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

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

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

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

כדי למנוע את ההתאמה הזו, התמונה שמעובדת צריכה להיות ברוחב פנימי של 800 פיקסלים לפחות. עם הגדלה לעומס (scaling) כדי להתאים שטח לפריסה ברוחב של 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 - פעמים רבות, עוד לפני שתגי העיצוב נותחו במלואם. כשהדפדפן מבצע בקשות כאלה, אין לו מידע על הדף עצמו, חוץ מתגי העיצוב — יכול להיות שהוא לא שלח בקשות בכלל. עדיין עבור גיליונות סגנונות חיצוניים, ובעיקר להחלתם. בשעה שבה הדפדפן מנתח את תגי העיצוב ומתחיל ליצור קבצים חיצוניים בקשות, יש בו מידע רק ברמת הדפדפן: גודל אזור התצוגה של המשתמש, דחיסות הפיקסלים של תצוגת המשתמש, העדפות המשתמש וכו'.

זה לא אומר שום דבר על האופן שבו תמונה אמורה להיות מעובדת בפריסת הדף — היא אפילו לא יכולה להשתמש באזור התצוגה. כשרת Proxy לגבול העליון של הגודל 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=.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 היא 480 פיקסלים. כשאנחנו מחלקים את המקורות שלנו עם רוחב פס זה, אנחנו מקבלים 1.25, 2.5 ו-4.1666666667. בגודל אזור התצוגה הזה, הגודל small.jpg ייבחר ב-1x מכשירים, ו-medium.jpg יתאים ב-2x מכשירים.

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

הערך של 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, שירות Bundler כמו Webpack, צד שלישי CDN כמו Cloudinary, או פונקציונליות שכבר מובנית במערכת ניהול התוכן שבחרתם. כשיש מספיק מידע כדי ליצור את המקורות שלנו מלכתחילה, למערכת יהיו מספיק מידע כדי לכתוב אותם במאפיין srcset מעשי.

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