Wie Google mit Ansichtsübergängen eine vernetzte Benutzeroberfläche für den neuen KI-Modus geschaffen hat

Jason Michelson

Bramus

Veröffentlicht: 28. August 2025

Die Google Suche hat eine der größten Reichweiten weltweit. Änderungen an der Benutzeroberfläche können sich daher auf Milliarden von Nutzern auswirken. Wir haben schon lange von einer Web-Erfahrung geträumt, die sich moderner und app-ähnlicher anfühlt. Als wir mit der Entwicklung des KI-Modus begannen, wollten wir eine Funktion für unsere Nutzer schaffen, bei der der Übergang von der Standardsuche in den KI-Modus nahtlos und verbunden ist. Als wir von Dokumentübergängen hörten, wussten wir, dass sie sich perfekt für die Funktion eignen. In dieser Fallstudie erfahren Sie, was wir beim Hinzufügen der Übergangsfunktion im Rahmen der Einführung des KI‑Modus gelernt haben.

Dokumentübergreifende Ansichtsübergänge sind ein echter Gamechanger für native Browser-Tools und wir sind gespannt, wie sie das Web in Zukunft prägen werden.

Den Status quo ändern

Für die Google Suche gelten strenge und konservative Anforderungen an die Browserunterstützung. Bisher war es nicht möglich, Funktionen mit eingeschränkter Verfügbarkeit zu nutzen. Bei Übergängen zwischen Dokumenten haben wir festgestellt, dass ein Polyfill nicht praktikabel ist. Der Hauptgrund dafür ist, dass es keine API zum Erstellen von Pixel-Snapshots gab und das Klonen des gesamten Viewports zu erheblichen Leistungsproblemen führte. Daher war die Verwendung der Funktion als progressive Erweiterung die beste Möglichkeit, sie zusammen mit dem KI-Modus einzuführen. Da die durch Ansichtsübergänge erstellten Animationen die Funktionalität der Website nicht direkt beeinträchtigen, werden sie bei nicht unterstütztem Traffic einfach deaktiviert. Das war auch schon der aktuelle Produktionsstatus ohne Übergangsanimationen.

Wir haben diese Strategie der progressiven Verbesserung zuerst mit unseren internen Nutzern getestet. So konnten wir frühzeitig Feedback erhalten, das überwiegend positiv war. Durch das Feedback wurden auch Fehler aufgedeckt, darunter Leistungsprobleme und unbeabsichtigte Interaktionen mit anderen Funktionen wie überlappenden Stapelkontexten.

Wir haben festgestellt, dass diese Strategie erfolgreich ist, und ich glaube, dass wir sie in Zukunft auch bei anderen neuen Browserfunktionen anwenden werden.

Schwierigkeiten, die aufgetreten sind, und wie wir sie gelöst haben

Latenz, Blockierung des Renderings und Watchdog-Timer

Insgesamt ist die zusätzliche Latenz, die mit MPA-Ansichtsübergängen einhergeht, für 99% der Anwendungsfälle vernachlässigbar, insbesondere auf moderner Hardware. Bei der Google Suche sind die Anforderungen an die Latenz jedoch extrem hoch. Wir sind bestrebt, Nutzererlebnisse zu schaffen, die auf allen Geräten gut funktionieren. Für uns zählen selbst wenige zusätzliche Millisekunden. Wir mussten also untersuchen, wie wir Übergänge zwischen Dokumenten richtig implementieren können, ohne die Nutzerfreundlichkeit zu beeinträchtigen.

Render Blocking ist eine Technik, die gut mit Übergängen zwischen Dokumenten funktioniert. In den Pseudo-Element-Snapshots des eingehenden Dokuments können nur Inhalte angezeigt werden, die bereits gerendert wurden. Wenn Sie also Inhalte aus dem eingehenden Dokument animieren möchten, müssen Sie den Block rendern, bis das zu animierende Zielelement gerendert wurde. Verwenden Sie dazu das Attribut blocking für ein HTMLLinkElement. Render-Blocking hat seine Nachteile, da das Warten auf ein Element, das sich im DOM-Baum des eingehenden Dokuments weiter unten befindet, zu einer erheblichen Latenz führen kann. Wir mussten diesen Kompromiss entsprechend abwägen und das Blockieren nur für Elemente rendern, die sehr früh im Seitenlebenszyklus gerendert werden.

<!-- Link tag in the <head> of the incoming document -->
<link blocking="render" href="#target-id" rel="expect">

<!-- Element you want to animate in the <body> of the incoming document -->
<div id="target-id">
  some content
</div>

In einigen Fällen reichte es nicht aus, genau anzugeben, für welches Element Sie den Block rendern möchten. Bei bestimmten Geräten oder Verbindungen kann es weiterhin zu zusätzlicher Latenz kommen, auch wenn das Rendern eines Elements in der Nähe des Anfangs des DOM-Baums blockiert wird. Für diese Fälle haben wir ein Watchdog-Timer-Script geschrieben, um das HTMLLinkElement nach einer bestimmten Zeit zu entfernen und so das Rendern des eingehenden Dokuments zu erzwingen.

So geht es ganz einfach:

function unblockRendering() {
  const renderBlockingElements = document.querySelectorAll(
    'link[blocking=render]',
  );
  for (const element of renderBlockingElements) {
    element.remove();
  }
}

const timeToUnblockRendering = t - performance.now();

if (timeToUnblockRendering > 0) {
  setTimeout(unblockRendering, timeToUnblockRendering);
} else {
  unblockRendering();
}

Einschränkungen der Abdeckung

Ein weiteres Problem, das wir festgestellt haben, ist, dass die Regel navigation: auto für Übergänge zwischen Dokumenten auf globaler Ebene innerhalb des Dokuments erfolgt. Es gibt keine integrierte Möglichkeit, die Aktivierung von Übergängen zwischen Dokumenten auf bestimmte Klickziele zu beschränken. Da es sich um eine so große Änderung handelt, konnten wir die Übergänge zwischen Dokumenten nicht für alle Navigationsvorgänge in der Google Suche aktivieren. Wir brauchten eine Möglichkeit, Übergänge zwischen Dokumenten dynamisch zu aktivieren oder zu deaktivieren, je nachdem, mit welcher Funktion der Nutzer interagierte. In unserem Fall haben wir sie nur für Modusänderungen in den und aus dem KI-Modus aktiviert. Dazu haben wir die Navigation programmatisch aktualisiert, je nachdem, auf welches Ziel geklickt oder getippt wurde.

So können Sie die @view-transition-Regel ein- und ausschalten:

let viewTransitionAtRule: HTMLElement | undefined;
const DISABLED_VIEW_TRANSITION = '@view-transition{navigation:none;}';
const ENABLED_VIEW_TRANSITION = '@view-transition{navigation:auto;}';

function getVtAtRule(): HTMLElement {
  if (!viewTransitionAtRule) {
    viewTransitionAtRule = document.createElement('style');
    document.head.append(viewTransitionAtRule);
  }
  return viewTransitionAtRule;
}

function disableVt() {
  getVtAtRule().textContent = DISABLED_VIEW_TRANSITION;
}

function enableVt() {
  getVtAtRule().textContent = ENABLED_VIEW_TRANSITION;
}

Verzögerung und zusammengesetzte Animationen

Einige der automatisch generierten Animationen für die Pseudoelemente für Ansichtsübergänge führten auf älteren Geräten zu Frame-Drops, was die reibungslose Nutzererfahrung beeinträchtigte, die wir Nutzern bieten möchten. Um die Leistung der Animationen zu verbessern, haben wir sie mit Animationstechniken neu geschrieben, die auf dem Compositor ausgeführt werden können. Dazu haben wir die Keyframes untersucht, um die Abmessungen der Pseudo-Elemente für den Snapshot vor und nach der Änderung zu ermitteln, und die Keyframes dann mithilfe von Matrixmathematik entsprechend neu geschrieben. Das folgende Beispiel zeigt, wie Sie die Animation für jedes Pseudo-Element für den Ansichtsübergang abrufen:

const pseudoElement = `::view-transition-group(${name})`;
const animation = document
  .getAnimations()
  .find(
    (animation) =>
      (animation.effect as KeyframeEffect)?.pseudoElement === pseudoElement,
  );

Weitere Informationen zum Schreiben von leistungsstarken Keyframes für Ansichtsübergänge finden Sie unter View Transitions Applied: Dealing with the Snapshot Containing Block.

Weitere wichtige Punkte

Eines der wichtigsten Probleme ist, dass sich das Tagging von Elementen mit der CSS-Eigenschaft view-transition-name auf den Stapelkontext auswirkt (View Transitions Specification: Section 2.1.1). Dies war die Quelle für mehrere Fehler, die eine Änderung der z-index von Containerelementen erforderten.

Außerdem sollten Sie nicht standardmäßig view-transition-name-Werte zu Elementen hinzufügen. Viele Menschen arbeiten an der Google Suche. Damit die view-transition-name-Werte, die unser Team für Elemente festlegt, nicht mit Werten anderer Teams in Konflikt geraten, haben wir Ansichtsübergangstypen verwendet, um die view-transition-name-Eigenschaft nur dann bedingt hinzuzufügen, wenn ein bestimmter Ansichtsübergangstyp aktiv ist.

Beispiel-CSS, um das view-transition-name von the-element nur dann einem Element hinzuzufügen, wenn der Ansichtsübergangstyp von ai-mode aktiv ist:

html:active-view-transition-type(ai-mode) {
  #target {
    view-transition-name: the-element;
  }
}

Sobald Sie diese CSS-Regeln für alle Ansichtsübergänge eingerichtet haben, können Sie den aktuellen Ansichtsübergangstyp für jede Navigation während der Ereignisse pageswap und pagereveal dynamisch ändern.

Beispiel für das Aktualisieren des Ansichtsübergangstyps auf ai-mode während des pageswap-Ereignisses.

function updateViewTransitionTypes(
  event: ViewTransitionEvent,
  types: string[],
): void {
  event.viewTransition.types.clear();
  for (const type of types) {
    event.viewTransition.types.add(type);
  }
}

window.addEventListener(
  'pageswap',
  (e) => {
    updateViewTransitionTypes(
      e as ViewTransitionEvent,
      ['ai-mode'],
    );
  }
);

So vermeiden wir Namenskonflikte und erstellen nicht unnötig Snapshots von Elementen, die beim Wechsel in den KI-Modus und zurück nicht aufgenommen werden müssen.

Schließlich treten Probleme mit dem Stacking-Kontext nur während des Ansichtsübergangs auf. Um diese Probleme zu beheben, können wir dann die Z-Indizes der generierten Pseudoelemente anvisieren, anstatt die Z-Indizes der ursprünglichen Elemente willkürlich zu ändern, nur um dieses Problem bei der Verwendung von Ansichtsübergängen zu beheben.

::view-transition-group(the-element) {
  z-index: 100;
}

Nächste Schritte

Wir planen, Dokumentübergreifende Übergänge für die Google Suche zu verwenden, einschließlich der Integration mit der Navigation API, sobald sie browserübergreifend verfügbar ist. Wir halten euch auf dem Laufenden, was wir als Nächstes entwickeln.