इस पेज का अनुवाद Cloud Translation API से किया गया है.

केस स्टडी: Google ने व्यू ट्रांज़िशन का इस्तेमाल करके, अपने नए एआई मोड के लिए कनेक्टेड अनुभव कैसे बनाया

Jason Michelson

Bramus

पब्लिश किया गया: 28 अगस्त, 2025

Google Search का इस्तेमाल दुनिया भर में सबसे ज़्यादा किया जाता है. इसलिए, उपयोगकर्ता अनुभव में किए गए बदलावों का असर अरबों लोगों पर पड़ सकता है. हम लंबे समय से, वेब पर ऐसा अनुभव देने का सपना देख रहे थे जो ज़्यादा मॉर्डन हो और ऐप्लिकेशन जैसा लगे. एआई मोड पर काम शुरू करते समय, हमारा मकसद उपयोगकर्ताओं को ऐसा अनुभव देना था जिसमें स्टैंडर्ड सर्च से एआई मोड पर स्विच करना आसान हो और दोनों मोड एक-दूसरे से जुड़े हुए लगें. जब हमें क्रॉस-डॉक्यूमेंट व्यू ट्रांज़िशन के बारे में पता चला, तो हमें लगा कि यह सुविधा के लिए सबसे सही है. इस केस स्टडी में बताया गया है कि एआई मोड लॉन्च करने के साथ-साथ ट्रांज़िशन की सुविधा जोड़ने से हमें क्या सीखने को मिला.

Google Search पर की गई खोज की रिकॉर्डिंग. इसमें खोज के नतीजों से एआई मोड पर स्विच करना दिखाया गया है. ट्रांज़िशन में व्यू ट्रांज़िशन का इस्तेमाल किया जा रहा है.

नेटिव ब्राउज़र टूलिंग के मामले में, क्रॉस-डॉक्यूमेंट व्यू ट्रांज़िशन एक गेम चेंजर है. हम यह देखने के लिए उत्साहित हैं कि आने वाले समय में यह वेब को कैसे आकार देगा.

Browser Support

Source

मौजूदा स्थिति में बदलाव करना

Google Search के लिए, ब्राउज़र से जुड़ी ज़रूरी शर्तें सख्त हैं. आम तौर पर, सीमित तौर पर उपलब्ध सुविधा का इस्तेमाल नहीं किया जा सकता. हमने पाया कि अलग-अलग दस्तावेज़ों के बीच व्यू ट्रांज़िशन के लिए, पॉलीफ़िल का इस्तेमाल नहीं किया जा सकता. इसकी मुख्य वजह यह है कि कोई पिक्सल स्नैपशॉटिंग एपीआई नहीं था. साथ ही, पूरे व्यूपोर्ट को क्लोन करने से परफ़ॉर्मेंस से जुड़ी समस्याएं आ रही थीं. इसलिए, इस सुविधा को एआई मोड के साथ लॉन्च करने का सबसे अच्छा तरीका यह था कि इसे प्रोग्रेसिव एन्हांसमेंट के तौर पर इस्तेमाल किया जाए. व्यू ट्रांज़िशन से बनाए गए ऐनिमेशन, वेबसाइट के काम करने के तरीके पर सीधे तौर पर असर नहीं डालते. इसलिए, जिन ब्राउज़र पर ये काम नहीं करते उन पर इन्हें बंद कर दिया जाएगा. ट्रांज़िशन ऐनिमेशन के बिना, वेबसाइट की मौजूदा स्थिति यही है.

हमने सबसे पहले, इस प्रोग्रेसिव एन्हांसमेंट रणनीति को अपने इंटरनल उपयोगकर्ताओं के साथ टेस्ट किया. इससे हमें शुरुआती दौर में ही सुझाव/राय/शिकायत मिल गई. इनमें से ज़्यादातर सुझाव/राय/शिकायत सकारात्मक थीं. हमें मिले सुझाव/राय या शिकायत से, गड़बड़ियों के बारे में भी पता चला. इनमें परफ़ॉर्मेंस से जुड़ी समस्याएं और अन्य सुविधाओं के साथ अनचाहे इंटरैक्शन शामिल हैं. जैसे, ओवरलैपिंग स्टैकिंग कॉन्टेक्स्ट.

हमें यह रणनीति कारगर लगी. हमें लगता है कि आने वाले समय में, हम ब्राउज़र की अन्य नई सुविधाओं के साथ भी इसका इस्तेमाल करेंगे.

हमें क्या-क्या समस्याएं आईं और हमने उन्हें कैसे हल किया

लेटेंसी, रेंडर होने से रोकना, और वॉचडॉग टाइमर

कुल मिलाकर, MPA व्यू ट्रांज़िशन की वजह से होने वाली लेटेन्सी, 99% इस्तेमाल के मामलों में न के बराबर होती है. खास तौर पर, आधुनिक हार्डवेयर पर. हालांकि, Google Search में लेटेन्सी (डेटा ट्रांसफ़र में लगने वाला समय) को लेकर काफ़ी सख्त नियम हैं. हमारी कोशिश होती है कि हम ऐसा उपयोगकर्ता अनुभव तैयार करें जो सभी डिवाइसों पर अच्छी तरह से काम करे. हमारे लिए, कुछ मिलीसेकंड भी मायने रखते हैं. इसलिए, हमें यह पता लगाना था कि क्रॉस-डॉक्यूमेंट व्यू ट्रांज़िशन को सही तरीके से कैसे लागू किया जाए, ताकि किसी भी उपयोगकर्ता के अनुभव पर कोई असर न पड़े.

रेंडर ब्लॉकिंग एक ऐसी तकनीक है जो क्रॉस-डॉक्यूमेंट व्यू ट्रांज़िशन के साथ अच्छी तरह से काम करती है. आने वाले दस्तावेज़ के स्यूडो-एलिमेंट स्नैपशॉट में सिर्फ़ ऐसा कॉन्टेंट दिख सकता है जिसे पहले ही रेंडर किया जा चुका है. इसलिए, आने वाले दस्तावेज़ के कॉन्टेंट को ऐनिमेट करने के लिए, आपको उस टारगेट एलिमेंट के रेंडर होने तक ब्लॉक को रेंडर करना होगा जिसे आपको ऐनिमेट करना है. इसके लिए, HTMLLinkElement पर blocking एट्रिब्यूट का इस्तेमाल करें. रेंडरिंग को ब्लॉक करने के कुछ नुकसान भी हैं. जैसे, आने वाले दस्तावेज़ के DOM ट्री के आखिर में मौजूद किसी एलिमेंट के लिए इंतज़ार करने से, लेटेन्सी पर काफ़ी असर पड़ सकता है. हमें इस ट्रेडऑफ़ को ध्यान में रखते हुए, सिर्फ़ उन एलिमेंट पर ब्लॉक को रेंडर करना पड़ा जो पेज के लाइफ़साइकल में बहुत पहले रेंडर हो जाते हैं.

<!-- 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>

कुछ मामलों में, यह बताना काफ़ी नहीं था कि आपने किस एलिमेंट पर रेंडर ब्लॉक किया है. कुछ डिवाइसों या कनेक्शन पर, डीओएम ट्री की शुरुआत में मौजूद किसी एलिमेंट पर रेंडरिंग ब्लॉक करने की सुविधा चालू होने पर भी, लेटेन्सी बढ़ जाएगी. इन मामलों को मैनेज करने के लिए, हमने एक वॉचडॉग टाइमर स्क्रिप्ट लिखी है. यह स्क्रिप्ट, एक तय समय के बाद HTMLLinkElement को हटा देती है, ताकि आने वाले दस्तावेज़ को रेंडर करने से ब्लॉक होने की समस्या को ठीक किया जा सके.

इसे करने का आसान तरीका यहां दिया गया है:

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();
}

कवरेज से जुड़ी सीमाएं

हमें एक और समस्या का सामना करना पड़ा. दस्तावेज़ में क्रॉस-डॉक्यूमेंट व्यू ट्रांज़िशन ऐट-रूल navigation: auto, ग्लोबल लेवल पर होता है. क्रॉस-डॉक्यूमेंट व्यू ट्रांज़िशन को सिर्फ़ कुछ खास क्लिक टारगेट पर चालू करने का कोई इन-बिल्ट तरीका नहीं है. यह एक बड़ा बदलाव है. इसलिए, हम Google Search पर 100% नेविगेशन पर, क्रॉस-डॉक्यूमेंट व्यू ट्रांज़िशन की सुविधा चालू नहीं कर सके. हमें एक ऐसे तरीके की ज़रूरत थी जिससे उपयोगकर्ता की गतिविधि के आधार पर, क्रॉस-डॉक्यूमेंट व्यू ट्रांज़िशन को डाइनैमिक तरीके से चालू या बंद किया जा सके. हमारे मामले में, हमने इन्हें सिर्फ़ एआई मोड में बदलाव करने के लिए चालू किया है. हमने ऐसा, नेविगेशन ऐट-रूल को प्रोग्राम के हिसाब से अपडेट करके किया. यह इस बात पर निर्भर करता है कि किस टारगेट पर क्लिक या टैप किया गया था.

व्यू ट्रांज़िशन ऐट-रूल को टॉगल करने का तरीका यहां दिया गया है:

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;
}

जंक और कंपोज़िट किए गए ऐनिमेशन

व्यू ट्रांज़िशन के छद्म-तत्वों पर अपने-आप जनरेट होने वाले कुछ ऐनिमेशन की वजह से, पुराने डिवाइसों पर फ़्रेम ड्रॉप हो रहे थे. इससे, उपयोगकर्ताओं को मिलने वाला बेहतर अनुभव खराब हो रहा था. ऐनिमेशन की परफ़ॉर्मेंस को बेहतर बनाने के लिए, हमने उन्हें फिर से लिखा है. इसके लिए, हमने ऐनिमेशन की ऐसी तकनीकों का इस्तेमाल किया है जो कंपोज़िटर पर चल सकती हैं. हमने ऐसा, कीफ़्रेम की जांच करके किया. इससे हमें स्नैपशॉट से पहले और बाद के छद्म एलिमेंट के डाइमेंशन मिले. इसके बाद, हमने मैट्रिक्स मैथ का इस्तेमाल करके, कीफ़्रेम को फिर से लिखा. यहां दिए गए उदाहरण में, हर व्यू ट्रांज़िशन स्यूडो-एलिमेंट के लिए ऐनिमेशन को कैप्चर करने का तरीका बताया गया है:

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

व्यू ट्रांज़िशन लागू किए गए: स्नैपशॉट वाले ब्लॉक से निपटना में, परफ़ॉर्म करने वाले व्यू ट्रांज़िशन कीफ़्रेम लिखने के बारे में ज़्यादा पढ़ें.

ध्यान रखने लायक अन्य बातें

एक अहम समस्या यह है कि view-transition-name सीएसएस प्रॉपर्टी के साथ टैग किए गए एलिमेंट, स्टैकिंग कॉन्टेक्स्ट (व्यू ट्रांज़िशन स्पेसिफ़िकेशन: सेक्शन 2.1.1) पर असर डालते हैं. इस वजह से कई बग आए थे. इन्हें ठीक करने के लिए, कंटेनर एलिमेंट के z-index में बदलाव करना पड़ा था.

एक और बात का ध्यान रखें कि हो सकता है कि आपको डिफ़ॉल्ट रूप से, एलिमेंट में view-transition-name वैल्यू न जोड़नी हों. Google Search पर कई लोग काम कर रहे हैं. हमारी टीम ने एलिमेंट पर view-transition-name वैल्यू सेट की हैं. हालांकि, ऐसा हो सकता है कि अन्य टीमों के लोग भी इन वैल्यू का इस्तेमाल करें. इसलिए, हमने व्यू ट्रांज़िशन टाइप का इस्तेमाल किया है. इससे, view-transition-name प्रॉपर्टी को सिर्फ़ तब जोड़ा जा सकेगा, जब कोई खास व्यू ट्रांज़िशन टाइप चालू हो.

सिर्फ़ तब किसी एलिमेंट में the-element का view-transition-name जोड़ने के लिए सीएसएस का उदाहरण, जब ai-mode का व्यू ट्रांज़िशन टाइप चालू हो:

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

सभी व्यू ट्रांज़िशन के लिए सीएसएस के ये नियम लागू करने के बाद, pageswap और pagereveal इवेंट के दौरान किसी भी नेविगेशन के लिए, मौजूदा व्यू ट्रांज़िशन टाइप को डाइनैमिक तरीके से बदला जा सकता है.

pageswap इवेंट के दौरान, व्यू ट्रांज़िशन टाइप को ai-mode पर अपडेट करने का उदाहरण.

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'],
    );
  }
);

इस तरह, हम नाम के टकराव को रोकते हैं. साथ ही, हम उन एलिमेंट का स्नैपशॉट नहीं लेते हैं जिन्हें एआई मोड में जाने और उससे बाहर आने के दौरान स्नैपशॉट लेने की ज़रूरत नहीं होती.

आखिर में, स्टैकिंग कॉन्टेक्स्ट से जुड़ी कोई भी समस्या सिर्फ़ व्यू ट्रांज़िशन के दौरान मौजूद होगी. इन समस्याओं को हल करने के लिए, हम जनरेट किए गए सूडो एलिमेंट के z-इंडेक्स को टारगेट कर सकते हैं. इसके बजाय, व्यू ट्रांज़िशन का इस्तेमाल करते समय, इस समस्या को हल करने के लिए ओरिजनल एलिमेंट के z-इंडेक्स में मनमाने तरीके से बदलाव किया जा सकता है.

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

आगे क्या करना है

हम Google Search के लिए, क्रॉस-डॉक्युमेंट व्यू ट्रांज़िशन का इस्तेमाल करने का प्लान बना रहे हैं. इसमें Navigation API के साथ इंटिग्रेशन भी शामिल है. हालांकि, यह सुविधा तब उपलब्ध होगी, जब इसे अलग-अलग ब्राउज़र पर इस्तेमाल किया जा सकेगा. हमारे साथ बने रहें और देखें कि हम आगे क्या बनाते हैं!