עדכונים חלקיים דקלרטיביים

Barry Pollard
Noam Rosenthal

פורסם: 19 במאי 2026, עדכון אחרון: 8 בספטמבר 2026

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

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

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

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

שתי קבוצות ה-API החדשות הראשונות מאפשרות להציג HTML בצורה פחות לינארית, בין אם מחוץ לסדר במסמך ה-HTML עצמו, או באמצעות דרכים קלות יותר להוסיף HTML באופן דינמי למסמכים קיימים באמצעות ממשקי JavaScript API חדשים. יש גם polyfills שמאפשרים לכם להשתמש בממשקי ה-API החדשים האלה באופן מיידי, גם בדפדפנים שעדיין לא תומכים בהם.

סטרימינג לא לפי הסדר

Browser Support

  • Chrome: 150.
  • Edge: 150.
  • Firefox: not supported.
  • Safari: not supported.

Source

השינויים הראשונים הם ממשקי API חדשים להזרמת נתונים לא לפי הסדר, שמשתמשים במחזיקי מקום של הוראות עיבוד ורכיב ה-HTML‏ <template> עם המאפיין for. לדוגמה:

<div>
  <?marker name="placeholder">
</div>

...

<template for="placeholder">
  Here is some <em>HTML content</em>!
</template>

הוראות עיבוד קיימות ב-XML כבר הרבה זמן, אבל הן נחשבות לתגובות ב-HTML והמערכת מתעלמת מהן. ה-API החדש משנה את זה ומביא הוראות עיבוד ל-HTML. לדוגמה, כשהדפדפן רואה את הוראת העיבוד <?marker name="placeholder">, הוא לא עושה שום דבר באופן מיידי – כמו קודם – אבל אפשר להתייחס אליה בהמשך.

הרכיב <template> עם המאפיין for מחפש את הוראות העיבוד התואמות עם המאפיין name ומחליף את התוכן. במקרה כזה, אחרי הניתוח, ה-DOM ייראה כך (תוך התעלמות מהבדלים מסוימים ברווחים הלבנים):

<div>
  Here is some <em>HTML content</em>!
</div>

בנוסף למאפיין <?marker> להחלפות, יש גם סמני טווח <?start> ו-<?end> שמאפשרים להציג תוכן זמני של placeholder לפני שהתבנית עוברת עיבוד:

<div>
  <?start name="another-placeholder">
  Loading…
  <?end>
</div>

...

<template for="another-placeholder">
  Here is some <em>HTML content</em>!
</template>

במקרה כזה, מחרוזת Loading… מוצגת עד שרואים את <template>, ואז היא מוחלפת בתוכן החדש.

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

<ul id="results">
  <?start name="results">
  Loading…
  <?end>
</ul>

...

<template for="results">
  <li>Result One</li>
  <?marker name="results">
</template>

...

<template for="results">
  <li>Result Two</li>
  <?marker name="results">
</template>

...

אחרי הניתוח והעיבוד, קוד ה-HTML שמתקבל הוא:

<ul id="results">
  <li>Result One</li>
  <li>Result Two</li>
  <?marker name="results">
</ul>

ההוראה הסופית לעיבוד מופיעה בסוף, למקרה שיוסיפו עוד placeholders של <template for="results"> למסמך בהמשך.

למה הוראות עיבוד במקום רכיבי HTML רגילים?

זו שאלה נפוצה בקרב משתמשים שמתחילים להשתמש ב-API הזה, ויש הצעות להשתמש ברכיבי <slot> או אפילו <template> עצמם. גרסה ראשונית של ההצעה הזו פעלה עם רכיבי HTML רגילים, אבל הוראות העיבוד הוחלפו כשהעיצוב עבר איטרציה. הוראות העיבוד מאפשרות לבצע תיקון בלי להשפיע על ה-DOM. המאפיין הזה מאפשר להשתמש ב-<head> – למשל, לעדכונים של <title> – או אפילו בתוך רכיבים אחרים כמו <table> (כדי להוסיף שורות נוספות אופציונליות, למשל).

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

הדגמה (דמו)

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

הדגמה של אלבום תמונות שהוטמעה באמצעות סטרימינג לא מסודר (מקור)

גם הסטטוס וגם התמונות מוזרמים ל-HTML אחרי הפריסה הראשונית.

תרחישים לדוגמה

יש הרבה תרחישי שימוש לתיקון HTML לא מסודר בשילוב עם HTML בהזרמה:

  • ארכיטקטורת איים. תבנית נפוצה שהפכה לפופולרית בזכות מסגרות כמו Astro היא ארכיטקטורת האיים, שבה הרכיבים עוברים הידרציה באופן עצמאי על גבי HTML סטטי. ‫<template for> API מאפשר לטפל בתוכן סטטי באופן דומה ישירות ב-HTML. אפשר להשתמש בזה גם ב-JavaScript frameworks כדי ליצור איים אינטראקטיביים יותר או כדי לטפל ברכיבים.
  • העברת תוכן כשהוא מוכן. בזכות ארכיטקטורת האיים הזו, אפשר להזרים תוכן כשהוא מוכן, במקום לעכב אותו בגלל תוכן שדורש עיבוד נוסף – לדוגמה, חיפוש במסד נתונים. הרבה פלטפורמות מאפשרות סטרימינג של HTML, אבל בגלל האופי של HTML, התוכן לרוב מושהה או שנעשה שימוש במניפולציות מורכבות של JavaScript DOM. עכשיו אפשר להציג את התוכן הסטטי בזמן ההמתנה, ואז להוסיף תוכן יקר יותר ודינמי בסוף שידור ה-HTML.
  • אפשר להציג את ה-HTML בסדר האופטימלי לביצועי טעינת הדף. אפשר גם לשנות את הסדר אחרי שהסרטון מוכן. לדוגמה, תפריטים מורחבים הם תכונת ניווט נפוצה שמכילה הרבה קוד HTML שהמשתמש לא יראה עד שהדף יהפוך לאינטראקטיבי. אפשר להעביר את החלק הגדול הזה של ה-HTML לחלק מאוחר יותר במסמך ה-HTML, כדי לתת עדיפות ל-HTML חשוב יותר שנדרש לטעינת דף הראשונית. הזמנה כבר לא מהווה מחסום עם HTML.

אלה רק כמה תרחישי שימוש, ואנחנו נרגשים לראות למה מפתחים ישתמשו ב-API החדש הזה.

הגבלות וניואנסים

יש כמה מגבלות וניואנסים שחשוב להכיר לגבי ה-API:

  • מטעמי אבטחה, <template for> יכול לעדכן הוראות עיבוד רק באותו רכיב אב. הוספת <template for> ישירות לרכיב <body> נותנת לו גישה לכל המסמך (כולל <head>).
  • הוראת העיבוד <?end> היא אופציונלית, ואם היא לא מופיעה, התוכן שבין הרכיב <?start> לסוף הרכיב המכיל יוחלף.
  • העברת הוראות עיבוד אחרי שסטרימינג של <template for> התחיל יכולה גם להוביל לתוצאות לא צפויות, כשהתוכן החדש ממשיך להיות בסטרימינג למיקום הישן.
  • שימו לב: כשמכניסים את <template for> באופן דינמי באמצעות שיטה כמו setHTML או המאפיין innerHTML, ה'הורה' של התבנית בזמן הניתוח הוא קטע מסמך ביניים. כלומר, אי אפשר לשנות DOM קיים באמצעות הוספת HTML בשיטות האלה, והתיקון מתבצע 'במקום' בתוך הפריט. עם זאת, כשמבצעים סטרימינג באמצעות שיטות כמו streamHTMLUnsafe (שנפרט עליהן בהמשך), אין פרגמנט ביניים, ולכן התבניות יכולות להחליף תוכן קיים.

סטטוס התקנון

המאפיין <template for> הוא חלק מתקן ה-HTML, אבל הוא עדיין לא נתמך בכל הדפדפנים.

תוספות פוטנציאליות בעתיד

הנה כמה תוספות פוטנציאליות שאנחנו שוקלים להוסיף בעתיד:

  • הוספות בצד הלקוח. לדוגמה, <template for="footer" src="/partials/footer.html"> או אפילו בלי תיקון <template src="/partials/footer.html">. מידע נוסף זמין במאמר ההסבר. האפשרות הזו זמינה מאחורי הדגל chrome://flags/#enable-experimental-web-platform-features.
  • מניעת החלפה של תוכן שלא ישתנה. אפשר לעשות את זה באמצעות מספר תיקון תוכן או ניהול גרסאות. כך אפשר לשמור על מצב האפליקציה בין שינויים במסלולים או עדכונים אחרים, במקום לאפס את התוכן.
  • ניקוי בזמן תיקון. לדוגמה, <template for=icon safe><svg id="from-untrusted-source">...</svg></template>.

פוליפיל

צוות Chrome פרסם template-for-polyfill שזמין ב-npm כדי לאפשר לאתרים להשתמש בפונקציונליות החדשה הזו באופן מיידי, עוד לפני שהיא תוטמע בדפדפנים אחרים.

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

שיטות חדשות להוספת HTML ולהעברה בסטרימינג

לא ניתן להעביר את כל התוכן כ-HTML. חלק נוסף בעבודה ש-Chrome ביצע בתחום הזה נועד להקל על עדכון תוכן באמצעות JavaScript.

כבר יש כמה דרכים להוסיף באופן דינמי HTML למסמך קיים באמצעות JavaScript:

  • setHTML
  • setHTMLUnsafe
  • innerHTML וגם outerHTML
  • createContextualFragment
  • insertAdjacentHTML

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

  • האם התוכן החדש מחליף את התוכן הקיים או מתווסף אליו?
  • האם הם מבצעים סניטציה של קוד HTML שעלול להיות מסוכן – לדוגמה, על ידי ביטול התגים <script>?
  • אם לא, האם צריך להריץ את <script>?
  • איך הם פועלים עם סוגים מהימנים?

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

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

קבוצה חדשה של ממשקי API סטטיים ושל סטרימינג

Browser Support

  • Chrome: behind a flag.
  • Edge: behind a flag.
  • Firefox: not supported.
  • Safari: not supported.

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

התכונות האלה מוכנות לבדיקות של מפתחים מגרסה Chrome 148 באמצעות התכונה הניסיונית chrome://flags/#enable-experimental-web-platform-features, והן צפויות להיות זמינות בגרסה Chrome 155.

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

פעולה סטטי סטרימינג
הגדרת תוכן ה-HTML של הרכיב setHTML(html, options); streamHTML(options);
החלפת הרכיב כולו ב-HTML הזה replaceWithHTML(html, options); streamReplaceWithHTML(options);
מוסיפים את ה-HTML לפני הרכיב beforeHTML(html, options); streamBeforeHTML(options);
מוסיפים את ה-HTML כרכיב המשני הראשון של הרכיב prependHTML(html, options); streamPrependHTML(options);
מוסיפים את ה-HTML כרכיב המשני האחרון של הרכיב appendHTML(html, options); streamAppendHTML(options);
הוספת ה-HTML אחרי הרכיב afterHTML(html, options); streamAfterHTML(options);
השיטות החדשות להוספה ולסטרימינג

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

הגרסאות הסטטיות מקבלות HTML חדש כארגומנט DOM String, יחד עם אפשרויות אופציונליות:

const newHTML = "<p>This is a new paragraph</p>";
const contentElement = document.querySelector('#content-to-update');

contentElement.setHTML(newHTML);

הגרסאות של הסטרימינג פועלות עם Streams API, למשל עם getWriter():

const contentElement = document.querySelector('#content-to-update');
const writer = contentElement.streamHTMLUnsafe().getWriter();

// Example stream of updating content
while (true) {
  await writer.write(`<p>${++i}</p>`);
  await new Promise((resolve) => setTimeout(resolve, 1000));
}

writer.close();

או לחלופין, מתשובה של אחזור באמצעות שרשראות של צינורות:

const contentElement = document.querySelector('#content-to-update');
const response = await fetch('/api/content.html');

response.body
  .pipeThrough(new TextDecoderStream())
  .pipeTo(contentElement.streamHTMLUnsafe());

textStream() אמצעי תשלום נוח

Browser Support

  • Chrome: 151.
  • Edge: 151.
  • Firefox: not supported.
  • Safari: not supported.

נוספה גם textStream שיטת נוחות שמאפשרת צפייה ישירה בסטרימינג בלי הצורך בשלב הביניים TextDecoderStream():

const contentElement = document.querySelector('#content-to-update');
const response = await fetch('/api/content.html');

response.textStream().pipeTo(contentElement.streamHTMLUnsafe());

options

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

const newHTML = '<p>This is a new paragraph</p>';
const contentElement = document.querySelector('#content-to-update');

// Only allows basic formatting
const basicFormattingSanitzer = new Sanitizer({ elements: ['em', 'i', 'b', 'strong'] });

contentElement.setHTML(newHTML, {sanitizer: basicFormattingSanitzer});

שיטות 'לא בטוחות'

יש גם גרסאות 'לא בטוחות' של כל אחד מממשקי ה-API:

פעולה סטטי סטרימינג
הגדרת תוכן ה-HTML של הרכיב setHTMLUnsafe(html,options); streamHTMLUnsafe(options);
החלפת הרכיב כולו ב-HTML הזה replaceWithHTMLUnsafe(html, options); streamReplaceWithHTMLUnsafe(options);
מוסיפים את ה-HTML לפני הרכיב beforeHTMLUnsafe(html, options); streamBeforeHTMLUnsafe(options);
מוסיפים את ה-HTML כרכיב המשני הראשון של הרכיב prependHTMLUnsafe(html, options); streamPrependHTMLUnsafe(options);
מוסיפים את ה-HTML כרכיב המשני האחרון של הרכיב appendHTMLUnsafe(html, options); streamAppendHTMLUnsafe(options);
הוספת ה-HTML אחרי הרכיב afterHTMLUnsafe(html, options); streamAfterHTMLUnsafe(options);
שיטות ההוספה והסטרימינג 'לא בטוחות'

השיטות האלה נחשבות ל "לא בטוחות" כי הן משביתות את אמצעי החיטוי כברירת מחדל, ואם רוצים אפשר לציין אמצעי חיטוי מותאם אישית. ה-methods האלה מאפשרות גם להריץ סקריפטים עם אפשרות runScripts אופציונלית – שמוגדרת כברירת מחדל ל-false.

בדומה ל-setHTML, ‏ setHTMLUnsafe היא שיטה קיימת, אבל נוסף לה פרמטר האפשרויות runScripts כדי לאפשר שימוש בה עם הפעלת סקריפט:

const newHTML = `<p>This is a new paragraph</p>
                 <script src=script.js></script>`;
const contentElement = document.querySelector('#content-to-update');

contentElement.setHTMLUnsafe(newHTML, {runScripts: true});

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

המידה שבה הפעולה הזו לא בטוחה תלויה במידת המהימנות של נתוני הקלט. כל השיטות הסטטיות של Unsafe פועלות עם DOM String או עם TrustedHTML כארגומנטים של html, ומאפשרות גם להשתמש ב-sanitizers. עם זאת, ב-runScript המטרה היא לאפשר סקריפטים, ולכן כברירת מחדל לא נעשה שימוש בחיטוי.

תרחישים לדוגמה

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

תרחישים לדוגמה:

  • סטרימינג דינמי של עדכוני תוכן גדולים באפליקציות בדף יחיד. כמו שציינו קודם, חיסרון משמעותי בארכיטקטורת SPA הנוכחית הוא שהיא לא נהנית מהטבע הסטרימינג של טעינות HTML ראשוניות – עד עכשיו!
  • הוספת תוכן נפוץ כמו כותרות תחתונות ב-HTML. השימוש ב-JavaScript APIs מאפשר לכם לשלוף חלקים ולהוסיף אותם לדף, וליהנות מהיתרונות של שמירה במטמון, במקום לחזור עליהם בכל דף שנשלח. עם זאת, בהתחשב בתלות ב-JavaScript להפעלה, צריך להשתמש בשיטה הזו רק לתוכן שלא יוצג בטעינה הראשונית.

שוב, אלה רק כמה דוגמאות, ואנחנו מחכים לראות מה תצליחו ליצור!

הגבלות וניואנסים

בנוסף, יש כמה הגבלות וניואנסים שחשוב להכיר לגבי ממשקי ה-API החדשים:

  • כדי לשלב סטרימינג עם Trusted Types API, צריך להשתמש ב-method חדש של createParserOptions שמאפשר להוסיף אמצעי חיטוי לכל פעולת הגדרת HTML. מידע נוסף על שילוב סוגים מהימנים
  • בדומה ל-<template for>, הזזה של רכיבים שמוזרמים לתוך המסך עלולה ליצור השלכות לא צפויות או שגיאות בהזרמה.
  • ‫streamHTMLUnsafe פועל בדומה לניתוח התחביר הראשי בהרבה מובנים, כולל עיבוד ההוראות של <template for> כשהן מתווספות למסמך הראשי, ודחיית הסקריפטים של defer עד לסוף הזרם.

סטטוס התקנון

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

פוליפיל

צוות Chrome פרסם html-setters-polyfill שזמין ב-npm כדי לאפשר לאתרים להשתמש בפונקציונליות החדשה הזו באופן מיידי, עוד לפני שהיא תוטמע בדפדפנים אחרים.

שימו לב: ה-polyfill הזה לא מזרים נתונים, אלא מאגר אותם ומחיל אותם כשהוא מסתיים. הוא יותר polyfill לצורת ה-API מאשר לפונקציונליות.

בנוסף, הגדרת התוכן הבטוח תלויה ב-setHTML וב-Sanitizer API, שלא נתמך ב-Safari.

אפשר להשתמש בשתי האפשרויות האלה ביחד

אלה שני ממשקי API נפרדים, אבל העוצמה האמיתית שלהם מתגלה כשמשלבים ביניהם. על ידי הזרמת רכיבי <template for> חדשים ל-HTML, אפשר לעדכן באופן דינמי חלקים שונים של התוכן בלי לטרגט כל אחד מהם ישירות באמצעות הפניות נפרדות של JavaScript ל-DOM.

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

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

יש עוד כמה ממשקי API ש-Chrome עובד עליהם במסגרת הפרויקט Declarative Partial Updates, אבל אנחנו שמחים להעביר לידיכם את שני ממשקי ה-API הראשונים האלה. נעדכן אתכם כשיהיו עוד אפשרויות בתחום הזה.