 Ini adalah untuk 99% anda yang bekerja di web Walaupun anda bekerja di web desain, perkembangan, analisis performa atau otomasi test, kami telah membantu anda. Saya Jessalyn, perkembangan perkembangan perkembangan perkembangan perkembangan perkembangan. Saya akan berkongsi dengan anda beberapa perkembangan yang menerimanya dan menerimanya, terutama perkembangan dan otomasi. Oh, untuk 1% anda, Just follow along and I'm sure you will learn some productive tooling tips. Let's start with the design tools and jump straight into the toolings around the new responsive. The web ecosystem is changing and the CSS is evolving. The responsive design today is not only about changing layout based on the viewport size but it also includes modifying the component layout based on its parent's container and tweaking the design based on user preference. Combining the power of media queries, CSS grid, container queries and the cascade layer, we can create a truly responsive layout like this. The page layout is created with the CSS grid with template areas defined for headline, big and minus areas. We can enable the grid batch to inspect the grid, then go to the layout pane, change the setting to show the area's name on the screen. Say, you want to swap the positions of the mocha and express saw. With the label, we can reorganize the layout with ease. Klik on mocha and we can change the grid area to big. Then, we can do the same for express saw or with the help of the number labels, we can instead change the grid load precision to negative 3. It gives you the same result. For more grid debugging tips, please refer to google.gear slash dev2-grid. Next, let's take a look at the coffee component. These are essentially the same coffee components but they display differently based on its container size. The coffee description is shown on the side when there is more space. It moves to the bottom when the container size gets smaller and the description is completely hidden for the very small container size. This is achievable with the CSS container queries. In the elements panel, click on the container batch to toggle the overlay on the element. Now, click on the paragraph and we can see the container queries in the styles pane. With this rule, the paragraph will show only if the container size exceeds 400 pixels. Let's adjust that to 100 pixels and see what will happen. Aha, the description now shown for the smaller cut as well. Apart from that, the container name is displayed on the top of the queries. Hover on it to view the container size or click on it to jump to the container right away. Now, inspect on a hyperlink, notice the new layer section in the styles pane. These are the new CSS cascade layer. Instead of using the importance to overwrite the styles, you can now define multiple layers and set their priorities regardless of the sequence in the code. In our example here, I have three layer defined, the base style, the component, and the page. Each layer changes the color of the hyperlink. So, which color wins? Well, since the page layer has the highest priority, the hyperlink will be brown. You can view the layer names in the styles pane and click on it to see its priority. To learn more about these new CSS features, please make sure you check out Adam's talk on the state of CSS. Now, let's talk about the part of the new responsive. Users often set preferences in their operating system to get a more personalized experience. With these new user preference media features, we can style the web experience to align with the user's specific needs. During the design, instead of messing with your device settings, you can use depth tools to simulate these media queries on the different combinations. Go back to our demo here. When hovering the mouse over the card element, we animate and enlarge the card item. Let's adjust styles to support users who prefer less motion. First, force the element to the hover state. Open the rendering tab with Ctrl Shift P Ctrl S, scroll down and set the preference reduce motion media feature to reduce. In the styles pane, instead of enlarging the card, we can change the border color for users who prefer reduce motion. Next, let's see how your page looks when the users enable the force colors mode. Windows high contrast mode is one of the example. Set the force colors mode to active and check on your page's styles. You might want to find how it looks in the dark mode as well. Set the preference color scheme media feature to dark for that. Nice, our page looks good. Let's move on to talk about some new accessibility tools. We can create content that looks very different than what it is in the HTML document. This is a big accessibility problem as screen reader users would get a different and most likely confusing experience than sighted users. The new full page accessibility makes it easier for you to get an overview and help you better understand how your web content is exposed to assistive technologies. Enable full page accessibility tree setting and reload depth tools. Here, spot new accessibility button in the elements panel. Click on it to toggle full page accessibility tree view. Hower over a node to highlight the corresponding element on the screen. You can expand the nodes or click to see the details in the accessibility pane If you select a node and toggle back to the DOM tree the corresponding DOM node is selected. Go to Google.gov slash accessibility dash 3 to learn more. Besides that, you can view the order of source elements on the screen. Enable the show source orders checkbox in the accessibility pane. Now, focus on an element. For the screen reader users. Last update on the design tools. If you are like me, always forget about the CSS changes you make in the styles pane. This new feature can help you to track and copy the changes with ease. For example, let's change the containers padding to 20px and change the background color to black. Notice the green border that indicates these styles have changed. What is even better is that you can hover on the rules and click on the copy button to copy the styles right away. Or if you want to copy all the changes at once use the new button on the top. There you go. Very convenient, right? Next, I want to share with you some good stuff on debugging tools. Let's start with the network panel, shall we? First one, a feature request since 2014. You can finally throttle the web socket request in the network panel. Let's filter the list by web socket and click on the request. Set the network to offline and send a message. You can see the message is sent but it's not yet network connection to no throttling and the message is now received. Debugging the cross origin resource sharing issues has always been difficult. With the new changes, we want to make it less painful. The network request with course error are now labeled and highlighted in the network panel. Apart from that, you can now click on the icon next to a preflight request to identify the origin request. Oftentimes, you might start debugging the course errors from the console. We added the same button to help you locate the corresponding network request with an extra button to understand the issues. Click on it to open the issues tab. Here, you can learn about why the errors happen, the impacted resources and potential fixes. With these changes, you can change the console setting to hide the course errors details. This way your console looks less scary. A bonus tip on the settings, you can sync your dev2 settings across all devices if you enable the sync. Useful for those who work on multiple devices. The console has some new changes as well. Apabila anda mencari kode di console, anda mengalami error keberadaan? Untuk contoh, anda mempunyai kode ini di console. Apabila anda mencari kode dan menerima error keberadaan. Well, the good news is the console now supports redeclarations of cons less and class statements. This way, you can experiment with new JavaScript code without reloading the page. Apart from that, it was hard to spot an object's custom properties especially for web APIs with many inherited properties. This snippet creates an URL object with two own properties, user and assess. This is how the properties looks like previously. With the latest improvements, DevTools will always bold and sort the object's own property first. Similarly, the properties changes applied to the properties pane as well. Besides that, you can now filter the properties and enable the show all checkbox to view all the properties with now and undefined value. Very helpful especially for those of you who works a lot on custom elements. Good news for the Chrome extension developers. You can now debug Chrome extensions with source map files. For example, here is my extension built with TypeScript transferred to JavaScript with a source map file. Open the Chrome extension enable the developer mode and load the extension. Open the service worker. You can see the messages are now locked as expected and point to the TypeScript source file. Previously, users will receive warning and the lock only points to the JavaScript making it hard for debugging extensions but not anymore. Next, let's touch a little bit on the improvement we have done on WebAssembly debugging. Since last year, the WebAssembly tooling team and the DevTools team have worked together to improve the debugging experience of large-scale applications like Google Earth and Adobe Photoshop. Previously, when you change a line of code and compile it, it takes about 400 seconds for you to be able to run the code. This experience is apparently not great. Imagine waiting 6 minutes just to change a typo in the code and run it. With the new enhancement on the linking process, we have successfully brought down the debugging cycle from 400 seconds to only 23 seconds. Now, let's take a guess. How much time does it take when you set a breakpoint in the code and want to see the scope variables? It used to take about 20 seconds previously with the support of multiple build flags and more efficient symbols loading. It only takes about 2 seconds now. If you wonder how we achieve that, go to google.com faster-wasm-debugging to learn more. Okay, I have some exciting updates for you on the performance tooling. However, before that, let's take a step back to understand the current pain points for performance analysis. This copied photo is exactly how majority of us developers feel when working with performance analysis, especially with the assisting performance panel. Over and over, we see developers struggle when working on the performance panel. It feels like the performance panel just give you a whole bunch of information and let you figure out how to fix. It is probably fine if you are a performance expert that knows the in and out of how a browser works. However, for many of us, we just want to get some actionable feedback on what to fix and be able to analyse performance based on a certain use case like improving the page load or analyse the interactivity. Can we simplify that? Take the page load use case for example, there are three key metrics to figure out if your page is loaded fast enough. First is the loading speed. Is your main content loaded fast enough? Second is the interactivity. Can the users interact with your page without delay? The last one is about visual stability. Is there an advertisement popping up halfway as the user is reading the main content? These three key metrics are what we call the core web vitals. The essential metrics for delivering a great user experience on the web. When building a new application you can run the lighthouse report in the dev tools to get an overview of your pages performance. If you want to drill down further, you can use the new performance insights panel to do so. Let's start by opening the performance insight panel and click on measure a page load. For now, the performance insights panel only support the page load use case. More use cases will be added based on your feedback. First thing first, once the recording is completed you can click on the play button to replay the recording or even slow it down. Next, let's zoom in to the insights pane. Here, you can get an overview of the key insights of your page. When you hover the mouse over the insight item it will highlight the item on the main track as well. Not only that, you can click on the insights item to view the details. Here, it shows the render blocking issues with suggestions on how to fix it. You can drill down to the network details to view the request waterfall. Let's shift our focus to the main track. The web vitals matrix are displayed on the top and you can hover the mouse over it to view the details. Next, let's talk about the layout shift and what are they. Think about layout shift like fireworks. There are time where multiple rapid shift happen continuously then it pause for a few seconds and it starts to shift again. Let's take a look at our page load. Once the coffee is loaded the page is stable for a while then an image pop up and pushes the content down. Then the page is stable for a while until later the size of the coffee cup changes and a new font is loaded. The first group of rapid shifts happens when the image is loaded and it happens since under 0.4 seconds. The second group of rapid shifts happen one second later due to the cup size changes and the new font and it happens within 0.9 seconds. For each group of these rapid layout shifts we name them as session windows. So we have 2 windows here you can spot that in the layout shift track as well and it's pretty obvious gap in between the 2 windows. When debugging the layout shift issues always focus on the largest window first. From the track we know that window 1 has larger shifts than windows 2. So let's focus on that. Each of the layout shifts carry score. The maximum score for each layout shift is 1 if the whole page is shifted. In our case the first layout shift is the biggest because of the blank space allocated for the image. The second layout shift is smaller because it only pushes the content down a little bit more when the image is loaded. Now click on the layout shift. You can view the current layout shift details and the cumulative score. The details pane also listed the current windows details with the total score and all the layout shifts within the window. This could help you understand how the score is calculated. To maintain a good CLS the total score of each window should be within 0.1. Apart from that the pane also shows the potential root causes of the layout shift and the impacted elements for reference. The performance insights panel is experimental. It is an experiment to provide a more actionable and use case-driven performance analysis experience. Please go to go to google.gov. And please send us your feedback via the feedback link. As a developer or a tester, we want to make sure our users can complete their task successfully. For example we want to know if our users can order and paid for the coffee successfully. At the same time we hope to have tools to automate the flow at the same time we want to make sure our new code changes don't break the user flow. This is what the recorder panel is for. A tool to help you record, replay and measure your user flow. We launched this feature last year as a developer preview. And since then your feedback is overwhelming. Among the feedback here are the top 3 requests. You want to be able to set a longer timeout between steps. You want to be able to specify a custom selector for the recording and you want to be able to import and export the recordings for sharing purpose. We hear you and guess what? We have built these 3 features with some extra goodies. Let's go through them one by one. You can now set a longer timeout for all the steps or customise for a particular step with the add timeout button. The recorder will auto-prefer the common test selector if you define that. For example data test is a common selector. When it is defined the recorder will take that as the default selector instead of using the ID attribute and the CSS class. Even better you can define your own custom selector during the start of the recording. For example we are using the data automation selector in this case. During the recording the recorder will pick the element with the data automation attribute wherever possible. Next you can now export the user flow as a JSON file and share it with others. You can receive the files that can import it back in the recorder and replay the user flow just like this. Combining the import and export features it could be a really powerful tool for bug reporting. But there are more. Drumroll please. Tada! You can now convert the recording into the front-end testing tools that is built for the modern web. Here is how to do it. Once you install Node.js you can install the Cypress Chrome recorder with this command. Next run this command to convert the file into a Cypress Test Script. For example I exported the order of coffee JSON in a recording folder. Here I run the Cypress Chrome recorder command to convert the file. A new JavaScript file is generated and that is the Cypress Test Script. Let's move the file into a Cypress project and launch the Cypress Test Runner. In the Test Runner our spec file is shown on the screen. Cypress support running tests in multiple browsers. For example let's select the Firefox browser and start the test. And yay! The test replaced successfully in Firefox. Apart from that we also support exporting the user flow as Puppeteer Replace Script. What is the Puppeteer Replace Script? Go to go.gov-slash-dev-tools-dev-recorder to find out more. And thank you for your feedback so far. Let's keep them coming. Alright There are a lot of interesting new features in DevTools indeed. Every 4 weeks I will publish a what's new in DevTools blog post with a short video summarising the top features. Go to this link to subscribe or follow at Chrome DevTools on Twitter for the updates. That's all. Thanks for watching. Ciao!