Hi all, and thanks for being here. Half an hour is very little time, so let's dive into the talk. I'm Francesco and we will take a quick ride through the tool we use the most, our trusty browser. It helps everyone surf the web, but more importantly, it allows everyone to serve through our artistic creation. Well, but first, let's do a virtual show of fans. We are not in person, I know, but this will do. I bet if I ask it all of you right now, how many times have you gotten frustrated with your browser not responding? Or how often have you seen or closed the page with laggy animations or a bad user experience? Well, I can picture an infinite number of age dance at this moment. Well, it's time to understand why our dear beloved browsers sometimes act like this. Well, but what is a browser, you ask? Everyone uses it, but you really know it really works. So let's start by learning how it works and what challenges it faces. Okay. If we try to simplify things, it's an application that requests data from the web servers, sends a network request to the URL, retrieve resources and present them interactively. Sounds simple, right? Well, in reality there's nothing simple about it and it's one of the most complex processes you can imagine. Browsers are the most widely used software ready to run any kind of application. Everything today is web based. They helped us navigate for decades and they're build with millions of line of c plus plus code and a bunch of other hardcore starts. They need also to adapt to the ever growing demands of users. Trust me, they're a concentrated mix of technology and algorithms that makes the bad mobile looks like a regular car. And trust me, you should know that I'm Batman enthusiast. Well, okay. But those who write browsers have a little has to manage. Users love to see pixels on their screen has quickly as possible making a web application fast. Okay, you might be thinking, why should I care? I'm not a browser code developer, right? Oh, a little disclaimer. If you are from the Kramer team, please be merciful. Okay, thank you. Okay. Has fence quad goes. As web developers we must understand some of the mechanics of browsers so we can make better decision and grasp some things that sometimes seem absurd. Actually it's not Femiscott, it's mine Chicho from Valdemon, a national name of place in Sicily. But I hope that it will be very famous quote and you can help me. Okay, we have confirmed that it's complex stuff, but worth knowing about. So let's dive into how it's built and look a bit inside the architecture. Well, currently there are no standard specification for browsers and approaches could change from other to another, from one to another. Well, however, today a multiprocess architecture is commonly used where each process handles specific task or logic. Moreover, these processes have a main thread and dedicated thread for more specific tasks to manage more specific tasks. To get a clearer understanding of the concept of processes and threads, we can define them very high level as follow a process is a running program that includes the executable code, data, program state and other elements required for the execution. Each process has its own address space and is managed by the operating system Lida, an independent entity. A thread is a single unit of execution within a process. A process can contain one or more threads which share the same memory space and resources of the parent process. Well, since browsers use multiprocess architectures, processes must communicate with each other. So using the interfaces communication APC the APC is a set of mechanisms and techniques such as pipes, socket, shared memory and blah blah blah, that enables separate processes on operating system to exchange data and communicate between them. IPC is essential when coordination and sharing of information are needed between separate processes, such in a multitasking system or a distributed application, for example. Well, a browser is a multiprocess application and these processes manage to communicate with each other. Well, but what exactly are these processes and how do they collaborate? Whoa. Don't be scared. It seemed complex and indeed it is, as we can see in this wonderful, beautiful low zone diagram made by myself, our brother, is divided into various processes. Okay, the first one, main or browser process, is the browser's primary process, responsible for managing the user interface, address bar, menus, tabs and so on. As well as coordinating interaction between others processes. It also handles the creation and termination of tab rendering processes. Okay, one moment. Well then we have the rendering processes. Each open tab in the browser is associated with a separate rendering process. This process renders web page, process, HTML, execute javascript, and interfaces with the dome. Each tab has dedicated process and sometimes different contexts, like an iframe for example. You can think that each tab having its own rendering process right now is good enough to understand. It's not perfect like a concept, but it's good enough. Well, the network process manages all network requests, including resource download like image, style sheet and so on. It isolates network operation to ensure security issues or crashes, so don't impact the entire browser experience. It's basically responsible for communicating with the network with the Internet. The GPU process handles hardware acceleration for rendering pages and works closely. Yes, closely with the rendering processes. It provides better graphic performance by separating graphic work from tab and user interface management. There are also others processes like storage, extension and various minor processes, but it's not important for our session. Okay, as you can see, each process has a priority showing how important a process is to the operating system. DOS balances process priorities to ensure efficient use of system resources and a responsive experience for our application. Okay, it's important. Well, like everything else, multiprocessor architecture has its pros and cons. Talking about pros, sandboxing is like a security bubble that isolates processes and underlaying the operating system. So if one process gets hit by malware, for example, the image is contained. So that process without messing up the world browser operating system is a very important thing. Blackship detection nice name. Consider this a way to spot processes that are consuming too much resources like cpu or memory or ones that might be blocked, for example. This feature helps prevent a single tab or process from destroying your browsing. Experience optimal memory fruit in another one. This is about ensuring your browser uses memory wisely. Nobody likes a memory hog. Okay? Privacy data this feature can ensure sensitive stuff like cookies, private browser data and so on are handled securely and privately. And the last one set isolation that ensures web pages from different sites load in separate processes for the same reason. But there are some counts. It's normal. We have got to deal with extra memory usage, for example, creating lots of processes and a lot of chitchat between them using ABC. Okay, well we understand what happens when we browse then. Okay, well, when we enter a URL or a search query in our address bar, the input is evaluated by the browser process and the end navigation begins. The browser process communicates with the network trader process to execute the request and then manage the response handle the response. At this point, a render process is activated by the browser process and navigation is taken over by the render process. Finally, the document loading phase begins, maintaining the dialogue between the render and browser processes. It's very weird, but it's true. So the user types in the address bar. The browser process asks the network process to go fetch the information of the Internet. Once it is received, the browser process instantiates or look for the best is another concept render process which communicates with the browser process and TaDA. The page is served. So it's not magic, but what happens inside the rendering process. Well, let's try to understand it together. The rendering process taken care of by the trusty render process is certainly the most intricate and exciting part, and it's where we encounter the much clearer critical rendering part. Great concept, but what exactly does it entail? What does each rendering process need to do to render the requested page? Well, here is the entire journey that the rendering process has to do to render a single frame fira, a very common gesture in Italy. You know, Italians are known for the expressive gestures, and I'm sicilian, the best one for the expressive gestures, trust me. Okay, let's remove the expression of terror from our faces and take a look at the main phases of the rendering process. Tense is a considerable part to the main thread, which we'll discuss later. The rendering process needs to handle parsing, style, calculation, layout, painting and composing. Okay, hand composing. Let's go through them one by one. Well, when we send over the Internet, data travels as packets, and when retrieved by the network process, the data is nothing more than row bytes. The first thing we receive is the HTML also received a simple bytes. What's necessary is to execute a parsing phase that follows a well defined process. It transformed bytes into a sequence of character that are then tokenized. Tokenization means converting them into a sequence of tokens. A tokens is a piece of text representing an HTML element, an attribute text, or other content within the HTML document. For example, a tag like opening div tag becomes an open token, while closing div tags becomes a closing token, as you can see in these images, by doing these, what were once bytes become analyzable. Structure and the tokens are analyzed by Alexer, Alex analyzer to understand the language, to identify their type and relative information, such as the tag name or attribute value or so on. The lexer breaks down the tokens, the token stream and recognize their structure. So the browser can finally create nodes and dom using these tokens and information extracted during tokenization and relaxer works. Finally, the DOM is like a tree like representation of the page's structure, and each node represents an element in the HTML document and contains information about the relationship between elements. But we should read it now this, and I'm sure you know this well. After creating the DOM, the browser builds another free knows as CSSOM. The CSSOM, a very difficult name for an italian guy like me, represents all CSS rules declared in the document, including selectors, style declaration and their specificity. It uses similar parsing techniques, not the same, but similar for the CSS files and retrieve information found in line during parsing. In fact, references to CSS style sheets are identified and the rendering process, or better, the main thread, fetches the relative CSS files or extract styles directly from the HTML documenting line. Okay, well, CSS style sheets are parsed and we get the CSSOR. Well, this phase and another phase is completed and the process is ready to create the layout or render tree once the DOM and CsS Som are created. In fact, the main thread traverses through the DoM and styles making the layout or render tree. This tree contains the information such as the coordinates and dimensions of elements. These structures represent the visible elements on the web page and their relationship. Non visible element will not be included in this tree in the render tree. Okay, the layout process is quite resource intensive for the browser because it has to compute the exact position and size of every element on the page. Every element on the page, the exact position and size. Well, this is a slide I'm very proud of. Quite a notable quote. I hope you catch the quote and it's animated too. I'm expecting a virtual and great applause. Okay, the dome and CSS on fusion. Whoa. Well, he obtains not a super science, but the most powerful layout tree. Well, during the layout phase, the browser calculates the size and position of element in the box tree. This process is known has reflow elements are positionated based on their type, dimension of their content, and the computed styles values on the x and y axis two dimension axis. This has considers factors such as viewport dimensions, browser windows resizing, and other variables that can affect the position of the element. Okay, I hope this video help you. The video is clear enough, but watching it give a good sense of how much work is required to position element by element on the page. It's a great work and very hard work. Okay, well, once we have positioned the element on the x and y axis, a new face come into play, the paint phase. However, to be able to draw every pixel on the page, it's also necessary to know how the elements are arranged on z axis. So what's in front and what's behind. Okay, the painting has is the process in which the browser draw pixel on the user device screen based on the calculated layout and web page content. During this phase, the layout tree is traversed to build a queue, a queue of paint records which helps detect pixel colors, drawing orders of element and their overlapping. Okay, the content is divided in two layers traversing the layer tree, and it is useful to generate the layer tree. Okay, the compositing phase is the next step after the painting phase. It's a very important phase. During this, the browser combines the previously prepared layers into a single compositing mage that represent the final visual appearance of our web page. This phase, and it is very important, is handled by an independent thread called compositor thread, and some of the more resource intensive operations such as scrolling are managed by this thread. Before compositing begins, the content is divided into layers by traversing the layout tree to generate the layer tree, another structure, another tree. The information is then received by the compositor thread, which handles the rasterization of each layer by breaking them down into draw quotes and sending them to the raster thread. Draw quotes a portion of pages like quotes for our page. After the draw quotes are created, the compositor trait gators around the world the information to create a composite frame. It is like a collection of information and is then sent to the browser. The browser process, I'm sorry, via pc and then to the GP U for display for display to our display. Well, for example, if there is a scrolling event, the compositor trap creates another compositor frame to send it to the gpu. Okay, so we finally have our rendered frame. When a user gesture like a touch on the screen occurs, what we have to do okay, when a user gesture like attach, for example on a script on a screen, I'm sorry occurs, the browser process is the one that receives the gesture at first. However, the browser process only knows where that gesture occurred. Since the render process handles content inside a tab, so the web process sends the event type touch start, for example, and this coordinates to the render process. The render process handles the event appropriately by finding the target and running the attaching listener, the attached listener. Okay, this work is made by the compositor thread. The compositor thread marks a region on the page, one or more region or more regions on the page with the event handlers attached, and these regions are called non fast crawlable region. This information allow the competitor thread to send input events to the main thread to manage this event only if the event occurs in that region. If an input event come from outside this region, the compositor thread continues compositing a new frame without waiting for the main thread. And it is wonderful and sorry, there's indeed a lot to do and every step is critical. Critical the World Series of step is often called CRP critical rendering, but the entire process has to manage an aspect that makes it especially critical. It's crucial for the browser to render about 60 frames per second to ensure smooth animation. So the entire pipeline I saw I talk has approximately ten milliseconds to complete its task, and it is crazy or it's critical. Okay, if the browser fails to maintain this frame generation frequency, we'll see those infamous logs that are so detested by users we often refer to as junk in technical jargon. But we are sure no user wants a poor experience, so avoiding it is crucial. It's important to know that you can skip specific steps in the rendering process through some optimization. You can skip the layout phase when the dimension or positions aren't changed. For instance, if only color of the text changes, there's no need to redo this has or you can skip the painting phase. Use specific CSS rules like transform and opacity that works directly on the gpu. Skipping any of these phases will help the browser render the correct number of frames for asmooth experience. Okay, well, so we need clarification on a concept we should all be familiar with, but it's very important to clarify web application use the main thread to execute most application logic and user interface tasks. We are really familiar with the concept of the event loop, I'm sure. However, it's crucial to understand that it lives within the main thread and its behavior also help us in the rendering phase helps browser or us in the rendering phases haven't loop is basically an infinite loop responsible for selecting a task from the task queue and placing it on the main thread for execution until completion. And I'm sure you know, but sometimes selecting a render steps task instead of reading from the task queue to generate a frame. So we need to be careful not to overload it. This task to execute comes in various states that include all the render steps performed on the main trait well, so looking back at the recap slide now, we should understand better, or at least I hope so. It's essential to grasp how much work the browser has to do frame by frame, and how crucial it is to achieve those famous 60 frame per second. Okay, so far what I have told you aligns with what happens in chromium based architecture. However, it's important to remember that various rendering engines work depending on your browser on your choice. Okay, so our browser don't have such an easy life as we could see, and it's a good idea to start thinking about how to make their job more manageable. Well, some ideas, some stuff we can dig into include request animation frame and request idle frame API. Use it, use them. Use the wheel change, but be careful. CSS rules to create a layer of rendering to create another layer of rendering, use the async and deferred tag attributes to load our script in a synchronous way. Please use workers workers is an incredible technology not so young. And this kind of technology is helpful to move a lot of work out of the main thread. Okay. Manage the priority of the resources with preload or check out CSS and API triggers that force the layout and paint faces well to ensure a smooth experience. Let's try to help the tool that takes us through. Billions and billions and billions of pages full of things to learn and kittens every day. Well, I do it in my way. I use the bad computer, which is powerful and I don't care no like that, but by trying to write better code. Okay, well, this is a collection of link. It is always handy links and more and more and more. Okay, well, I'm Francesco Shudi, a developer by choice and patient. I'm a Google developer expert at Microsoft MVP. I'm also a partner in an italian company that specializes in front end mobile development and provides training in this field. So thank you all very much and here are some links to reach out to me or my company. Thanks again. And now it's feedback time. Thank you so much.