Engineering video
8:40 · 6 May 2024
Critical CSS encompasses styles needed for above-the-fold elements, which can be extracted using tools like Webpack plugins and Puppeteer to improve performance by deferring non-essential styles.
Watch section from 0:00 →ARIA attributes specify semantic accessibility roles for non-semantic HTML elements (like divs or spans) when design constraints prevent the use of proper semantic HTML.
Watch section from 0:00 →Defer downloads scripts in parallel during HTML rendering and executes them before DOMContentLoaded, whereas async downloads and executes scripts as soon as possible without waiting for HTML rendering.
Watch section from 2:00 →Normal static imports happen at build time, enabling tree shaking and TypeScript type inference, while dynamic imports function like network-fetching promises that can be evaluated conditionally at runtime for lazy loading.
Watch section from 4:03 →CLS measures unexpected layout shifts during page load caused by late-arriving assets like images, fonts, or styles, which can be mitigated using fixed dimensions and debugging performance tools.
Watch section from 5:21 →Essential state changes independently and stems from user interactions or network data, whereas derived state is calculated or computed directly from existing essential state variables.
Watch section from 7:05 →Hi folks. Here we go. Senior front end interview questions. Now, Bug, are you ready? Yes, let's go. Very important question comes up uh every almost in every front end engineering interview I've been doing. What is critical CSS? And how do we extract it in a on a web page? Ah, sure. So, critical CSS is the name we give to the CSS styles needed to display the elements uh that appear above the fold. So, basically imagine you land on a page and you see certain elements without scrolling. That would be uh the above the fold elements in the critical CSS. It's all the CSS we need in order to make those elements uh position and to style them. In order to extract it, uh you can use certain module bundle plugins, like I used in the past, the Webpack plugin. It will basically render the application with Puppeteer, a headless browser. So, in the background, it will render the application for the specific width, and then it will use browser mechanism like the CSS coverage to extract the CSS tiles that you need to render a specific width. Once you extracted critical CSS, you can use it to improve the performance of your application by deferring all the CSS except the critical CSS. Because CSS it's a unique name space, browser really try to collect all the CSS in uh in it and render it before they move on with the HTML part. So, if we have a lot of CSS that uh that can take a long a very long time and decrease the application speed. So, if we are able to separate that, we can improve uh drastically the the performance. Cool. Now we're going to move on with a accessibility question. Have you ever heard about the area attributes in HTML and when are they useful? So, most of the times we just want to stick to semantic HTML. That's the easiest and best way to make something accessible. But there is some edge cases where we just cannot use
semantic HTML because of design constraints or because we're building a specific widget. And in that case, you can use aria attributes to specify semantic accessibility roles for non semantic HTML elements like div or span. I would definitely use them if you have accessibility constraints and you cannot use semantic HTML. Talking about semantic tags in HTML, what I do footer or header or image, those are all semantic tags. They have semantic meaning and the accessibility tools understand them. Cool. Now we're going to move on. Can you explain what the defer and async attributes do when added to an HTML script tag? Um, sure. So, we use defer and sync to control when a certain script tag will be loaded and interpreted. Um, defer will basically download the script in the background as we render the HTML, so we can parallelize, but interpret the script uh just before the DOM content loaded event. So, just when it finishes the HTML, then it goes with that script. Well, async, it's pretty um it's pretty parallel. So, it just really downloads the script and interprets it as soon as possible. And um it doesn't really care about when the HTML is rendered. It can finish before or after, so it doesn't really matter. And as far as I recall, ES6 modules are deferred by default in most web browsers. Understood now. Why do we want to use this defer and async attributes in the first place when uh loading a script in HTML? Uh, so the main reason to do that is to avoid scripts blocking the critical rendering path and have much better web performance, uh much better initial loading. And so we pretty much take all of our non critical JavaScript, all the JavaScript that we don't really need in the initial load, and we can push it down so it doesn't block the uh the rendering of the page. Cool. Now we can
and move on to an ES6 question. Can you explain the difference between a normal import in ES6 and a dynamic import? Basically, dynamic imports work more like the common JS imports, like a function. You can think of it as a function and it will just import or fetch over the network the module. Whereas normal imports are static imports, so they get interpreted at build time. And the biggest difference is that with static imports, okay, normal imports, you can apply tree shaking, you can infer TypeScript types.
So you have all the advantages of static analysis, whereas with dynamic imports, you do not have all those advantages. But because they are like a function, you can use them in code. So you can, for example, use them inside if statements or switch statements. So they allow you to lazy load components. Okay. So lazy loading certain components, right? Yes, and you can also load certain modules depending on an user action.
So you could, for example, if you only use load dash when the user does something, you can add an dynamic import that imports load dash when the on click event happens. So you don't need to load load dash in the initial load, which makes the initial load much faster and it only loads that code on demand. Awesome. Cool. Now we're going to move on with AP performance, web performance question. The question is, have you heard of the CLS metric and can you explain it?
So CLS, it's one of the core web vitals. I think it stands for cumulative layout shift and it's basically the layout shift that happens as we load the page. So normally what would happen is we render the HTML and then maybe some styles arrive too late, maybe some fonts or images arrive too late. And if we haven't optimized our page well, the user will perceive that as a shifting layout. It happens sometimes you go to a slow page, all of a sudden an image is render at the top and they push everything to the bottom.
And maybe you clicked on something, but you end up clicking on something else. so that would be the cumulative layout shift. How would you fix this? What would be the first steps to fix a uh bad CLS score? The first thing I would do is probably use some debugging tool to see which element has a lot of CLS. uh the new Google Chrome Performance insight does a vague job at it and they pinpoint exactly the div that's moving.
And then based on that, you mentioned images, but they can be many different causes, it can be the fonts, it can be CSS loading slower. Then you have different solutions. So for example, if it would be, if an image is the main cause, I would add some fixed width and height um uh attributes to this image. And then the browser will know ahead of time, hey, this image will be this big, so it would render stuff around it and you won't have CLS.
If the issue with it's with fonts, for example, I would try to optimize the font loading and you can also uh specify uh what will be the the height of the fonts coming in versus the the web browser's default, and then you have no CLS. So again, depending on the cause, you'd have different solutions, if it's CSS, implement uh critical CSS and only load the CSS we need. Awesome. Sounds good. And uh final question for today, I want you to explain difference between essential state and derived state in a front end application.
As the name says, derived state, it's usually state we can calculate based on other state and essential state, it's state that changes independently and we cannot really calculate or deduct the value from other state variables. It's either coming from user interactions or data fetching over the network. So just to give you maybe an example, if you have a checkout page, I would say essential state is the items in the cart.
Whereas derived state, it's anything we need to compute based on those items, like the total price, the net price, the price with tax, how many items you have in the cart. All that would be derived state, it doesn't really change independently and we can derive or compute the value based on the existing essentials. makes sense. Awesome. Well, um, thank you for today, for the for you people watching us.
Is there any question, any interview question that you want Bogden and I uh to address in these videos, then just drop it in the comments. And finally, if you want Bogden and I to personally mentor you, for you to close your gaps and become that competent, confident senior engineer, check the links uh in the descriptions as well, you can schedule a quick chat with me, uh find out if there's a match, if there's a fit, and you know, I would love to, you know, understand your situation better, see if you could be a fit and see if we could help you.
You can apply in the comments. With that being said, we will see you in the next one.
