Creating instant and seamless web apps with Chrome

Key Takeaways

[Music] hello welcome to this workshop creating an instant and seamless web app my name is sunya i'm a web ecosystem consultant at google and i'm hadian also a web ecosystem consultant at google we are host of the workshop today we will walk through the quadrant together we will start with an existing web application and learn how to implement the apis that chrome natively supports that can make its navigation instant and the transition more seamless before we get started with our up i would like to ask hariyam to explain a little bit of what we mean by instant and seamless and why they are important certainly the apis that fall under the instant and seamless program are created with the purpose of bringing a low friction engaging and intuitive user experience on the web you have probably heard about core vitals a set of metrics that measure real-world user experience for loading performance interactivity and visual stability of the page we introduce core vitals because site speed is always an important aspect of user experience there are three new instant loading apis that we will learn in this codelab pre-rendering back forward cache and private prefetch proxy these apis would help to improve core vital score on your website in the field especially for loading performance and we will also cover a seamless transition api the root shared element transitions we have become accustomed to the intuitive navigation and state changes that mobile native apps offer while it is possible to replicate such experience on the web implementing it through the web platform apis are often too difficult seamless apis are designed to fill that kind of user and developer experience gap between app and web as we learned about these instant and seamless apis please note that these apis are still in the early stages so there might be some bugs limitations and missing features as of today api services might also change in the future that is why we would really welcome your feedback and bug report that you can submit through crbog.com now that we are all aligned with the definition of instant and seamless shunya shall we start with our codelab alright let's dive into the coder app the sample web app is built with nexjs which is a popular javascript framework the app is intentionally made from mpa smart page application part and spa single page application part for demo purpose we will implement pre-rendering and the backward cache for npa pages and shared element transition for spi pages what you need firstly you need a browser that supports the apis chrome version 111 or above and knowledge of html css javascript and how to use chrome dev tools next we are going to enable chrome flags you can open the browser and type chrome chrome slash flux to the address bar we will enable two flags one is for pre-rendering and the other one is for shared element transitions those apis are implemented behind the flag which are not enabled by default we can restart the browser once the are enabled after you enable the chrome flux and restart the browser then download the source code we are hosting the source code on github so you can run the git chrome command to download please specify the branch name by passing the b option to the command the branch name is caller once you downloaded the source code then run the npm install command and npm run dev command then the app will start on your local server we run npm run dev command in the terminal and see if the server is running yes the server has started now we are ready to add new ielts features so we can start from pre-rendering as the name implies this is about pre-loading rendering and running a web page before the user actually navigates to it the main goal of pre-rendering is to ideally achieve near instant navigation in this codelab we will apply pre-rendering for same origin urls you can read this web.dev article web.dev slash speculative pre-rendering that explains about pre-rendering in great detail to achieve the near instant experience a pre-rendered page is created when the browser acts on a hint to pre-render a url the content is loaded into a pre-rendering browsing context a new type of browsing context that can be thought of as a browser tab that is not yet shown to the users when users navigate to that url the pre-rendering browsing context is activated from the user's perspective activation acts like an instantaneous navigation because it does not require a network round trip creation of a document or running javascript initialization like a normal navigation all of those things have already been done in the pre-rendering browsing context i also mentioned earlier that the browser needs a hint to pre-render a url this is done through the speculation rules api you can learn more about this in this github page github.com slash wicg nav speculation and if you find out about the speculation rules section you will be able to find that speculation rules is a new way to declare what kind of speculation the browser may do about future user activity in this case an outgoing navigation you can use this api to tell the browser which links to pre-render the speculation rules is json object included within a script tag that can be inlined or loaded in externally just before we start working on pre-rendering i would like to highlight two things one pre-rendering requires more device and network resources that resource hints like preconnect prefetching and the others are doing so please be mindful when selecting the url to prerender you should analyze your user navigation pattern and only pre-rendered the url that your users are most likely to navigate to you should also avoid pre-rendering pages like the checkout add to cart login or logout pages the second point is that the current pre-rendering origin trial only accepts one same origin url to pre-render per page with that shunya will now show you how to integrate pre-rendering into the sample app sunya all right let's implement the pre-rendering feature into the sample app we are going to add the feature to the list of vegetable page the demo bubbles the response time of the vegetable detail page is very slow by having a delay on the server side we can eliminate this this waiting time by using pre-rendering first let's add a new button to the list of vegetable page that will trigger pre-rendering once a user clicks it we will start from making a new button component as the first step so we can copy and paste the code simplet from the coder app and create a new file we can create a new file on the components directory and naming prerendableton.js and paste it basically this prerender component renders a button element and triggers the handle click function then the user clicks the button inside the function we capture the url of the next page and pass it to the dispatch function we import resource context here this is a predefined feature in this web app it manages global states by using react context prerender url is managed in resource context and it will be used for making a speculation rules component once it's updated once we create the prerender button component then we import it into the list item component it's a component for list of list items in the list pages so let's open the list item not just and we can uncomment here and here so we import the preliminar button and [Music] use it on list item for nba function next we are going to make another new component which is speculation rules component this component will insert a speculation rules script tag into the html to trigger pre-rendering create a new file under the component directory and named speculation rules dot js and paste it so in this code we make custom script tag by using script component provided by nextgs this component will insert the script tag once the preliminary url global state has changed then import the script speculation rules component into our app.js let's open the app.js and we can import speculation rules component here and uncomment this ring now we've implemented the basic feature of prerender let's check how it works on the browser so we have pre-render button here and without pre-rendering the navigation to detail page takes a very long time like this after clicking the button the pre-rendering process has started in the background and it results in the page loading instantly like this yes it works we successfully open the next page without waiting for the loading and rendering time it looks great thanks sunya as you work on implementing pre-rendering on our sample app there is one sticky question on top of my head what happens with the javascript on the page that are pre-rendered but not yet activated do they run at all that's a good point hadia you should be careful of which scripts on the pre-rendered page because they will be run even before user navigates to the prerendered page let's take an example of the analytics script pageview events should only be sent when the user actively visits and visually sees the website not the time when the website is pre-rendered but not activated yet let's open analytics.js on the public directory by default analytics.js in the sample web app sends a page view event in the dom content loaded event handler unfortunately this is not wise because this event will fire during the pre-rendered phase so let's make this analytic suggest to be pre-render aware we introduce document.prerenderingproperty and the pre-rendering change event here a document can tell it being pre-rendered with the document document.pre-rendering property upon navigation the pre-rendering change event is dispatched to the document we go back to the editor first we should change analytics.js not to send page view event if the page is prerendered but not activated yet we can put the document.pre-rendering property check in the send event function basically we can uncomment here this send event function is called on in the dome content loaded event if the page is prerendered but still not activated the property returns true so we can simply return in that case the next point is we need to send the pageview event when the pre-rendering page pre-rendered page is activated since the pre-rendered page already finished the dom content loaded event we use the pre-rendering change event in this case so let's uncomment this range this event is triggered when the pre-rendered page is activated and the user actually opens a page and we call send event function inside the event handler now we are changed the analytics code to be prerender aware let's check how it works on the browser you can open the dev tools and click the console tab we can see the event is sent when the page is opened like this and click the pre-render button and click the link yes we are seeing the page activation block first and then the page view event that works correctly the page view event is sent exactly when we activate the pre-rendered page all right moving on to the next instant navigation api the backward cache the backcard cache or bf cache is a browser optimization that enables instant back and forward navigation chrome data shows that around one in 10 navigations on desktop and around 1 in 5 on mobile are either back or forward navigation bf cache is different from the http cache http cache contain only the responses such as html css javascript for previous made http requests while bf cache is an in-memory cache that store a complete snapshot of a page including javascript heap with bf cache enabled loading the previous page is essentially instant because the entire page can be restored from the memory without having to go to the network at all nor having to re-render the page either [Music] we can check the comparison video on the web.dev article there are lots of factors for bf cache eligibility please check out web.dev bf cache to get an in-depth detail about the common bf cache broadcast and in this workshop hadian will take you through how to unblock the top two bf cache brokers the android event handler and cache control no store http header our sample app has an unnecessary unload event handler it is a common mistake to use an unload event because it is unreliable it does not always fire on mobile platforms and safari now we can remove this unload event from our sample app the unload event is triggered from public slash analytics.js file we are now replacing this unload event with the page height event instead page height event is much more reliable because it fires in all cases when the unload even fires and it also fires when a page is put in bf cache this is the first blocker and let's move on to the second blocker the second blocker that we want to remove is the cache control no store http header we will call it the ccns header if a page does not contain personalized or critical information like in the case of our sample app we probably don't need to serve our page with the ccns http header because the page will not benefit from the browser's bf cache feature because right now our sample app is run locally with the next dev command the next js library overrides its http header with ccns header in order to prevent local caching for development and debugging purposes to confirm this we can use the network step in devtools to check the http header of our sample app if we pick up the devtools network tab let's reload our sample app and we can see that there is a cache control no store header here so now as an exercise in this a code lab we can declare a cache control public http header in two files to be able to see how bf cache impacts these two pages when we navigate back and forward between them let's go back to our code editor and let's work on the vegetable index page in here we have prepared the set header function call that we can uncomment and you can see that we are calling the cache control public header here so that's the first file and the second file that we are going to modify is the detail page of each of the vegetable vegetable slash name.js so similarly we have prepared a set header function call here and we can just uncomment this line save it and now we have these two pages explicitly calling cache control public header now that those codes are in place the next step is to stop our dev server which i'm doing at the bottom of the screen here and then we can run an npm run build command to make our production build it may take a couple of seconds to complete the building now that we have built the production build we will run our production build with npm run start everything looks good on the production build so now we can head back to our browser and we can reload our vegetable page once again we look at the network tab in the devtools console now we can inspect that the cache control is set to public let's also inspect the vegetable detail page as soon as mentioned there is some delay that we especially put in for this sample app and we also see that it is setting the cache control to public so now let's see whether the bf cache is in place now if we move back with our browser back button and then move forward again we can see that the page load is really different now don't you think we are seeing a near instant experience here because the page is loaded from bf cache that's it we have successfully removed the two main bf cache blockers the unload event handler and ccns http header i would like to mention that the chrome team proposes that pages with ccns http header are stored in bf cache in some scenarios such as when there are no cookie changes you can check the details of this proposal by following this url in our codelab that looks great but i have two questions how can we gather the stats of pages that are restored from bf cache also after we remove the brokers how can we debug if the page is now eligible for bf cache is there an easy way to check those are great questions first of all i would like to note that the main analytics tools and chrome user experience report are aware of bf cache but we also want to show you that you can use a property called persisted in the page show event to show whether a page is restored from bf cache or not let's head back to the public slash analytics js file on our sample app you can see that we have prepared a code block here for the page show event so we can just uncomment this block and in this page show event handler there is a persisted event which only returns true when the page is restored from bf cache so in inside this persisted event code block you can run anything to your in-house analytics tool or in this case we are just sending a message to the dev console this should do it now let's see the patio event handler in action in our browser so previously there is no event when the page was loaded from bf cache now let's reload our pages this is the vegetable index page and then the detail page of the vegetable now if we go back to the previous page we can see this message that we just added the page was restored from bf cache same goes if we go forward this page now has the page restored from bf guest message that we have added inside the page show event handler now you can gather any statistics that you want only when your page is restored from bf cache and for your second question sunia about how we can debug a page eligibility for bf cache there is a dedicated testing tool in devtools to help us identify any bf cache blockers in devtools let's open the application step and on the left side you see the cache heading here underneath you will find the back forward cache testing so inside this tool we can use this test back forward cache button we click on it the page will reload and if the page is successfully restored from bf cache you will see this message here successfully serve from back forward cache otherwise it will list down the bf cache blockers for example when the page has the unload handler or cache control no store http header like what we discussed earlier i hope this answers your question sunya yes certainly they are clear now thanks hadiyan so we have pre-rendering and pf cache in the app but what about the user experience when user navigates from other sites such as google search page let me introduce the concept of prefetch basically prefetching speeds up navigation by starting fetches array so that the response are already at the browser when the user navigates however when it is done with a naive approach there is a thread of in which user information such as their interest or ip address would be revealed to the publishers before the user decides to navigate that's not good from the privacy perspective the private prefetch proxy solves this problem private prefetch proxy enables cross-site prefetch without revealing private information about the user to the destination server this proxy never sends cookies or other personally identifiable information also it hides the browser it has the user ip address via http 2 connect proxy as it is shown in the animated image in our code prefetches are end to end encrypted between chrome and the origin the proxy only knows the hostname of the destination the private prefetch proxy is now provided an early access program by opting in chrome will try to prefetch the links to your website on the google search page if it's eligible please keep in mind that these are the instructions for the current state of the private prefetch proxy at the time of recording for the latest please refer this url doo dot gre slash p3 dash info harian will now take you through on what we have to do to get the benefit from this technology there is a new resource called traffic advice that allows site owners to control how the site responds to private prefetch proxy requests for example if you need to temporarily opt out or if you want to limit the prefetching connections you can think about traffic advice as something similar to your robots.txt file which gives directives to web crawlers when it crawls your site during the early access program we are also using this traffic advice to opt-in to the private prefetch proxy let's add this resource to our sample app we have to add it under the public slash well-known directory now we are creating a new file here and call it traffic dash advice now that the file is created let's take the sample code snippet from our codelab let's copy from here and paste it to our newly created file as you can see the file content is actually a json configuration in this case google prefetch proxy eap is a special field to opt into the early access program and the fraction is a field to control the fraction of preferred prefetch proxy request just one more thing the traffic advice also needs to be written with a specific mime type that's why we need to configure the response header of our sample app in the next dot config.js file here since we have prepared the code block let's uncomment this and now you can see that whenever the browser requests for the traffic advice file it will be written with the content type that is set to application slash traffic advice plus json like we are setting here since we updated the next.js config file we need to stop our server again which i'm doing at the terminal at the bottom of the screen and then let's restart it with the npm run dev command to start our dev server again looks like the server is started so let's head back to our browser and check whether the traffic advice file is in place as you can see the traffic advice file is now served from our sample app and let's inspect the network tab in devtools and we can see that the content type is as per what we have set just now applications less traffic advice plus json that's about it we have now opted in our sample app to use private prefetch proxy what do you think sunya well that's a very simple process to obtain the eap we can get the benefit of prefetching and that would improve the quality vital score in the field as we mentioned before private prefetch proxy is still actively developed and the instruction might be changed in the future please check the latest status from the public github repository when you work on it another option to enable cross site prefetch is using signed exchange we don't cover signed exchange at this workshop but please take a look at the google search documentation and web.dev articles for more details there are lots of useful libraries and tools that makes it easy to build signed exchange of production alright so far we have covered the three instant navigation apis now we will look at the seamless transition api root shared element transition on the web when a user navigates from page a to page b the content that they are looking at changes suddenly and as page a disappears then page b jumps into view this sequence and disconnected user experience is forcing users to piece together how they got to where they come from this jarring experience also increases how much users perceive the page loading as they wait for the destination page to load smooth loading animations can lower the cognitive load by helping users stay in context as they navigate between the pages and also reduce the perceived latency of loading by providing users with something engaging and delightful in the meantime for these reasons most platforms such as android ios and windows provide easy to use primitives that enable developers to build seamless transitions root shared element transitions api provides developers with the same capability on the web regardless of whether the transitions are cross document in multi-page application or intra-document in single page application all right let's integrate the shared element transition into the spa part of the sample app the list of fruit page and detailed page are built with spa so we apply the shared element transition between those two types of pages first of all let's open the global.css file basically shared elements needs a special css which is a contain property in css and we set paint as the value of the property this property allows elements to make a new stacking context and implies that descendants of the elements don't apply outside of its bonds that is a requirement for shared element before diving into the sample app code let me explain a little bit about the transition object which is the new javascript api provided by the shared element transitions basically we can split the transition process into two steps the first step is preparing the transition on the first page we create the transient object by calling the document.createdocumenttransitionmethod and we register an element as shared element by transition.setelement method and then we call the start method that's the first step it should be done on the start page before moving to the next page the second step is making a page transition once the start method is called the browser tries to capture snapshot for the registered elements we update the dom and switch to the next page inside the start function after switching to the next page we register the element by using the set element again so we are registering the elements in both start page and next page by doing so those two elements are considered as a shared element during the page transition in the browser when the callback finishes the animation will start and we will see the seamless navigation between two pages so how can we integrate it into next.js or react component lifecycle in order to manage that kind of workflow inside the sample app we use some custom hooks in react let's open use page transition.js [Music] so basically we have two custom hook one is use page transition prep and the other is use page transition these two custom hooks implement the workflow that i explained before as i mentioned the start method needs to be called on the first page and the next page needs to be rendered inside the callback function to make this happen we are using a promise in the use page transition prep book in order to defer the callback function being resolved not on the first page but on the next page we pass the resolver function from the start page to the next page we call use page transition prep on the first page which is the list page in the sample app and we call the use based transition book on the second page which is the detail page let's open the list item.js file and import the use page transition prep book you can uncomment here then we check list item for spa component we receive the function the trigger the transition start method from the book and call it inside the click event [Music] we can uncomment this range inside the function the shared element class elements are collected and registered as shared elements now we've finished the work on the first page moving on to the next page that receives the transition object let's open the name.js under fruit directory [Music] on this detail page we call use page transition hook to finish transition start callback function we can uncomment here and replace the line here so we set the left object here it will be used inside the custom hook in order to access the actual dom with using useless indiact alright we've done the shared element transition integration let's check the browser and see how it works let's open the demo again so basically we expect images between the list and detail page to be registered as shared elements and make smooth transition with animation [Music] yes it works we've now achieved a seamless transition on the sample app that is the basic integration of shared element transition api if you want to customize the animation more you can use the css pistol classes please check out the explainer for more details congratulations for making it to the end of our codelab and creating a low friction engaging and intuitive web app we hope you had a fun time going through this codelab with us as mentioned in the beginning of our codelab these apis are still in their early stages so we would like to share these great references that you can follow to get the latest updates and learn more we would once again invite you to submit your feedback through the github pages of each api or through crbog.com there is also a great deep dive session about root shared element transitions with jake archibald do check it out and many other interesting io sessions as well ariana [Music]