דף זה תורגם על ידי Cloud Translation API.

בניית רכיב תמונה יעיל

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

Leena Sohoni

Kara Erickson

Alex Castle

תמונות הן מקור נפוץ לצווארי בקבוק בביצועים של אפליקציות אינטרנט, וזהו מוקד עיקרי לאופטימיזציה. תמונות שלא בוצעה בהן אופטימיזציה תורמות להגדלת נפח הדף ומהוות יותר מ-70% ממשקל הדף הכולל ביחידות ביייט ב-90^th הרבעון. יש כמה דרכים לבצע אופטימיזציה של תמונות, ולכן צריך 'רכיב תמונה' חכם עם פתרונות ביצועים מובנים כברירת מחדל.

צוות Aurora עבד עם Next.js כדי ליצור רכיב כזה. המטרה הייתה ליצור תבנית תמונה אופטימיזציה שמפתחי אתרים יוכלו להתאים אישית עוד יותר. הרכיב משמש כמודל טוב ומגדיר סטנדרט לבניית רכיבי תמונה במסגרות אחרות, במערכות ניהול תוכן (CMS) ובסטאקים טכנולוגיים. עבדנו בשיתוף על רכיב דומה של Nuxt.js,ואנחנו עובדים עם Angular על אופטימיזציה של תמונות בגרסאות עתידיות. בפוסט הזה נסביר איך תכננו את הרכיב Image ב-Next.js ואת הלקחים שלמדנו לאורך הדרך.

רכיב תמונה כתוספי תמונות

בעיות והזדמנויות לאופטימיזציה של תמונות

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

תמונות לא גדולות פוגעות ב-CLS

אם מוצגות תמונות בלי גודל הקובץ שצוין, הן עלולות לגרום לאי-יציבות בפריסה ולגרום לשינויים גבוהים של הפריסה (CLS). הגדרת המאפיינים width ו-height באלמנטים img יכולה לעזור למנוע שינויי פריסה. לדוגמה:

<img src="flower.jpg" width="360" height="240">

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

תמונות גדולות עלולות לפגוע ב-LCP

ככל שגודל הקובץ של התמונה גדול יותר, כך זמן ההורדה ארוך יותר. תמונה גדולה יכולה להיות התמונה הראשית (Hero) של הדף או הרכיב המשמעותי ביותר באזור התצוגה שאחראי להפעלת ה-LCP (LCP). תמונה שהיא חלק מהתוכן החיוני ופעולת ההורדה שלה נמשכת זמן רב תעכב את זמן ה-LCP.

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

דחיסת תמונות ירודה עלולה לפגוע ב-LCP

פורמטים מודרניים של תמונות, כמו AVIF או WebP, מספקים דחיסת נתונים טובה יותר מאשר הפורמטים הנפוצים של JPEG ו-PNG. דחיסת קובץ טובה יותר מפחיתה את גודל הקובץ ב-25% עד 50% במקרים מסוימים, בלי לפגוע באיכות התמונה. הפחתת הנתונים מובילה להורדות מהירות יותר עם צריכת נתונים נמוכה יותר. האפליקציה צריכה להציג פורמטים מודרניים של תמונות בדפדפנים שתומכים בפורמטים האלה.

טעינת תמונות מיותרות פוגעת ב-LCP

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

אתגרי אופטימיזציה

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

עדיפויות: מפתחי אתרים בדרך כלל מתמקדים בקוד, ב-JavaScript ובאופטימיזציה של נתונים. לכן, יכול להיות שהם לא מודעים לבעיות בתמונות או לאופן שבו אפשר לבצע אופטימיזציה שלהן. יכול להיות שתמונות שנוצרו על ידי מעצבים או שהועלו על ידי משתמשים לא יופיעו בראש רשימת העדיפויות.
פתרון חדשני: גם אם המפתחים מודעים לניואנסים של אופטימיזציה של תמונות, היעדר פתרון כולל וייחודי ל-framework או לסטאק התוכנות שלהם יכול להרתיע.
תמונות דינמיות: בנוסף לתמונות סטטיות שנכללות באפליקציה, משתמשים מעלים תמונות דינמיות או שהן מגיעות ממקורות חיצוניים כמו מסדי נתונים או מערכות ניהול תוכן (CMS). יכול להיות שיהיה קשה להגדיר את הגודל של תמונות כאלה שבהן מקור התמונה הוא דינמי.
עומס סימון: פתרונות שכוללים את גודל התמונה או את srcset בגדלים שונים דורשים סימון נוסף לכל תמונה, וזה יכול להיות מייגע. המאפיין srcset נוסף לשימוש בשנת 2014, אבל נעשה בו שימוש רק ב-26.5% מהאתרים כיום. כשמשתמשים ב-srcset, המפתחים צריכים ליצור תמונות בגדלים שונים. כלים כמו just-gimme-an-img יכולים לעזור, אבל צריך להשתמש בהם באופן ידני בכל תמונה.
תמיכה בדפדפנים: פורמטים מודרניים של תמונות כמו AVIF ו-WebP יוצרים קובצי תמונות קטנים יותר, אבל צריך לטפל בהם באופן מיוחד בדפדפנים שלא תומכים בהם. המפתחים צריכים להשתמש באסטרטגיות כמו ניהול משא ומתן על תוכן או באלמנט <picture> כדי שהתמונות יוצגו בכל הדפדפנים.
בעיות בחירת שיטת טעינת נתונים באיטרציות: יש כמה שיטות וספריות שאפשר להשתמש בהן כדי להטמיע טעינת נתונים באיטרציות לתמונות שמתחת ל'קפל'. לבחור את הדרך הכי טובה יכולה להיות אתגר. בנוסף, ייתכן שהמפתחים לא יודעים מה המרחק הטוב ביותר בין החלק "קיפול" לבין טעינת תמונות שנדחו. אם יש אזור תצוגה בגדלים שונים במכשירים, זה עלול לסבך עוד יותר.
הסביבה משתנה: הדפדפנים מתחילים לתמוך בתכונות חדשות של HTML או CSS כדי לשפר את הביצועים, ויכול להיות שיהיה קשה למפתחים להעריך כל אחת מהן. לדוגמה, ב-Chrome משיקים את התכונה Fetch Priority כגרסת מקור לניסיון. אפשר להשתמש בה כדי לשפר את העדיפות של תמונות ספציפיות בדף. באופן כללי, למפתחים יהיה קל יותר אם השיפורים האלה ייבדקו ויושמו ברמת הרכיב.

רכיב תמונה כפתרון

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

בשנה האחרונה עבדנו עם ה-framework של Next.js כדי לעצב ולהטמיע את רכיב התמונה שלהם. אפשר להשתמש בו כתחליף לרכיבי <img> הקיימים באפליקציות Next.js באופן הבא.

// Before with <img> element:
function Logo() {
  return <img src="/logo.jpg" alt="logo" height="200" width="100" />
}

// After with image component:
import Image from 'next/image'

function Logo() {
  return <Image src="/logo.jpg" alt="logo" height="200" width="100" />
}

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

הגנה מפני שינויי פריסה

כפי שצוין קודם, תמונות ללא הגדרת גודל גורמות לשינויים בפריסה ומגדילות את ה-CLS. כשמשתמשים ברכיב התמונה Next.js, המפתחים חייבים לספק גודל תמונה באמצעות המאפיינים width ו-height כדי למנוע שינויים בפריסה. אם הגודל לא ידוע, המפתחים צריכים לציין את הסמל layout=fill כדי להציג תמונה לא גדולה שנמצאת בתוך קונטיינר בגודל. לחלופין, אפשר להשתמש בייבוא של תמונות סטטיות כדי לאחזר את גודל התמונה עצמה בכונן הקשיח בזמן ה-build ולכלול אותה בתמונה.

// Image component with width and height specified
<Image src="/logo.jpg" alt="logo" height="200" width="100" />

// Image component with layout specified
<Image src="/hero.jpg" layout="fill" objectFit="cover" alt="hero" />

// Image component with image import
import Image from 'next/image'
import logo from './logo.png'

function Logo() {
  return <Image src={logo} alt="logo" />
}

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

שיפור הרספונסיביות

כדי שהתמונות יהיו רספונסיביות בכל המכשירים, המפתחים צריכים להגדיר את המאפיינים srcset ו-sizes ברכיב <img>. רצינו לצמצם את המאמץ הזה באמצעות רכיב התמונה. ברכיב התמונה Next.js תכננו את הגדרת ערכי המאפיינים רק פעם אחת לכל אפליקציה. אנחנו מחילים אותן על כל המופעים של רכיב התמונה על סמך אופן הפריסה. פיתחנו פתרון בן שלושה חלקים:

נכס deviceSizes: אפשר להשתמש בנכס הזה כדי להגדיר נקודות עצירה חד-פעמיות על סמך המכשירים הנפוצים בקרב בסיס המשתמשים של האפליקציה. ערכי ברירת המחדל של נקודות העצירה כלולים בקובץ התצורה.
המאפיין imageSizes: זהו גם מאפיין שניתן להגדרה, שמשמשים לקבלת גודלי התמונות התואמים לנקודות המעבר של גודל המכשיר.
המאפיין layout בכל תמונה: משמש כדי לציין איך להשתמש במאפיינים deviceSizes ו-imageSizes בכל תמונה. הערכים הנתמכים של 'מצב פריסה' הם fixed, ‏ fill, ‏ intrinsic ו-responsive

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

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

תמונות שעברן רינדור לפריסות שונות
מסך של מחשב נייד	מסך הטלפון
Layout = Intrinsic: התמונה תתכוונן לרוחב של המיכל באזורי תצוגה קטנים יותר. לא הגדלה מעבר לגודל המהותי של התמונה באזור תצוגה גדול יותר. רוחב המכל הוא 100%

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

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

פריסה = מילוי: רוחב וגובה מורחבים כדי למלא את מאגר האב. (הרוחב של הורה `<div>` מוגדר כ-300*500 בדוגמה הזו)

טעינה מדורגת מובנית

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

מציינים את המאפיין loading: נתמך בכל הדפדפנים המתקדמים.
שימוש ב-Intersection Observer API: פיתוח פתרון מותאם אישית של טעינת פריטים בזמן אמת (lazy loading) דורש מאמץ ותכנון והטמעה מוקפדים. יכול להיות שלמפתחים לא תמיד יהיה זמן לעשות זאת.
ייבוא ספרייה של צד שלישי כדי לטעון תמונות באיטרציה: יכול להיות שתצטרכו להשקיע מאמץ נוסף כדי להעריך ולשלב ספרייה מתאימה של צד שלישי לטעינה באיטרציה.

ברכיב Image של Next.js, הטעינה מוגדרת ל-"lazy" כברירת מחדל. טעינת הנכסים באיטרציות מיושמת באמצעות Intersection Observer, שזמין ברוב הדפדפנים המודרניים. המפתחים לא צריכים לעשות שום דבר נוסף כדי להפעיל אותה, אבל הם יכולים להשבית אותה לפי הצורך.

טעינה מראש של תמונות חשובות

לרוב, רכיבי LCP הם תמונות, ותמונות גדולות עלולות לעכב את ה-LCP. מומלץ לטעון מראש תמונות קריטיות כדי שהדפדפן יוכל לזהות את התמונה הזו מוקדם יותר. כשמשתמשים ברכיב <img>, אפשר לכלול רמז לטעינת נתונים מראש בכותרת ה-HTML באופן הבא.

<link rel="preload" as="image" href="important.png">

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

<Image src="/hero.jpg" alt="hero" height="400" width="200" priority />

הוספת מאפיין priority מפשטת את ה-Markup והשימוש בו נוח יותר. מפתחים של רכיבי תמונות יכולים גם לבדוק אפשרויות להחיל שיטות ניתוח נתונים (heuristics) כדי לבצע טעינת נתונים מראש באופן אוטומטי של תמונות שמופיעות בחלק העליון של הדף ועומדות בקריטריונים ספציפיים.

מעודדים אירוח תמונות שמניבות ביצועים טובים

מומלץ להשתמש ב-CDN לתמונות כדי לבצע אופטימיזציה של תמונות באופן אוטומטי. בנוסף, הם תומכים בפורמטים מודרניים של תמונות כמו WebP ו-AVIF. רכיב התמונה של Next.js משתמש ב-CDN של תמונות כברירת מחדל באמצעות ארכיטקטורת מעבד. בדוגמה הבאה מוצג שהמטען מאפשר להגדיר את ה-CDN בקובץ התצורה של Next.js.

module.exports = {
  images: {
    loader: 'imgix',
    path: 'https://ImgApp/imgix.net',
  },
}

בתצורה הזו, המפתחים יכולים להשתמש בכתובות URL יחסיות במקור התמונה, והמסגרת תקשר את כתובת ה-URL היחסית עם נתיב ה-CDN כדי ליצור את כתובת ה-URL המוחלטת. יש תמיכה ב-CDNs פופולריים של תמונות כמו Imgix,‏ Cloudinary ו-Akamai. הארכיטקטורה תומכת בשימוש בספק ענן מותאם אישית באמצעות הטמעה של פונקציית loader בהתאמה אישית לאפליקציה.

תמיכה בתמונות באירוח עצמי

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

תמיכה בטעינה פרוגרסיבית

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

רכיב התמונה ב-Next.js תומך בעומס הדרגתי של התמונה באמצעות הנכס placeholder. אפשר להשתמש ב-LQIP (Placeholder של תמונה באיכות נמוכה) כדי להציג תמונה מטושטשת או באיכות נמוכה בזמן שהתמונה בפועל נטענת.

השפעה

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

כשLeboncoin העבירו את ממשק הקצה הקודם שלהם ב-JavaScript ל-Next.js, הם שדרגו גם את צינור עיבוד הנתונים של התמונות שלהם כך שישתמש ברכיב התמונה של Next.js. בדף שהועבר מ-<img> לתמונה הבאה/לתמונה, מדד LCP ירד מ-2.4 שניות ל-1.7 שניות. מספר הבייטים הכולל של התמונות שהורדו בדף ירד מ-663KB ל-326KB (עם כ-100KB של בייטים של תמונות שנטענו באיטרציה).

לקחים

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

שסתומי בטיחות יכולים לגרום נזק גדול יותר מאשר טוב

בגרסה מוקדמת של רכיב התמונה Next.js, הוספנו מאפיין unsized שמאפשר למפתחים לעקוף את דרישת הגודל, ולהשתמש בתמונות עם מידות שלא צוינו. חשבנו שזה יהיה הכרחי במקרים שבהם לא ניתן היה לדעת מראש את הגובה או הרוחב של התמונה. עם זאת, שמנו לב שמשתמשים ממליצים על המאפיין unsized בבעיות ב-GitHub כפתרון כללי לבעיות שקשורות לדרישה לגבי הגודל, גם במקרים שבהם הם יכלו לפתור את הבעיה בדרכים שלא החמירו את מדד CLS. לאחר מכן הוצאנו משימוש את המאפיין unsized והסרנו אותו.

הפרדה בין התנגדויות מועילות לבין התנגדויות מיותרות

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

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

איזון בין תכונות הנוחות לבין אופטימיזציה של ביצועים

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

הגדרת תוכנית עבודה לתכונות כדי לעודד את השימוש בהן

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

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

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

סיכום

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

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

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