DEV Community: Andrew S.

Optimizing Web Application Performance

Andrew S. — Mon, 14 Jul 2025 20:06:52 +0000

Overview

In today's fast-paced digital world, web application performance plays a crucial role in delivering a seamless user experience. Slow loading times, lagging interactions, and unresponsive interfaces can drive users away and negatively impact your business. To make your web application work at its best, it's important to optimise its performance. In this article, we'll go over various tips and techniques to help you optimise your web application for better performance.

1. Minimize HTTP Requests

Every time a web page loads, it makes several HTTP requests to retrieve resources such as HTML, CSS, JavaScript, images, and other resources. These requests can cause delays in page loading. You can minimise the number of HTTP requests:

Combine multiple CSS files into a single file, just as you would with JavaScript files.
Use CSS sprites to combine multiple small images into one.
Use font icons instead of uploading separate image files for icons.
Use lazy loading methods to load resources only when they are needed.

Also, consider using browser caching by setting appropriate cache headers to reduce the number of HTTP requests made by returning visitors.

2. Optimize CSS and JavaScript

CSS and JavaScript can have a significant impact on the performance of web applications. By optimising and minifying these files, you can reduce load times and improve performance. Here are some tips:

Minimise your CSS and JavaScript files by removing unnecessary comments, whitespace, and line breaks.
Combine multiple CSS and JavaScript files into one file each.
Place the CSS files in the <head> section and the JavaScript files just before the closing of the </body> tag.
Consider using CSS preprocessors such as Sass or LESS to make your CSS more efficient and maintainable.
Consider using JavaScript bundlers such as Webpack or Rollup to eliminate unused code and reduce file size.

3. Compress and Optimize Images

Images can take up a significant portion of the total page size. Large image files can slow down loading times. Optimise images for the web:

Compress images with tools like PNGGauntlet, TinyPNG, or JPEGmini.
Resize images to the appropriate dimensions for your web page.
Use modern image formats such as WebP, which provide better compression and quality than JPEG and PNG.
Lazy loading of images that are not initially visible.
Use responsive images to display different sizes depending on the resolution of the device.

4. Reduce Server Response Time

The time it takes for the server to respond to requests can have a significant impact on the performance of web applications. Reduce server response time:

Optimise database queries by adding the right indexes, reducing unnecessary joins, and caching frequently accessed data.
Use a content delivery network (CDN) to cache and serve static content from servers closer to the user's location.
Enable HTTP/2, which allows the server to handle multiple requests simultaneously and reduces the need for multiple connections.
Implement server-side caching mechanisms, such as reverse proxies or in-memory caches, to store frequently accessed data.

5. Optimize Database Queries

Inefficient database queries can slow down your web application. Optimise database queries:

Analyse slow queries and optimise them by adding appropriate indexes, rewriting queries, or denormalising data where necessary.
Minimise the use of OR conditions and use appropriate indexes for columns used in WHERE, JOIN, and ORDER BY clauses.
Cache frequently accessed data in memory using tools such as Redis or Memcached.

6. Eliminate Render-Blocking Resources

Render-blocking resources, such as external CSS and JavaScript, can delay the rendering of a web page. Remove the render-blocking resources:

Load critical CSS inline or use methods such as server-side rendering.
Use script tags with async or defer attributes for non-critical JavaScript files so that rendering continues without waiting for the script to load.

7. Optimize Web Fonts

If web fonts are not optimised properly, they can slow down loading times. Optimise web fonts:

Use subsets of fonts to include only the characters you need and reduce file size.
If possible, use system or stock fonts to avoid downloading custom web fonts.
Preload web fonts to reduce rendering latency.

8. Enable GZIP Compression

Enabling GZIP compression can significantly reduce the size of the response and speed up page load times. Most modern web servers support GZIP compression. Enable it by adding the appropriate configuration on your server.

9. Implement Caching Mechanisms

Caching plays a crucial role in reducing the load on your web application and improving performance. Implement caching mechanisms on both the client and server sides:

Implement browser caching by setting appropriate cache headers for static files.
Use HTTP cache headers such as Cache-Control and ETag to control server-side caching.
Use content delivery networks (CDNs) that automatically cache static files to reduce server load.

10. Optimize Your Code

Efficient code execution is key to performance:

Use async or defer attributes to load JavaScript files asynchronously, preventing them from blocking the rendering of the page.
Combine multiple CSS and JavaScript files into one to reduce the number of HTTP requests.

11. Use Lazy Loading

Lazy loading delays the loading of off-screen images and other elements until they are needed:

Implement lazy loading for images and videos to improve initial load times.
Use lazy loading for additional content that appears as users scroll down the page.

12. Database Optimization

For dynamic websites, optimizing the database can lead to significant performance gains:

Ensure that your database tables are properly indexed to speed up queries.
Regularly clean up unnecessary data and optimize database tables.

13. Monitor and Optimize Performance Regularly

Performance optimisation is an ongoing process. Regularly monitor your web application's performance and collect metrics using tools like Google Analytics, New Relic, or Pingdom. Use these metrics to identify bottlenecks and areas for improvement. Continuously optimise your web app to ensure a fast and seamless user experience.

Conclusion

Optimising web application performance is crucial to delivering a seamless user experience and maximising conversions. By following the tips and techniques discussed in this article, you can significantly improve the performance of your web application. Don't forget to regularly monitor and optimise performance to stay one step ahead. Implement these strategies and your users will thank you with increased engagement and loyalty.

Support ❤️

It took a lot of time and effort to create this material. If you found this article useful or interesting, please support my work with a small donation. It will help me to continue sharing my knowledge and ideas.

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

Ways to Generate Pages: CSR, SSR, SSG, ISR

Andrew S. — Sun, 13 Jul 2025 14:53:27 +0000

Along with SPA, several interesting concepts have emerged that may seem complicated and, at the very least, incomprehensible. What is the difference between client-side, server-side, static and incremental website generation? What is it anyway and how does it relate to Search Engine Optimisation (SEO)?

I suggest that you familiarise yourself with the following concepts and consider their advantages and disadvantages:

Client-Side Rendering (CSR);
Server-Side Rendering (SSR);
Static Site Generation (SSG);
Incremental Static Regeneration (ISR).

This material will be useful for Front-end developers of any level, because we will consider the concept, pros and cons of each approach, as well as the tools that can be used to implement them. I will use the React stack as a basis.

History

Before there was React or Angular, all websites were "multi-page" applications. We would open a website address in a browser, send a request to the server, where some conditional PHP would generate a whole page for us (all HTML, CSS, and a bit of JS) and return it to the client. When we clicked on a link to another page, sent the same request again, the server generated a new page and returned it. The browser deleted the old one and rendered the new one, with a kind of ‘blip’ when switching between pages. This approach is called Multi Page Application (MPA).

From an SEO perspective, this is the perfect approach. We have a full page with all the necessary information, and any search bot can read it immediately, our sites are at the top of search results, and our clients (the owners of these sites) are happy.

From the point of view of website users, it's not so perfect. Every time we open a new page, we wait for all the resources to load again and for the page to render. Of course, most of the resources are already cached, but we still wait for the page to be fully rendered. Well, no one has cancelled the transition blinks.

This approach was revolutionised by the emergence of frameworks that allowed to implement the so-called Single Page Application (SPA). The idea is that we load CSS, JS, and an almost empty HTML page once, and then JS builds everything in the client browser. When switching between pages, JS rebuilds only the part that has changed, and, if necessary, makes an AJAX request to the server to get the necessary data. We got rid of the blinks!

Customers are satisfied - we download the resources once and all pages are displayed smoothly in the browser. The user experience is similar to that of native mobile applications.

If all the resources have already been downloaded, why not store them on your phone and use them even when you don't have internet access? Progressive Web Apps will help you with this. Not all applications need to constantly download up-to-date information from the server, there are various games or static applications. And even if you do need to download information, such as articles, you can download them in advance and save them along with your files.

A Service Worker will help you implement this mechanism. And, as a bonus, by manually saving the application to your phone (and you can do it), it works without displaying browser navigation, just like a regular application installed from the App Store or Google Play.

SEO suffers. Search bots load the page, but there's nothing there, it's empty. They didn't know how to execute JS, so they couldn't get the same page as users. In addition, the URL did not change.

// An example of a page seen by a search bot.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">

    <title>SPA Aplication</title>

    <link rel="icon" href="/assets/favicon.ico">
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <div id="app"></div>

    <script src="main.js"></script>
  </body>
</html>

Over time, the URL began to change when navigating between pages. At first, it was hash navigation (using the # symbol, JS allowed you to change the hash in the address), then a full-fledged address change using the History API. Some search bots started to execute JS, but it was not a solution. Rendering a full page is a long and expensive process. Each bot has a so-called ‘budget’ - a limit on time, resources, and the number of pages it can crawl. Just imagine how many pages Google indexes every day - a huge amount of work.

The solution to the SEO problem is server-side rendering. It's time to take a closer look at it, but first, let's close the issue with client-side page generation.

Client-Side Rendering (CSR)

The approach is quite simple. The created application consists of several files: a stylesheet, scripts, and a conditionally empty HTML page where the styles and scripts are connected. In the index.html file, there is only one div with id="root", where the entire page is built. When you navigate between pages, the URL in the browser changes and data is pulled from the server, if necessary. The implementation is simple, the server load is minimal, because you do not need to render the page for each request, but only return static files. If you need data, you can create a separate RESTful server that will return data in JSON format.

As a bonus, it is easy to scale, and the data can be used by different clients (web pages, mobile applications, other servers). In addition, you can save money on hosting. You don't need a lot of resources to return a few files.

Of course, this approach suffers from SEO. Additionally, you may face problems when trying to share such pages on social media, because they also need to download the page, render it, and find the necessary data. And let's not forget about users: if they have old, weak phones, the page will take forever to render.

✅ Advantages:

Ease of implementation;
Less server load;
Relevance of information;
Do without a server;
Ease of scaling;
Cheaper hosting.

❌ Disadvantages:

SEO suffers;
social media crawlers and share issues;
more load on customers' devices;
JS file size at first download.

⚙️ Instruments:

Create React App;
React and manual configuration.

Server-Side Rendering (SSR)

The main feature of this approach is that the entire page is rendered on the server at the first request, and then, for example, React is initialised in the browser, and then the application works like a regular SPA, making AJAX requests to the server if necessary. The data loaded is always up-to-date, because every time the page reloads, a request to the server is made. From the SEO point of view, everything is also perfect: a full-fledged page is returned. Users are also satisfied - they work with a regular SPA and do not see any difference.

Although there is a need to maintain a powerful server that will handle all requests, there is an advantage. You can set up caching for the most popular requests, which will speed up page loading and display.

There are some difficulties with this approach. If you implement server-side rendering yourself using NodeJS, you need to:

Run, for example, React on the server to return the generated component. React comes with a function called ReactDOMServer.renderToString() that does this;
Pass the correct URL of the page, the server is not a browser. Let's use a static router - <StaticRouter location={req.originalUrl }>;
Get the data in advance and render the application using it;
After the page loads, run React so that we can navigate between pages, just like with client-side rendering. To do this, we use the ReactDOM.hydrate() function (ReactDOM.hydrateRoot() for the newer version of React). Unlike ReactDOM.render(), it doesn't hydrate the entire contents of the container, but only tries to add React event listeners to the pre-generated HTML.

✅ Advantages:

Perfect implementation of SEO;
Relevance of information;
Speed of loading and displaying content (Time to Interactive);
Server cache settings.

❌ Disadvantages:

Complexity of implementation;
Server load;
Increase in the size of files downloaded from the server;
Longer response from the server (TTFB - Time to first byte).

⚙️ Instruments:

Static Site Generation (SSG)

Do we need to generate a whole page on the server every time if the data is not updated that often? For various landing pages, business card sites, blogs, simple online stores where information is updated very rarely, server-side rendering support can be costly and redundant.

This is where SSG comes in. Why do you need to generate for each request if you can generate all the pages once when building the application? We simply put all HTML (CSS and JS) files in a folder, place them on a simple file server or even in a CDN and return them with each request. There is no server to process requests or generate pages. We get the maximum download speed and security. A safe server is a server that doesn't exist.

From the SEO point of view, this is an ideal option. For the user, the page is displayed even faster than with SSR, we don't wait for data on the server, so TTFB is smaller. For users, everything remains the same, because after the page loads, React is initialised again and the application works like a regular SPA.

From the SEO point of view, this is an ideal option. For the user, the page is displayed even faster than with SSR, we don't wait for data on the server, so TTFB is smaller. For users, everything remains the same, because after the page loads, React is initialised again and the application works like a regular SPA.

You may also wonder: what about user interaction with the site? What if you need to send a form or collect information? No one forbids you to launch a separate RESTful server that will be responsible for processing various requests from customers. You can also pay attention to Serverless or "cloud functions", I recommend taking a look at AWS Lambda or GCP Cloud functions.

✅ Advantages:

Perfect SEO implementation;
Loading and display speed;
Reliability and security (no server);
Cheap hosting.

❌ Disadvantages:

When updating content, you need to reassemble the project;
Time to generate a large number of pages, for example, for 100,000 products.

⚙️ Instruments:

GatsbyJS;
NextJS.

Incremental Static Regeneration (ISR)

This method combines the advantages of the previous two. You don't always need to generate a page for every request, and pre-generated pages are not a solution if the content is updated from time to time.

The solution is to split pages. Those that are updated more frequently will be rendered with SSR, while those that are rarely updated will be generated with SSG.

✅ Advantages:

Perfect SEO implementation;
Loading and display speed;
Can be used for some pages;
Relative relevance of information.

❌ Disadvantages:

The complexity of implementation;
Requires a server.

⚙️ Instruments:

NextJS.

Support ❤️

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

The Rendering Engine

Andrew S. — Thu, 10 Jul 2025 17:02:21 +0000

Overview

When you're building web apps, however, you don't just write isolated JavaScript code that runs on its own. The JavaScript you write is interacting with the environment. Understanding this environment, how it works and what it is composed of will allow you to build better apps and be well-prepared for potential issues that might arise once your apps are released into the wild.

So, let's see what the browser main components are:

User interface: this includes the address bar, the back and forward buttons, bookmarking menu, etc. In essence, this is every part of the browser display except for the window where you see the web page itself.
Browser engine: it handles the interactions between the user interface and the rendering engine
Rendering engine: it's responsible for displaying the web page. The rendering engine parses the HTML and the CSS and displays the parsed content on the screen.
Networking: these are network calls such as XHR requests, made by using different implementations for the different platforms, which are behind a platform-independent interface.
UI backend: it's used for drawing the core widgets such as checkboxes and windows. This backend exposes a generic interface that is not platform-specific. It uses operating system UI methods underneath.
JavaScript engine: basically, this is where the JavaScript gets executed.
Data persistence: your app might need to store all data locally. The supported types of storage mechanisms include localStorage, indexDB, WebSQL and FileSystem.

In this post, we're going to focus on the rendering engine, since it's handling the parsing and the visualization of the HTML and the CSS, which is something that most JavaScript apps are constantly interacting with.

Overview of the rendering engine

The main responsibility of the rendering engine is to display the requested page on the browser screen.

Rendering engines can display HTML and XML documents and images. If you're using additional plugins, the engines can also display different types of documents such as PDF.

Rendering engines

Similar to the JavaScript engines, different browsers use different rendering engines as well. These are some of the popular ones:

Gecko — Firefox
WebKit — Safari
Blink — Chrome, Opera (from version 15 onwards)

The process of rendering

The rendering engine receives the contents of the requested document from the networking layer.

Constructing the DOM tree

The first step of the rendering engine is parsing the HTML document and converting the parsed elements to actual DOM nodes in a DOM tree.

Imagine you have the following textual input:

<html>
  <head>
    <meta charset="UTF-8">
    <link rel="stylesheet" type="text/css" href="theme.css">
  </head>
  <body>
    <p> Hello, <span> friend! </span> </p>

    <div> 
      <img src="smiley.gif" alt="Smiley face" height="42" width="42">
    </div>
  </body>
</html>

The DOM tree for this HTML will look like this:

Basically, each element is represented as the parent node to all of the elements, which are directly contained inside of it. And this is applied recursively.

Constructing the CSSOM tree

CSSOM refers to the CSS Object Model. While the browser was constructing the DOM of the page, it encountered a link tag in the head section which was referencing the external theme.css CSS style sheet. Anticipating that it might need that resource to render the page, it immediately dispatched a request for it. Let's imagine that the theme.css file has the following contents:

body { 
  font-size: 16px;
}

p { 
  font-weight: bold; 
}

span { 
  color: red; 
}

p span { 
  display: none; 
}

img { 
  float: right; 
}

As with the HTML, the engine needs to convert the CSS into something that the browser can work with — the CSSOM. Here is how the CSSOM tree will look like:

Do you wonder why does the CSSOM have a tree structure? When computing the final set of styles for any object on the page, the browser starts with the most general rule applicable to that node (for example, if it is a child of a body element, then all body styles apply) and then recursively refines the computed styles by applying more specific rules.

Let's work with the specific example that we gave. Any text contained within a span tag that is placed within the body element, has a font size of 16 pixels and has a red color. Those styles are inherited from the body element. If a span element is a child of a p element, then its contents are not displayed due to the more specific styles that are being applied to it.

Also, note that the above tree is not the complete CSSOM tree and only shows the styles we decided to override in our style sheet. Every browser provides a default set of styles also known as "user agent styles" — that's what we see when we don't explicitly provide any. Our styles simply override these defaults.

Constructing the render tree

The visual instructions in the HTML, combined with the styling data from the CSSOM tree, are being used to create a render tree.

What is a render tree you may ask? This is a tree of the visual elements constructed in the order in which they will be displayed on the screen. It is the visual representation of the HTML along with the corresponding CSS. The purpose of this tree is to enable painting the contents in their correct order.

Each node in the render tree is known as a renderer or a render object in Webkit.

This is how the renderer tree of the above DOM and CSSOM trees will look like:

To construct the render tree, the browser does roughly the following:

Starting at the root of the DOM tree, it traverses each visible node. Some nodes are not visible (for example, script tags, meta tags, and so on), and are omitted since they are not reflected in the rendered output. Some nodes are hidden via CSS and are also omitted from the render tree. For example, the span node — in the example above it's not present in the render tree because we have an explicit rule that sets the display: none property on it.
For each visible node, the browser finds the appropriate matching CSSOM rules and applies them.
It emits visible nodes with content and their computed styles

Let's just look at some of the core things for this class:

class RenderObject : public CachedImageClient {
  // Repaint the entire object.  Called when, e.g., the color of a border changes, or when a border
  // style changes.

  Node* node() const { ... }

  RenderStyle* style;  // the computed style
  const RenderStyle& style() const;

  ...
}

Each renderer represents a rectangular area usually corresponding to a node's CSS box. It includes geometric info such as width, height, and position.

Layout of the render tree

When the renderer is created and added to the tree, it does not have a position and size. Calculating these values is called layout.

HTML uses a flow-based layout model, meaning that most of the time it can compute the geometry in a single pass. The coordinate system is relative to the root renderer. Top and left coordinates are used.

Layout is a recursive process — it begins at the root renderer, which corresponds to the <html> element of the HTML document. Layout continues recursively through a part or the entire renderer hierarchy, computing geometric info for each renderer that requires it.

The position of the root renderer is 0,0 and its dimensions have the size of the visible part of the browser window (a.k.a. the viewport).

Starting the layout process means giving each node the exact coordinates where it should appear on the screen.

Painting the render tree

In this stage, the renderer tree is traversed and the renderer's paint() method is called to display the content on the screen.

Painting can be global or incremental (similar to layout):

Global — the entire tree gets repainted.
Incremental — only some of the renderers change in a way that does not affect the entire tree. The renderer invalidates its rectangle on the screen. This causes the OS to see it as a region that needs repainting and to generate a paint event. The OS does it in a smart way by merging several regions into one.

In general, it's important to understand that painting is a gradual process. For better UX, the rendering engine will try to display the contents on the screen as soon as possible. It will not wait until all the HTML is parsed to start building and laying out the render tree. Parts of the content will be parsed and displayed, while the process continues with the rest of the content items that keep coming from the network.

Order of processing scripts and style sheets

Scripts are parsed and executed immediately when the parser reaches a <script> tag. The parsing of the document halts until the script has been executed. This means that the process is synchronous.

If the script is external then it first has to be fetched from the network (also synchronously). All the parsing stops until the fetch completes.

HTML5 adds an option to mark the script as asynchronous so that it gets parsed and executed by a different thread.

Optimizing the rendering performance

If you'd like to optimize your app, there are five major areas that you need to focus on. These are the areas over which you have control:

JavaScript — in previous posts we covered the topic of writing optimized code that doesn't block the UI, is memory efficient, etc. When it comes to rendering, we need to think about the way your JavaScript code will interact with the DOM elements on the page. JavaScript can create lots of changes in the UI, especially in SPAs.
Style calculations — this is the process of determining which CSS rule applies to which element based on matching selectors. Once the rules are defined, they are applied and the final styles for each element are calculated.
Layout — once the browser knows which rules apply to an element, it can begin to calculate how much space the latter takes up and where it is located on the browser screen. The web's layout model defines that one element can affect others. For example, the width of the can affect the width of its children and so on. This all means that the layout process is computationally intensive. The drawing is done in multiple layers.
Paint — this is where the actual pixels are being filled. The process includes drawing out text, colors, images, borders, shadows, etc. — every visual part of each element.
Compositing — since the page parts were drawn into potentially multiple layers they need to be drawn onto the screen in the correct order so that the page renders properly. This is very important, especially for overlapping elements.

Optimizing your JavaScript

JavaScript often triggers visual changes in the browser. All the more so when building an SPA.

Here are a few tips on which parts of your JavaScript you can optimize to improve rendering:

Avoid setTimeout or setInterval for visual updates. These will invoke the callback at some point in the frame, possible right at the end. What we want to do is trigger the visual change right at the start of the frame not to miss it.
Move long-running JavaScript computations to Web Workers.
Use micro-tasks to introduce DOM changes over several frames. This is in case the tasks need access to the DOM, which is not accessible by Web Workers. This basically means that you'd break up a big task into smaller ones and run them inside requestAnimationFrame, setTimeout, setInterval depending on the nature of the task.

Optimize your CSS

Modifying the DOM through adding and removing elements, changing attributes, etc. will make the browser recalculate element styles and, in many cases, the layout of the entire page or at least parts of it.

To optimize the rendering, consider the following:

Reduce the complexity of your selectors. Selector complexity can take more than 50% of the time needed to calculate the styles for an element, compared to the rest of the work which is constructing the style itself.
Reduce the number of elements on which style calculation must happen. In essence, make style changes to a few elements directly rather than invalidating the page as a whole.

Optimize the layout

Layout re-calculations can be very heavy for the browser. Consider the following optimizations:

Reduce the number of layouts whenever possible. When you change styles the browser checks to see if any of the changes require the layout to be re-calculated. Changes to properties such as width, height, left, top, and in general, properties related to geometry, require layout. So, avoid changing them as much as possible.
Use flexbox over older layout models whenever possible. It works faster and can create a huge performance advantage for your app.
Avoid forced synchronous layouts. The thing to keep in mind is that while JavaScript runs, all the old layout values from the previous frame are known and available for you to query. If you access box.offsetHeight it won't be an issue. If you, however, change the styles of the box before it's accessed (e.g. by dynamically adding some CSS class to the element), the browser will have to first apply the style change and then run the layout. This can be very time-consuming and resource-intensive, so avoid it whenever possible.

Optimize the paint

This often is the longest-running of all the tasks so it's important to avoid it as much as possible. Here is what we can do:

Changing any property other than transforms or opacity triggers a paint. Use it sparingly.
If you trigger a layout, you will also trigger a paint, since changing the geometry results in a visual change of the element.
Reduce paint areas through layer promotion and orchestration of animations.

Support ❤️

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

Ways to Avoid Cross-Browser Compatibility Issues

Andrew S. — Wed, 09 Jul 2025 19:44:26 +0000

Common Browser Compatibility Issues

1. DOCTYPE Error

Imagine writing the entire code and missing out on the most basic line! Yes, it can lead to a faulty rendering. Several browsers with outdated versions such as the Internet Explorer 8.0 and earlier often check for the Doctype.

In case it is missing, the site will be not be rendered as per expectations. To understand why the doctype is checked, we would have to understand the two modes in which a browser operates.

The first mode is called the Strict Mode. In this mode, the browser works with stricter code error checks and making sure that the code adheres to the W3C specifications. The second mode is called the Quirks Mode. The quirks mode was created with an intention of providing backward compatibility to older browser version and they do not perform strict error checking.

When there is a missing “Doctype” tag in the webpage, the browser tends to go into the quirks mode. At the same time, if there is a browser which doesn’t support HTML5, it will not understand which version to look for. This would lead to some of the tags to become unresponsive and the webpage will not look as intended.

The solution to this problem is a simple one line code at the very beginning of the code. It looks like this:

!DOCTYPE html

This will ensure a perfectly rendered site in every browser available.

2. Browser Detection

Unlike any other product, browsers are being loaded with technology to optimize output. This means less consumption, more output. But, due to these advancements, even javascript has a lot to offer to browsers. So, at times, when an old browser is being used chances are the javascript fails to detect the browser.

This is a common cross-browser compatibility issue which is faced due to obsolete java scripts. But, tackling this cross-browser issue is easy. You can remove the browser detection. Instead use Modernizer, a collection of ‘superfast tests’ which list all the features of a browser, hence giving you a seamless experience. Using this the developer can direct the site to focus on features rather than browsers.

3. HTML/ CSS Validation

Another major cross-browser compatibility issue faced by developers is the validation of HTML and CSS codes. This is mainly because different browsers read code differently. And not only read but also handle them differently.

There are times when developers are stuck with an error as small as missing out on closing a tag. While some browsers might autocorrect, others might not display the feature it signifies. For example, missing out on might cause an error on Internet Explorer and not on chrome.

It is a very common cross-browser compatibility issue and has a simple solution. One can use code validating tools for HTML and CSS depending on their requirements. These validators are powered by W3C.

4. CSS Resets

Browsers by default have a design layout (CSS style) which is applied to the website. For any website to implement its own layout, the default has to be overridden. Until implemented, websites will be rendered differently on different browsers.

To overcome this cross-browser issue, the websites rendered are ‘reset’ to the same basics. For this, developers use CSS reset style sheets. Addition of the style sheet ensures avoidance of any layout design issue.

Some common reset style sheets used include HTML5Reset, Eric Meyers CSS Reset and the Github based Normalize.css.

5. Layout Compatibility

As previously mentioned, browsers have default layout styling. But, developers started using ‘Resets’ in CSS to remove the default design and apply their own.

It has been one of the most common cross-cross-browser compatibility issues and has often been associated with one of the two reasons. It is either due to an irresponsive design on mobile devices or due to the difference in or lack of support for layouts by modern browsers.

These issues are now easier to solve. A common solution is the use of floats which is supported by most browsers. But, a float is a floating image inside a text box and comes with limitations.

For the modern-day layout, dedicated layout mechanisms such as CSS grids and Flexbox have been introduced. These are supported by most modern browsers and are effectively used by developers.

6. Vendor Specific functions

The functions defined by the developer are, at times, contain functionality specific to browsers. While writing the CSS code, these browsers are denoted by specific codes.

To ensure proper functionality and avoid this cross-browser issue, one needs to ensure the addition of the function without the prefix as well. This will ensure there is no error in other browsers.

Common vendor prefixes include:

Mozilla Firefox (-moz)
Internet Explorer (-ms)
Opera (-o)
Safari and Chrome (-webkit)

7. Website Feature Functionality

While technology keeps evolving and there are workarounds for the changes, a check on the features of the website should be on your checklist to avoid cross-browser compatibility issues.

While cross-browser testing with tools is a part of the process, cross-checking the feature support with various browsers before putting it out in the market. Another important aspect is the use of polyfills and feature detection. This is a preventive measure which can improve cross-browser compatibility.

8. Use Cross-Browser Friendly Libraries And Frameworks

Most websites are comprised of various third-party libraries and frameworks. These tools help developers to bring in structure, scalability, and security to the web applications. Using the wrong alternatives to these libraries can lead to a variety of cross-browser issues that can range from the incorrect working of library features to the complete framework crash.

To avoid such issues, it is highly recommended to use well known and trusted frameworks that are cross-browser friendly.

Angular JS and React JS are some examples of cross-browser friendly web application development frameworks.
Bootstrap, Animate are examples of trusted CSS libraries.
JQuery is an example of a cross-browser friendly scripting library.

9. Use Separate Stylesheets For Different Browsers

Stylesheets tend to have the capability to quickly turn into a mess. As more and more styles come into the picture, they get bulky and unstructured. In addition to this, if all the styles that cater to different browsers come into the same stylesheet, it becomes a maintenance nightmare.

To navigate from this difficulty, it is beneficial to keep the styles separate for each type of browser that the website supports. Once the separation is complete, it can be included within the same HTML page by using conditional comments which help in invoking the right stylesheet for the right type of browser.

10. Browser-specific Features

Browser-specific features in compatibility testing refer to functionalities or behaviors that are specific to a particular web browser.

Different browsers use different rendering engines (e.g., Blink, Gecko, WebKit), and each has its way of interpreting and displaying web content, so it’s important to test how the website or application is rendered in each browser.

Solution: Verify the website’s layout, design, and interactivity remains consistent across different browsers such as Chrome, Firefox, Safari, Internet Explorer, and Edge. Testing on both desktop and mobile versions of browsers may also be necessary.

11. Media Formats and Codecs Issues

Some browsers may support popular formats like MP4, WebM, or Ogg for video, while others may have limitations or require additional plugins. Different browsers and devices may support different codecs, and compatibility issues can arise if a specific codec is not supported.

Solution: Compatibility testing verifies that the media files encoded with different codecs are played back correctly and consistently across the supported platforms. It also checks to handle different image formats, such as JPEG, PNG, GIF, or SVG.

Support ❤️

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

What is Critical Rendering Path?

Andrew S. — Wed, 09 Jul 2025 18:06:35 +0000

Users predominantly care about a fast and smooth experience when using web applications. If they don’t get these two they won’t visit that website. Research also suggests that web page loading speed and experience are directly related to the customer conversion rate. The higher the page loading speed, the higher the customer conversion.

In one research, Walmart found that for every 1-second improvement in page load time, conversions increased by 2%.

To understand how webpage performance can be optimized, we must understand how a webpage is created on any browser. To understand this, we need to know What is Critical rendering path.

So, What is the Critical Rendering Path or CRP?

A critical rendering path is the step-by-step process carried out to convert HTML, CSS, and JS files into pixels on the screen.

This process has five steps.

DOM construction.
CSSOM construction.
Render Tree Creation.
Layout Process.
Painting.

DOM construction

When the user enters the URL in the address bar, the browser sends a request to the server for an HTML page. The server fulfills the request by sending back an HTML page in the response.

The rendering engine uses the HTML parser to parse the HTML file. The HTML file data will be converted to tokens using the tokenization process.

consider the below HTML file data.

<html>
 <head></head>
 <body>
  <h1 class='cl-head'> Heading </h1>
  <p id ="i-para"> paragraph data </p>
 </body>
</html>

The tokenizer will convert data into tokens.

StartTag:html, StartTag:head EndTag:head, StartTag:body, StartTag:h1, Heading,
EndTag:h1, StartTag:p, paragraph data, EndTag:p, EndTag:body, EndTag:html

Once the tokenization process is over. Tokens created in the tokenization stage will used to create the DOM. Each token will be processed and a node will be created based on the occurrence. Each node will have respective data and attributes. This is how the DOM tree is created.

One thing we need to notice, when we request data, the server sends it chunk by chunk, so the DOM will be constructed incrementally with available data.

CSSOM Construction

While parsing HTML data, if the parser encounters the link or style tags, the browser will initiate the request for the CSS file, and if there are embedded styles within the style tags, those will be available readily. These CSS data will be parsed using CSS parsers. This involves tokenizing the CSS, parsing it into a hierarchical structure of nodes with respective properties and values, and creating the CSS Object Model.

CSSOM won’t be constructed incrementally, like how DOM is created.

Let’s assume we created the CSSOM tree using partial CSS data, and it has a value of .h1 { color: white, background: purple }. When we render it. It will have a Purple background color.

However, We have a h1 value in the CSS file which is not yet requested and it will override the initial value.

If we render this partial CSSOM tree, the rendered page will have a purple background. This is not an expected style. Hence CSSOM tree will be rendered once all the CSS data is parsed

Therefore, CSSOM construction is RENDER BLOCKING.

One thing to note here, while HTML parsing, if the parser encounters style tags it will make a request and it won’t block the parsing. But what if it encounters script a tag?

When parser encounters <script> tag, the browser will request the JS file. The gotcha here is, that the model of the web is synchronous, whenever the parser encounters the script tag, The parsing will be stopped until the file is downloaded, compiled, and executed by the JS engine. This will create a blank screen on the window.

So how do we handle it?

We need to use async or differ attribute in the script tag. These kinds of operations will be executed asynchronously, so they will be parsed and executed in a separate thread.

To handle such requests we have a Speculative Parser. This will only work for external resources that need to be parsed, such as scripts, images, or styles. BTW, it doesn’t modify the DOM tree.

Render Tree Construction

Once the DOM and CSSOM are constructed, a new tree will be created by combining both Object Models, and it is called a Render Tree. The render tree will have all the node elements, except node value with {display: none}. However, the node with the {display: hide} value will be included.

Layout Process

Once the render tree is ready, the Layout process will start. In the layout process, the render engine determines where and how each element of the render tree should be drawn. How much space should be consumed in a given real estate?

The size of the real estate depends on the viewport of the device. If we don’t mention it will take 960px by default. If we want to change the size based on the device we should mention it in the header tag of the HTML as <meta name="viewport" content="width=device-width"> This will help the render engine to consider the viewport of the device before calculating the size and location for each element.

The layout performance depends on the complexity of the render tree structure and complexity. The more the number of nodes, the more it will take time to Layout the elements. It also depends on the changing dimensions and locations, hence avoiding scrolling or animation during this process will improve the layout performance. Also, by considering the batch update we can improve the performance.

Paint

This is the last step of the Rendering Path. In this step, Pixels will be painted on the places determined during the layout process. It involves the conversion of boxes or shapes into pixels and this process is called rasterization.

Often a painting is done on a single surface, however, the render engine does it on different layers. Later these layers will be combined and this process is called layer composition.

The painting of the layers will happen on the CPU and these layers will be uploaded to the GPU to compose them into a single layer.

When there are dynamic changes such as adding extra DOM, changing the position of an element, or changing the font size will cause relayout (reflow), repaint, and invalidation of the cache. Browsers normally try to do minimal possible action in response to changes.

In all these stages there is a chance of introducing delay. Understanding each stage we can optimize the performance of the website.

How to Optimize the CRP?

Identify critical resources in the downloading process.
Prioritize downloading critical assets over non-critical ones.
Use techniques like async or defer tags for non-critical assets such as JS files or images.
Decrease the size of critical assets to reduce the number of requests.

Support ❤️

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

How does Event Loop Work?

Andrew S. — Wed, 09 Jul 2025 17:47:22 +0000

JavaScript is required for every browser to function and manage its interactivity. The code is compiled and executed by the JavaScript Engine within the browser. JavaScript is a single-threaded language. It only handles one task at a time. If we assign another work, it won’t entertain until the current one is finished.

Imagine, you have a task that takes around 1 minute to complete, JavaScript is true to its nature, it will not take another task until it finishes. In this case, the webpage will be stuck for a minute. And the user has to wait until it is completed. Imagine how frustrating it is to wait for a minute and stare at the blank screen.

To overcome this, the browser provides some features, that the JavaScript engine doesn’t, those are Web APIs, such as setTimeout, DOM API, HTTP requests, and so on. Using these we can achieve asynchronous and non-blocking behaviour.

Now the question is, how can we achieve this non-blocking behavior using provided Web APIs and others? Using Event Loop.

Before we understand the Event Loop we will see how code is executed in the JavaScript Engine.

How code is executed in the JavaScript Engine?

Whenever the browser receives the JavaScript file, it sends it to the JavaScript Engine. The code will be stored in the Memory Heap. As the code starts executing, line-by-line code is pushed into the Call Stack. The Call Stack executes the code and returns the value, once the value is returned, that line of code will be popped out.

Let’s see an example:

function foo(){
  console.log("state 1")
  console.log("state 2")
  console.log("state 3")
}

foo()

When the code executes, foo() function will be pushed into the Call Stack and then it will be executed. foo has 3 console statements. the first statement is pushed into the Call Stack, since it is straightforward, it will be executed and return the output “state 1” and it'll be popped out. The second statement will pushed into the stack, executed, and then popped out. similarly, the last statement will be pushed into the stack, executed, and popped out of the stack. Finally, function foo will be popped out of the Call Stack.

1/5 — Function foo is pushed to the CallStack.

2/5 — The first statement is pushed and executed. Once it prints the value, it will be popped out of the Call Stack.

3/5 — The second statement will be pushed, and executed. Once it returns the value, it is popped out.

4/5 — similarly the last statement.

5/5 — Finally, once all the lines of code are executed, function foo will be popped out of the Call Stack.

Event Loop — When code has `setTimeout`.

console.log("state 1");

setTimeout(() => {
  console.log("state 2");
}, 100);

console.log("state 3");

When the JavaScript engine receives this code, the first statement will be pushed into the stack. Since it is a simple console function it will be executed and output will be returned. i.e. “state 1” and popped out of the Call Stack. Now, the second statement will be pushed into the Call Stack. This time, the setTimeout function is Web API, it will given to the Browser Engine to execute. so, this statement will be popped out. Next, 3rd statement will pushed into the Call Stack. it will be executed and popped out of the stack.

We know, we have given one statement to the browser to execute. The browser runs the timers for 100 ms and then it will return the callback function. This callback function will not be directly moved to the Call Stack. Instead, it will be moved to the callback queue. The queue works on a first come first serve principle. The statements which are sent to the browser to execute will all be stored in the queue. Once the call stack is empty, The Event Loop takes the first statement from the queue stack and pushes it to the Call Stack.

Call Stack executes the function, returns values, and then the function will be popped out. Now, Event Loop checks the Call Stack, If the Call Stack is empty, it will take the first item from the queue stack and pushed to the Call Stack. The Call Stack continues its work.

1/4 — The first statement will be pushed to Call Stack and executed. Once the value is printed, it will be popped out.

2/4 — The second statement will be pushed, Since, it is part of the Web API, it will sent to Browser Engine to handle the execution.

3/4 — Now, the last statement will be pushed, executed and once the value is printed it will be popped out of the Call Stack.

4/4 — Event Loop checks the Call Stack, If the Call Stack is empty, it will take the first item from the queue and pushed to the Call Stack. The Call Stack continues its work.

Here is the output of the code:

state 1
state 3
state 2

When code has `setTimeout` and `Promise` both.

The Event Loop’s main function is to check whether the Call Stack is empty or not, If it is empty, push the first item from the queue to the Call Stack until the queue stack is empty.

You might be saying this is for setTimeout, but what about for the Promises? Promises also take time to execute.

Well, In this case, Event Loop works a little bit differently. But not completely different. It just sets different priorities for Promise kind of items.

Let’s see the last example with the promise code.

console.log("state 1");

setTimeout(() => {
  console.log("state 2");
}, 10);

setTimeout(() => {
  console.log("state 4");
}, 100);

Promise.resolve("state 5").then((data) => console.log(data))

console.log("state 3");

In this example, the first statement will be pushed to the Call Stack, executed, and popped out of the Call Stack. Now, the second statement will be pushed to the stack, since is setTimeout, It will be sent to the browser to handle by popping out of the Call Stack. Next, the 3rd statement will be pushed to the Call Stack, which is also web API, and it will be given to the browser to execute. The fourth statement is Promise, Promise is pushed to the stack. It will be sent to the browser engine to handle it by popping out of the Call Stack. Finally, the console statement is pushed, executed, and popped out of the stack.

Now, in the event loop side, The setTimeout functions will be executed and both the callback functions will be pushed to the task queue. Promise will be executed, and it’s .then() function will be pushed to another queue i.e. micro-task queue.

In the Event Loop, we have a Macro-task queue/callback queue(The normal queue we use for the tasks) and a Micro-task queue. Micro-task queue has the highest priority, hence the items in the micros-task will be handled first and then the Macro-task. For every Macro-task queue item, all the items in the micro-task queue will handled. Hence, promise callback will addressed first.

Once the Micro-task queue is empty, Event Loop checks whether the Call Stack is empty or not, if it is empty, it will push the items from the Macro-task queue and the Call Stack executes it and pops out of the Call Stack.

Here is the output:

state 1
state 3
state 5
state 2
state 4

1/8— The first statement will be pushed to Call Stack and executed. Once the value is printed, it will be popped out.

2/8 — The second statement will be pushed, Since, it is part of the Web API, it will sent to Browser Engine to handle the execution.

3/8— The third statement will be pushed, Since, it is also a part of the Web API, it will sent to Browser Engine to handle the execution.

4/8— The fourth statement will be pushed, Since, it is also a part of the Web API, it will sent to Browser Engine to handle the execution.

5/8— Now, the last statement will be pushed, executed and once the value is printed it will be popped out of the Call Stack.

6/8 — The setTimeout functions will be executed as per the delay provided, and the callback functions will be pushed to the task queue. Promise will be executed, and it’s .then() function will be pushed to another queue i.e. micro-task queue.

7/8 — Micro-task queue has the highest priority, hence, the items in the micros-task will be handled first. Event loop pushes the Micro-task queue item into the Call Stack. It will be executed and popped out of it.

8/8 — Once the Micro-task queue is empty, Event Loop picks functions from the Macro-task queue and pushed them to the Call Stack. The Call Stack executes functions and pops out of the it.

Understand Event Loop in Layman terms?

Imagine a big condiment shop with a nice setup of a front counter and kitchen at the backend to prepare items like sandwiches, omelets, Maggie, etc. All the items on the front counter are sold, such as Biscuits, snacks, tea, and other food items like sandwiches, omelets, and Maggie.

It is a busy shop and orders are handled in a queue. The person sitting at the counter takes care of it and he will be very busy handling them.

Whenever he receives an order, he checks, whether the order is delivered immediately or it takes time. If it is delivered immediately it will be served by him. For example, cigarettes or snacks.

If he receives orders like, omelettes, Maggie, or Sandwiches, he knows that it will take time to prepare and deliver. So, he shouts at the kitchen and asks people in the kitchen to prepare. Since he is very busy, he can not track whether the order is ready or not. For that, he keeps an Assistant. His job is to check whether the person on the counter is done with his order handling or not. If he is done will all, then he gives a prepared order to him. He never disturbs him while he was handling the orders.

This assistant has a queue system. Whenever the order is prepared from the kitchen, he keeps it in his queue and based on the order in which it is queued, he will give it to the person on the counter to complete the take order.

If you could see the whole process.

The person who is sitting on the counter and executing the order -> Call Stack.

The kitchen in which items are prepared is -> WebAPIs

The assistant who is helping the person on the counter is -> Event Loop.

The queue he is managing to stack the order is -> callback queue

The assistant can keep other sub-assistant a man and a woman.

The assistant is a kind of womanizer, he always prefers orders that are on the woman’s side. And those will be delivered first. If a woman’s side orders are emptied, then man’s side orders will be served to the counter.

Man sub-assistant is → Macro-task queue

Women sub-assistant is -> Micro-task queue

Support ❤️

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

How do Browsers Work?

Andrew S. — Tue, 08 Jul 2025 19:13:41 +0000

Browser is the way to connect to the internet and access information from around the world. Every day millions of web pages are visited. If you are a web developer, you must know how these browsers work. Because this will help you optimize performance and improve the user experience.

Browser Overview

Users request a web page by entering the URL in the address bar. If it is for the first time, the Browser sends the request to DNS (Domain Name Server) and gets the IP address of the place where the information is stored.
Based on the IP address, It creates a secure TCP connection.
The network layer sends the request to the Server to share the webpage resources.
Server then verifies and analyses the request and sends the data (HTML, CSS, Javascript, Images, Fonts, etc.).
The browser receives the data and using the Rendering Engine renders the web page content. If there is any script to be executed, the browser will use Javascript Engine to compile and execute.
If any data needs to be persisted, that will be cached for further use (So that website performance can be increased by reducing the network calls). It could be for future Network requests or some data calculations.

The browser has a high-level Infrastructure and it has the following components:

User Interface
Network Layer
Browser Engine
Rendering Engine
Javascript Engine
Data Storage Layer

Browser has 4 basic steps to work:

Request
Render
Display
Store

Request

Users request a web page by entering the URL in the address bar. The browser connects with the server and requests the page resource to display it on the screen.

So how does this connection and communication work in the browser?

This is handled by Network Layer. This is how it works under the hood.

Network Layer

When the browser receives a web page URL from the address bar, It checks if the requested page address is already there in the DNS cache, If not, Network Layer establishes the connection with DNS and requests for the IP address of the server.

Network Layer uses this IP address to create the TCP connection with the Server.

If the TCP connection is established over HTTPS, one more roundabout trip happens with the server to build the secure connection, i.e. TLS/SSL. Here server and client decide what kind of cipher will be used to encrypt the communication and the server will send the digital certificate to confirm it’s identity. Once it is verified by the client. Secure connection is established.

Once, the secure connection is established. Network Layer sends the initial HTTPS GET request on behalf of the browser. Most often, an HTML file of the webpage is requested. The server receives the request and it will respond with relevant headers and content of HTML.

Render

The server sends the data. It will be processed using the Render Engine and displayed on the screen. To process this data and display it on the screen, the browser takes the help of Render Engine.

Render Engine

Render Engine uses Critical Rendering Path to convert data into pixels on the screen.

The received HTML document will be parsed using an HTML parser. The parser converts content into tokens, using tokenization. These tokens will used to create the DOM tree. The DOM tree will have the nodes. These nodes contain the content and attributes of each element in the Document.
Next up, style sheet data will be parsed by a CSS parser. The parser converts data into tokens, tokens into CSSOM tree. Though DOM Tree creation and CSSOM creation look similar, however, underneath both use different algorithms. CSSOM is a Tree of nodes with respective style data.
By combining DOM and CSSOM a new tree called Render Tree is created. The Render tree will have all the elements except the element with {display: none} property. It is a hierarchy of nodes, and each node has content, style properties, and attributes to render the elements on the screen.
Based on the availability of Elements in the Render Tree, the Layout process starts. In this process dimensions and position of each element will be calculated to paint where each element should appear on the screen.
After the Layout, the Painting process starts, In painting, Pixels are drawn based on the node information. This is done layer by layer. These layers will be composed.

The rendering engine does this chunk by chuck. The moment it gets the data it will start the process of layout and painting. It will not wait until all the data is downloaded.

Javascript Engine

While parsing HTML document data, we will come across some blocking (Javascript) and non-blocking resources (CSS, fonts, images).

Non-blocking resources will be handled by parsers, whereas blocking resources, Javascript files, are compiled and executed by the Javascript Engine.

The Javascript Engine has two components, a Memory Head and a Call stack.

Memory Heap is the place where all the javascript code is stored.

The call stack is a stack data structure that keeps track of function calls and manages their execution order by Last In First Out manner.

Javascript is a single-threaded language, it executes one task at a time. If it gets multiple tasks, it won’t entertain until it finishes the existing task at hand.

The Javascript engine has to handle multiple tasks like I/O events, data fetching, etc, in such scenarios the task will get stuck and users can see a blank screen or a jank effect on the screen. This blocking issue can be handled by running these tasks asynchronously.

For that, the JS engine uses some browser-provided features like setTimeout, Fetch, DOM API, HTTP, etc., and executes tasks asynchronously using a process called Event Loop.

Learn More about Event Loop Here.

Display

User Interface:

Basically, it is about how the User Interface of any browser should look like. Such as the address bar, Forward/Backward buttons, Home Button, Bookmark menu, Input, etc. Over the period, after many iterations, the whole industry has come to a common design and specification. Along with these, we have a large viewport to display content fetched from the server.

Browser Engine:

The Browser Engine takes care of most of the browser functionality either directly or indirectly.

It handles primitive functionalities like, forward, reload, backward, navigation, bookmarks, alerts, etc.
Any kind of user interaction on the screen will be communicated to the Render Engine.
It uses the Network Layer to communicate with the server.
It manages the browser extension, add-ons, tab handling, history management, etc.
It handles browser security. It not only prevents malicious activity but also protects user privacy.

Storage

Data Storage Layer is the persistence layer, which is used by the browser to save data locally. It could be used to cache data or persist the data or other usages.

There different types of storage are there such as:

Cookies — This is key-value pair Javascript object data. It is stored in the browser memory. It has a max size of 5 MB. It will used during communication between Client and Server.
Local Storage — Local storage is a key-value Javascript object. It has a maximum size of 50MB. It will be used to store the user data, state, auth tokens, etc. The stored data is not cleared, unless the user deletes it.
Session Storage — Session storage data is a key-value pair javascript object and function. The data remains stored until the browser session is active. Once the browser is closed the stored data will be deleted. It has a max size of 5 MB.
IndexedDB — Used for storing large amounts of structured data in the browser.
FileSystem — Provides access to a sandboxed file system within the browser for reading, writing, and manipulating files.
Service Workers — Service Workers are often used to implement offline caching strategies. It is used for intercepting and caching network requests, enabling offline functionality and performance optimizations in web applications.

Support ❤️

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

Storage Engines

Andrew S. — Sat, 05 Jul 2025 18:10:45 +0000

Overview

Choosing the right storage mechanisms for local device storage is crucial when designing your web app. A good storage engine makes sure your information is saved reliably, reduces bandwidth, and improves responsiveness. The right storage caching strategy is a core building block for enabling offline mobile web experiences, which is something more and more users feel should be the case by default.

In this chapter, we'll discuss the available storage APIs and services and will offer some guidelines on how to make the right choice when building your web app.

Data Model

The data storing model determines how data is organized internally. This impacts the entire design of your web app, defines the tradeoffs to making your web app efficient yet solve the problem it should solve. There is no "better" approach and no one-size-fits-all solution as with almost everything related to engineering. So, let's take a look at the data models that you could choose from:

Structured: Data stored in tables with predefined fields, as is typical of SQL based database management systems, lends itself well to flexible and dynamic queries. A prominent example of a structured datastore in the browser is IndexedDB.
Key/Value: Key/Value datastores, and related NoSQL databases, offer the ability to store and retrieve unstructured data indexed by a unique key. Key/Value datastores are like hash tables in the sense that they allow constant-time access to indexed, opaque data. Good examples of key/value datastores are the Cache API in the browser and Apache Cassandra on the server.
Byte Streams: This simple model stores data as a variable in length, opaque string of bytes, leaving any form of internal organization to the application layer. This model is particularly good for file systems and other hierarchically organized blobs of data. Prominent examples of byte stream datastores include file systems and cloud storage services.

Persistence

Storage methods for web apps can be analyzed with respect to the timeframe over which data is made persistent:

Session Persistence: Data in this category is persisted only as long as a single web session or browser tab remains active. An example of a storage mechanism with session persistence is the Session Storage API.
Device Persistence: Data in this category is persisted across sessions and browser tabs/windows, on a particular device. An example of a storage mechanism with device persistence is the Cache API.
Global Persistence: Data in this category is persisted across sessions and devices. Therefore, it is the most robust form of data persistence. It cannot be stored on the device itself, however, which means that you need some sort of server-side storage. We won't discuss it here in detail as this post is focused on storing data on the device itself.

Data persistence in the browser

Nowadays, there are quite a few browser APIs that allow you to store data. We'll go through some of them and create a comparison to make it easier for you to choose the right option.

First, however, there are a few things that you should consider before choosing how to persist your data. Of course, the first thing you have to understand very well is the way your web app is going to be used and later maintained and enhanced. Even if you have the answers to these questions, you may end up with a few options to choose from. So, here is what you should look at:

Browser Support — you should take into account the fact that standardized and well established APIs are preferable, because they tend to be longer lived and more widely supported. Those APIs also enjoy a broader documentation and richer community of developers.
Transactions — sometimes, it is important for a collection of related storage operations to succeed or fail atomically. Databases have traditionally supported this feature using a transaction model, where related updates may be grouped into arbitrary units.
Sync/Async — Some storage APIs are synchronous in the sense that storage or retrieval requests block the currently active thread until the request is completed. Using a synchronous storage API can block the main thread and create a freezing experience for the UI of your web app. If possible, use async APIs.

Comparison

In this section, we take a look at the current APIs available for web developers and compare them across the dimensions described above.

API	Data Model	Persistence	Browser Support	Transactions	Sync/Async
File System	Byte Stream	Device	52%	No	Async
Local Storage	Key/Value	Device	93%	No	Sync

File System API

With the FileSystem API, a web app can create, read, navigate, and write to a sandboxed section of the user's local file system.

The API is broken up into various themes:

Reading and manipulating files: File/Blob, FileList, FileReader.
Creating and writing: Blob(), FileWriter.
Directories and file system access: DirectoryReader, FileEntry/DirectoryEntry, LocalFileSystem.

The File system API is a non-standard API. You shouldn't use it in production web apps since it will not work for every user. There may be large incompatibilities between implementations, and the behavior will probably change in the future.

The File and Directory Entries API interface FileSystem is used to represent a file system. These objects can be obtained from the filesystem property on any file system entry. Some browsers offer additional APIs to create and manage file systems.

This interface will not grant you access to the users' filesystem. Instead, you will have a "virtual drive" within the browser sandbox. If you want to gain access to the users' filesystem, you need to invoke the user by eg. installing a Chrome extension.

Requesting a file system

A web app can request access to a sandboxed file system by calling window.requestFileSystem():

// Note: The file system has been prefixed as of Google Chrome 12:
window.requestFileSystem = window.requestFileSystem || window.webkitRequestFileSystem;
window.requestFileSystem(type, size, successCallback, opt_errorCallback)

if you're calling requestFileSystem() for the first time, new storage is created for your app. It's important to remember that this file system is sandboxed, meaning one web app cannot access another app's files.

After you get access to the file system, you can do most of the standard operations on files and directories.

The FileSystem is quite a different storage option compared to the others as it aims to satisfy client-side storage use cases not well served by databases. Generally, these are applications that deal with large binary blobs and/or share data with applications outside of the context of the browser.

These are good use-cases for the FileSystem API:

Persistent uploader — when a file or directory is selected for upload, it copies the files into a local sandbox and uploads a chunk at a time.
Video game, music, or other apps with lots of media assets
Audio/Photo editor with offline access or local cache for speed -the data blobs are potentially quite large and are read-write.
Offline video viewer — it needs to download large files for later viewing or efficient seek + streaming
Offline Web Mail Client — downloads attachments and stores them locally.

Local Storage

The localStorage API allows you to access a Storage object for the Document's origin. The stored data is saved across browser sessions. localStorage is similar to sessionStorage, except that while data stored in localStorage has no expiration time, data stored in sessionStorage gets cleared when the page session ends — that is, when the page is closed.

Note that data stored in either localStorage or sessionStorage is specific to the origin of the page, which is a combination of the protocol, host and the port.

Session Storage

The sessionStorage property allows you to access a session Storage object for the current origin. sessionStorage is similar to localStorage, briefly explained above. The only difference is that while data stored in localStorage has no expiration set, data stored in sessionStorage gets cleared when the page session ends. A page session lasts for as long as the browser is open and survives over page reloads and restores. Opening a page in a new tab or window will cause a new session to be initiated, which differs from how session cookies work.

Note that data stored in either sessionStorage or localStorage is specific to the origin of the page.

Cookies

A cookie (web cookie, browser cookie) is a small piece of data that the user' server sends to the user's web browser. The browser may store it and send it back with the next request to the same server. Typically, it's used to tell if two requests came from the same browser — keeping a user logged-in, for example. It remembers stateful information for the stateless HTTP protocol.

Cookies have three main use-cases:

Session management — Logins, shopping carts, game scores, or anything else the server should remember
Personalization — User preferences, themes, and other settings
Tracking — Recording and analyzing user behavior

Cookies were once used for general client-side storage. While this was legitimate when they were the only way to store data on the client, nowadays it is recommended to choose modern storage APIs. Cookies gets sent with every request, so they can deteriorate performance (especially when on a mobile data connection).

There are two types of cookies:

Session cookies — They are deleted when the client shuts down. Web browsers may use session restoring, which makes most session cookies permanent, as if the browser was never closed.
Permanent cookies — Instead of expiring when the client closes, permanent cookies expire at a specific date (Expires) or after a specific time period (Max-Age).

Note that confidential or sensitive information should never be stored or transmitted with HTTP Cookies, as the entire mechanism is inherently insecure.

And, as you might have guessed, cookies are widely supported among all browsers.

Cache

The Cache interface provides a storage mechanism for Request / Response object pairs that are cached. Note that the Cache interface is exposed to windowed scopes as well as workers. You don't have to use it in conjunction with service workers, even though it is defined in the service worker spec.

An origin can have multiple, named Cache objects. You are responsible for implementing how your script (e.g. in a ServiceWorker) handles Cache updates. Items in a Cache do not get updated unless explicitly requested; they don't expire unless deleted. Use CacheStorage.open() to open a specific, named Cache object and then call any of the Cache methods to maintain the Cache.

You are also responsible for periodically purging cache entries. Each browser has a hard limit on the amount of cache storage that a given origin can use. Cache quota usage estimates are available via the StorageEstimate API. The browser does its best to manage disk space, but it may delete the Cache storage for an origin. The browser will generally either delete all the data for an origin or none of it. Make sure to version caches by name and use the caches only from the version of the script that they can safely operate on. See Deleting old caches for more information.

The CacheStorage interface represents the storage for Cache objects.

The interface:

Provides a master directory of all the named caches that can be accessed by a ServiceWorker or other type of worker or window scope (you're not limited to only using it with service workers, even though the Service Workers spec defines it)
Maintains a mapping of string names to corresponding Cache objects

Use CacheStorage.open() to obtain a Cache instance.

Use CacheStorage.match() to check if a given Request is a key in any of the Cache objects that the CacheStorage object tracks.

You can access CacheStorage through the global caches property.

IndexedDB

IndexedDB is a way for you to persistently store data inside a user's browser. Because it lets you create web applications with rich query abilities regardless of network availability, these applications can work both online and offline. IndexedDB is useful for applications that store a large amount of data (for example, a catalog of DVDs in a lending library) and applications that don't need persistent internet connectivity to work (for example, mail clients, to-do lists, and notepads).

In this article, it's the storage DB which we're going to discuss in a bit more detail because the rest of the storage APIs are quite well-known. Plus, IndexedDB is getting more and more popular with the increased complexity of web apps nowadays.

The internals of IndexedDB

IndexedDB lets you store and retrieve objects that are stored with a "key." All changes that you make to the database happen within transactions. Like most web storage solutions, IndexedDB follows a same-origin policy. So while you can access stored data within a domain, you cannot access data across different domains.

IndexedDB is an asynchronous API that can be used in most contexts, including WebWorkers. It used to include a synchronous version too, for use in web workers, but this was removed from the spec due to lack of interest by the web community.

IndexedDB used to have a competing spec called WebSQL Database, but it was deprecated by the W3C. While both IndexedDB and WebSQL are solutions for storage, they do not offer the same functionalities. WebSQL Database is a relational database access system, whereas IndexedDB is an indexed table system.

Don't start working with IndexedDB, relying on your assumptions from other types of databases. Instead, you should read the docs carefully. Here are some of the essential concepts that you should have in mind:

IndexedDB databases store key-value pairs — the values can be complex structured objects, and keys can be properties of those objects. You can create indexes that use any property of the objects for quick searching, as well as for a sorted enumeration. Keys can also be binary objects.
IndexedDB is built on a transactional database model — everything you do in IndexedDB always happens in the context of a transaction. Thus, you cannot execute commands or open cursors outside a transaction. Also, transactions auto-commit and cannot be committed manually.
The IndexedDB API is mostly asynchronous — the API doesn't give you data by returning values. Instead, you have to pass a callback function. You don't "store" a value into the database, or "retrieve" a value from the database through synchronous means. Instead, you "request" that a database operation happens. An event notifies you when the operation completes, and the type of event you get informs you if the operation succeeded or failed. It's not that different from the way that XMLHttpRequest (or tons of other JavaScript stuff) works.
IndexedDB uses a lot of requests — requests are objects that receive the success or failure events that were mentioned previously. They have onsuccess and onerror properties, as well as readyState, result, and errorCode properties that tell you the status of the request.
IndexedDB is object-oriented — IndexedDB is not a relational database with tables representing collections of rows and columns. This fundamental difference affects the way you design and build your applications.
IndexedDB does not use Structured Query Language (SQL) — it uses queries on an index that produces a cursor, which you use to iterate across the result set. If you are not familiar with NoSQL systems, read the Wikipedia article on NoSQL.
The same-origin policy applies to IndexedDB — an origin is the domain, the application layer protocol, and the port of a URL of the document where the script is being executed. Each origin has its own associated set of databases. Every database has a name that identifies it within an origin.

IndexedDB limitations

IndexedDB is designed to cover most cases that need client-side storage. It has not been designed, however, for a few cases such as the following:

Internationalized sorting — not all languages sort strings the same way, therefore internationalized sorting is not supported. While the database can't store data in a specific internationalized order, you can sort the data that you've read out of the database yourself.
Synchronization — the API is not designed to take care of synchronizing with a server-side database. You have to write code that synchronizes a client-side indexedDB database with a server-side database.
Full text searching — the API does not have an equivalent of the LIKE operator in SQL.

In addition, be aware that browsers can wipe out the database in the following conditions (ouch):

The user requests a wipeout — Many browsers have settings that let users wipe all data stored for a given website, including cookies, bookmarks, stored passwords, and IndexedDB data.
The browser is in private browsing mode — Some browsers have "private browsing" (Firefox) or "incognito" (Chrome) modes. At the end of the session, the browser wipes out the database.
The disk or quota limit has been reached.
The data is corrupt.

The exact circumstances and browser capabilities change over time, but the general philosophy of the browser vendors is to make the best effort to keep the data when possible.

Choosing the right storage API

As I mentioned already, it's better to choose APIs that are widely supported across as many browsers as possible and which offer asynchronous call models, to maximize UI responsiveness. These criteria lead naturally to the following technology choices:

For offline storage, use the Cache API. This API is available in any browser that supports Service Worker technology necessary for creating offline apps. The Cache API is ideal for storing resources associated with a known URL.
For storing application state and user-generated content, use IndexedDB. This enables users to work offline in more browsers than just those that support the Cache API.

Support ❤️

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

The Internals of Shadow DOM

Andrew S. — Sat, 05 Jul 2025 18:06:21 +0000

Overview

Web Components is a suite of different technologies that allows you to create reusable custom elements.Their functionality is encapsulated away from the rest of your code, and you can utilize them in your web apps.

There are 4 Web Component standards:

Shadow DOM
HTML Templates
Custom elements
HTML Imports

In this article, we'll focus on the Shadow DOM.

Shadow DOM is designed as a tool for building component-based apps. It offers solutions to common problems in web development you've probably experienced:

Isolated DOM: A component's DOM is self-contained (e.g. document.querySelector() won't return nodes in the component's shadow DOM). This also simplifies the CSS selectors across your web app since DOM components are isolated, and it gives you the ability to use more generic id/class names without worrying about naming conflicts.
Scoped CSS: CSS defined inside shadow DOM is scoped to it. Style rules don't leak out and page styles don't interfere with it.
Composition: Design a declarative, markup-based API for your component.

Shadow DOM

This article assumes that you're already familiar with the concept of the DOM and its APIs. If not, you can read a detailed article about it here — https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction.

Shadow DOM is just a normal DOM except for two differences:

How it's created/used in relation to the rest of the page compared to the wah you create and use DOM.
How it behaves in relation to the rest of the page.

In general, you create DOM nodes and append them as children to another element. In the case of shadow DOM, you create a scoped DOM tree that's attached to the element yet it's separate from its actual children. This scoped subtree is called a shadow tree. The element it's attached to is its shadow host. Anything you add to the shadow tree becomes local to the hosting element, including <style>. This is how shadow DOM achieves CSS style scoping.

Creating Shadow DOM

A shadow root is a document fragment that gets attached to a "host" element. The moment you attach a shadow root is when the element gains its shadow DOM. To create shadow DOM for an element, call element.attachShadow():

var header = document.createElement('header');
var shadowRoot = header.attachShadow({mode: 'open'});
var paragraphElement = document.createElement('p');

paragraphElement.innerText = 'Shadow DOM';
shadowRoot.appendChild(paragraphElement);

The specification defines a list of elements that can't host a shadow tree.

Composition in Shadow DOM

Composition is one the most important features of Shadow DOM.

When writing HTML, composition is the way you construct your web app. You combine and nest different building blocks (elements) such as <div>, <header>, <form> and others in order to build the UI you need for your web app. Some of these tags even work with each other.

Composition defines why elements such as <select>, <form>, <video> and others are flexible and accept specific HTML elements as children in order to do something special with them.

For example, <select> knows how to render <option> elements into a dropdown widget with pre-defined items.

Shadow DOM introduces the following features which can be used to achieve composition.

Light DOM

This is the markup a user of your component writes. This DOM lives outside the component's shadow DOM. It is the element's actual children. Imagine that you've created a custom component called <better-button> which extends the native HTML button and you want to add an image and some text inside it. This is how it looks like:

<extended-button>
  <!-- The image and span are extended-button's light DOM -->
  <img src="boot.png" slot="image">
  <span>Launch</span>
</extended-button>

The "extended-button" is the custom component that you have defined, while the HTML inside it is called Light DOM and is added by the user of your component.

The Shadow DOM here is the component you have created ("extended-button"). Shadow DOM is local to the component and defines its internal structure, scoped CSS, and encapsulates your implementation details.

Flattened DOM tree

The result of the browser distributing the light DOM, that's been created by the user into your shadow DOM and which has defined your custom component, renders the final product. The flattened tree is what you ultimately see in the DevTools and what's rendered on the page.

<extended-button>
  #shadow-root
  <style>…</style>
  <slot name="image">
    <img src="boot.png" slot="image">
  </slot>
  <span id="container">
    <slot>
      <span>Launch</span>
    </slot>
  </span>
</extended-button>

Templates

When you have to repeatedly reuse the same markup structures on a web page, it's better to use some kind of a template rather than repeat the same structure over and over again. This was possible before, but it is made a lot easier by the HTML element (which is well-supported in modern browsers). This element and its contents are not rendered in the DOM but it can still be referenced using JavaScript.

Let's look at a quick trivial example:

<template id="my-paragraph">
  <p> Paragraph content. </p>
</template>

This won't appear in your page until you reference it with JavaScript, and then append it to the DOM using something like the following:

var template = document.getElementById('my-paragraph');
var templateContent = template.content;

document.body.appendChild(templateContent);

Templates are useful on their own but they work even better with custom elements. We'll define custom elements in another post of the series, for the time being you should know that the customElement API in the browser allows you to define your own tags with custom rendering.

Let's define a web component that uses our template as the content of its shadow DOM. We'll call it <my-paragraph>:

customElements.define('my-paragraph',
  class extends HTMLElement {
    constructor() {
      super();

      let template = document.getElementById('my-paragraph');
      let templateContent = template.content;
      const shadowRoot = this.attachShadow({mode: 'open'}).appendChild(templateContent.cloneNode(true));
    }
});

The key point to note here is that we appended a clone of the template content to the shadow root, that's been created using the Node.cloneNode() method.

And because we are appending its contents to a shadow DOM, we can include some styling information inside the template in a <style> element, which is then encapsulated inside the custom element. This wouldn't work if we just appended it to the standard DOM.

For example, we can change our template to the following:

<template id="my-paragraph">
  <style>
    p {
      color: white;
      background-color: #666;
      padding: 5px;
    }
  </style>

  <p>Paragraph content. </p>
</template>

Now the custom component we have defined with our template can be used like this: <my-paragraph></my-paragraph>.

Slots

Templates have a few downsides, the main one being the static content which doesn't allow us to render our variables/data in order to make it work the way standard HTML templates you're used to do.

This is where the <slot> comes into the picture.

You can think of slots as placeholders that allow you to put your own HTML in the template. This allows you to create generic HTML templates and then make them customizable by adding slots.

Let's see how the above template will look like with a slot:

<template id="my-paragraph">
  <p> 
    <slot name="my-text">Default text</slot> 
  </p>
</template>

If the slot's content isn't defined when the element is included in the markup, or if the browser doesn't support slots, <my-paragraph> will just contain the fallback content "Default text".

To define the slot's content, we should include an HTML structure inside the <my-paragraph> element with a slot attribute whose value is equal to the name of the slot we want it to fill.

As before, this can be anything you like:

<my-paragraph>
  <span slot="my-text">Let's have some different text!</span>
</my-paragraph>

Elements that can be inserted into slots are known as Slotable; when an element has been inserted into a slot, it is said to be slotted.

Note that in the above example we have inserted a <span> element which is the slotted element. It has an attribute slot that's equal to "my-text" which is the same as the value of the name attribute in the template's slot definition.

After being rendered in the browser, the above code will create the following Flattened DOM tree:

<my-paragraph>
  #shadow-root
  <p>
    <slot name="my-text">
      <span slot="my-text">Let's have some different text!</span>
    </slot>
  </p>
</my-paragraph>

Note the #shadow-root element — it's just an indicator that Shadow DOM exists.

Styling

A component that uses shadow DOM can be styled by the main page, can define its own styles, or provide hooks in the form of CSS custom properties for users to override defaults.

Component-defined styles

Scoped CSS is one of the greatest features of Shadow DOM:

CSS selectors from the outer page don't apply inside your component.
Styles defined inside your component don't impact the rest of the page. They're scoped to the host element.

CSS selectors used inside Shadow DOM apply locally to the component. In practice, this means we can use common id/class names again, without worrying about conflicts elsewhere on the page. Simple CSS selectors mean better performance.

Let's take a look at the following #shadow-root that defines some styles:

#shadow-root
<style>
  #container {
    background: white;
  }
  #container-items {
    display: inline-flex;
  }
</style>

<div id="container"></div>
<div id="container-items"></div>

All the styles in the above example are local for the #shadow-root.

You can also use the <link> element to include stylesheets in the #shadow-root which are also local.

The :host pseudo-class

The :host allows you to select and style the element hosting a shadow tree:

<style>
  :host {
    display: block; /* by default, custom elements are display: inline */
  }
</style>

There's one thing you should be careful with when it comes to :host — rules in the parent page have higher priority than :host rules defined in the element. This allows users to override your top-level styling from the outside. Also, :host only works in the context of a shadow root, so you can't use it outside of a Shadow DOM.

The functional form of :host(<selector>) allows you to target the host if it matches a <selector>. This is a great way for your component to encapsulate behavior that reacts to user interaction or state, and style internal nodes based on the host:

<style>
  :host {
    opacity: 0.4;
  }

  :host(:hover) {
    opacity: 1;
  }

  :host([disabled]) { /* style when host has disabled attribute. */
    background: grey;
    pointer-events: none;
    opacity: 0.4;
  }

  :host(.pink) > #tabs {
    color: pink; /* color internal #tabs node when host has class="pink". */
  }
</style>

Theming and element with the :host-context() pseudo-class

The :host-context(<selector>) pseudo class matches the host element if the latter or any of its ancestors matches <selector>.

A common use for this is theming. For example, many people do theming by applying a class to <html> or <body>:

<body class="lightheme">
  <custom-container>
  …
  </custom-container>
</body>

:host-context(.lightheme) would style <fancy-tabs> when it's a descendant of .lightheme:

:host-context(.lightheme) {
  color: black;
  background: white;
}

:host-context() can be useful for theming but an even better approach is to create style hooks using CSS custom properties.

Styling the host element of a component from the outside

You can style the host element of components from the outside by just using their tag name as selector like this:

custom-container {
  color: red;
}

Outside styles have higher priority than styles defined in Shadow DOM.

For example, if the user writes the selector:

custom-container {
  width: 500px;
}

, it will overwrite the component's rule:

:host {
  width: 300px;
}

Styling the component itself will only get you so far. But what happens if you want to style the internals of a component? For that, we need CSS custom properties.

Creating style hooks using CSS custom properties

Users can tweak internal styles if the component's author provides styling hooks using CSS custom properties.

The idea is similar to <slot> but applied to styles.

Let's take a look at the following example:

<!-- main page -->
<style>
  custom-container {
    margin-bottom: 60px;
     - custom-container-bg: black;
  }
</style>

<custom-container background>…</custom-container>

Inside its Shadow DOM:

:host([background]) {
  background: var( - custom-container-bg, #CECECE);
  border-radius: 10px;
  padding: 10px;
}

In this case, the component will use black as the background value since the user provided it. Otherwise, it would default to #CECECE.

As the component author, you're responsible for letting developers know about CSS custom properties they can use. Consider it part of your component's public interface.

Slots JavaScript API

The Shadow DOM API provides utilities for working with slots.

The slotchange event

The slotchange event fires when a slot's distributed nodes change. For example, if the user adds/removes children from the light DOM.

var slot = this.shadowRoot.querySelector('#some_slot');

slot.addEventListener('slotchange', function(e) {
  console.log('Light DOM change');
});

To monitor other types of changes to the light DOM, you can use a MutationObserver in your element's constructor.

The assignedNodes() method

It could be useful to know what elements are associated with a slot. Calling slot.assignedNodes(), gives you which elements the slot is rendering. The {flatten: true} option will also return a slot's fallback content (if no nodes are being distributed).

Let's look at the following example:

<slot name='slot1'><p>Default content</p></slot>

Let's assume that this is in a component called <my-container>.

Let's take a look at the different usages of this component and what will be the result of calling assignedNodes():

In the first case, we'll add our own content to the slot:

<my-container>
  <span slot="slot1"> container text </span>
</my-container>

Calling assignedNodes() will result in [<span slot="slot1"> container text </span>]. Note that the result is an array of nodes.

In the second case, we'll leave the content empty:

<my-container> </my-container>

The result of calling assignedNodes() will return an empty array [].

If you, however, pass the {flatten: true} parameter for the same element, you will get the default content as a result: [<p>Default content</p>].

Also, to reach an element inside a slot, you can call assignedNodes() to see which of the component slots your element is assigned to.

Event Model

It's interesting to note what happens when an event that takes place within the Shadow DOM bubbles up.

The target of the event is adjusted to maintain the encapsulation that is provided by the Shadow DOM. When an event is re-targeted, it looks like it's coming from the component itself, rather than the internal element in the Shadow DOM that is part of the component.

Here is a list of events that propagate out of the Shadow DOM(there are some that don't):

Focus Events: blur, focus, focusin, focusout
Mouse Events: click, dblclick, mousedown, mouseenter, mousemove, etc.
Wheel Events: wheel
Input Events: beforeinput, input
Keyboard Events: keydown, keyup
Composition Events: compositionstart, compositionupdate, compositionend
DragEvent: dragstart, drag, dragend, drop, etc.

Custom Events

Custom events don't propagate outside of the Shadow DOM by default. If you want to dispatch a custom event and want it to propagate, you need to add bubbles: true and composed: true as an option.

Let's see how dispatching such an event might look like:

var container = this.shadowRoot.querySelector('#container');

container.dispatchEvent(new Event('containerchanged', {bubbles: true, composed: true}));

Browser support

To detect whether Shadow DOM is a supported feature, check for the existence of attachShadow:

const supportsShadowDOMV1 = !!HTMLElement.prototype.attachShadow;

Support ❤️

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

WebSockets and HTTP/2 with SSE

Andrew S. — Sat, 05 Jul 2025 17:59:51 +0000

Intro

Nowadays complex web apps that feature rich, dynamic UIs are taken for granted. And it's not surprising — the internet has come a long way since its inception.

Initially, the internet wasn't built to support such dynamic and complex web apps. It was conceived to be a collection of HTML pages, linking to one another to form the concept of "web" that contains information. Everything was largely built around the so-called request/response paradigm of HTTP. A client loads up a page and then nothing happens until the user clicks and navigates to the next page.

Around 2005, AJAX was introduced and a lot of people started to explore the possibilities of making connections between a client and а server bidirectional. Still, all HTTP communication was steered by the client, which required user interaction or periodic polling to load new data from the server.

Making HTTP "bidirectional"

Technologies that enable the server to send data to the client "proactively" have been around for quite some time. "Push" and "Comet" to name a few.

One of the most common hacks to create the illusion that the server is sending data to the client is called long polling. With long polling, the client opens an HTTP connection to the server which keeps it open until a response is sent. Whenever the server has new data that has to be sent, it transmits it as a response.

Let's see how a very simple long polling snippet might look like:

(function poll(){
  setTimeout(function(){
    $.ajax({
      url: 'https://api.example.com/endpoint',
      success: function(data) {
        // Do something with `data`
        // ...

        // Setup the next poll recursively
        poll();
      },
      dataType: 'json'
    });
  }, 10000);
})();

This is basically a self-executing function that runs the first time automatically. It sets up the ten (10) second interval and after each async Ajax call to the server, the callback calls ajax again.

Other techniques involve Flash or XHR multipart request and the so-called htmlfiles.

All these workarounds share the same problem though: they carry the overhead of HTTP, which doesn't make them well-suited for low-latency applications. Think multiplayer first-person shooter games in the browser or any other online game with a realtime component.

The introduction of WebSockets

The WebSocket specification defines an API establishing "socket" connections between a web browser and a server. In plain words: there is a persistent connection between the client and the server and both parties can start sending data at any time.

The client establishes a WebSocket connection through a process known as the WebSocket handshake. This process starts with the client sending a regular HTTP request to the server. An Upgrade header is included in this request which informs the server that the client wishes to establish a WebSocket connection.

Let's see how opening a WebSocket connection looks like on the client side:

// Create a new WebSocket with an encrypted connection.
var socket = new WebSocket('ws://websocket.example.com');

WebSocket URLs use the ws scheme. There is also wss for secure WebSocket connections which is the equivalent of HTTPS.

This scheme just starts the process of opening a WebSocket connection towards websocket.example.com.

Here is a simplified example of the initial request headers.

GET ws://websocket.example.com/ HTTP/1.1
Origin: http://example.com
Connection: Upgrade
Host: websocket.example.com
Upgrade: websocket

If the server supports the WebSocket protocol, it will agree to the upgrade and will communicate this through the Upgrade header in the response.

Let's see how this can be implemented in Node.JS:

// We'll be using the https://github.com/theturtle32/WebSocket-Node
// WebSocket implementation
var WebSocketServer = require('websocket').server;
var http = require('http');

var server = http.createServer(function(request, response) {
  // process HTTP request. 
});
server.listen(1337, function() { });

// create the server
wsServer = new WebSocketServer({
  httpServer: server
});

// WebSocket server
wsServer.on('request', function(request) {
  var connection = request.accept(null, request.origin);

  // This is the most important callback for us, we'll handle
  // all messages from users here.
  connection.on('message', function(message) {
    // Process WebSocket message
  });

  connection.on('close', function(connection) {
    // Connection closes
  });
});

After the connection is established, the server replies by upgrading:

HTTP/1.1 101 Switching Protocols
Date: Wed, 25 Oct 2017 10:07:34 GMT
Connection: Upgrade
Upgrade: WebSocket

Once the connection has been established, the open event will be fired on your WebSocket instance on the client side:

var socket = new WebSocket('ws://websocket.example.com');

// Show a connected message when the WebSocket is opened.
socket.onopen = function(event) {
  console.log('WebSocket is connected.');
};

Now that the handshake is complete the initial HTTP connection is replaced by a WebSocket connection that uses the same underlying TCP/IP connection. At this point, either party can start sending data.

With WebSockets, you can transfer as much data as you like without incurring the overhead associated with traditional HTTP requests. Data is transferred through a WebSocket as messages, each of which consists of one or more frames containing the data you are sending (the payload). In order to ensure the message can be properly reconstructed when it reaches the client each frame is prefixed with 4–12 bytes of data about the payload. Using this frame-based messaging system helps to reduce the amount of non-payload data that is transferred, leading to significant reductions in latency.

Note: It's worth noting that the client will only be notified about a new message once all of the frames have been received and the original message payload has been reconstructed.

WebSocket URLs

We briefly mentioned before that WebSockets introduce a new URL scheme. In reality, they introduce two new schemes: ws:// and wss://.

URLs have scheme-specific grammar. WebSocket URLs are special in that that they do not support anchors ( #sample_anchor ).

The same rules apply to WebSocket style URLs as to HTTP style URLs. ws is unencrypted and has port 80 as default, while wss requires TLS encryption and has port 443 as default.

Framing protocol

Let's take a deeper look at the framing protocol. This is what the RFC provides us with:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
     |N|V|V|V|       |S|             |   (if payload len==126/127)   |
     | |1|2|3|       |K|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |Masking-key, if MASK set to 1  |
     +-------------------------------+-------------------------------+
     | Masking-key (continued)       |          Payload Data         |
     +-------------------------------- - - - - - - - - - - - - - - - +
     :                     Payload Data continued ...                :
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                     Payload Data continued ...                |
     +---------------------------------------------------------------+

As of the WebSocket version specified by the RFC, there's only a header in front of each packet. It's quite a complex header, however. Here are its building blocks explained:

fin (1 bit): indicates if this frame is the final frame that makes up the message. Most of the time the message fits into a single frame and this bit will always be set. Experiments show that Firefox makes a second frame after 32K.
rsv1, rsv2, rsv3 (1 bit each): must be 0 unless an extension is negotiated that defines meanings for non-zero values. If a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value, the receiving endpoint must fail the connection.
opcode (4 bits): says what the frame represents. The following values are currently in use: 0x00: this frame continues the payload from the previous. 0x01: this frame includes text data. 0x02: this frame includes binary data. 0x08: this frame terminates the connection. 0x09: this frame is a ping. 0x0a: this frame is a pong. (As you can see, there are enough values unused; they've been reserved for future use).
mask (1 bit): indicates if the connection is masked. As it stands right now, every message from a client to a server must be masked and the spec would want to terminate the connection if it's unmasked.
payload_len (7 bits): the length of the payload. WebSocket frames come in the following length brackets: 0–125 indicates the length of the payload. 126 means that the following two bytes indicate the length, 127 means the next 8 bytes indicate the length. So the length of the payload comes in ~7bit, 16bit, and 64bit brackets.
masking-key (32 bits): all frames sent from the client to the server are masked by a 32-bit value that is contained within the frame.
payload: the actual data which most likely is masked. Its length is the length of the payload_len.

Why are WebSockets frame-based and not stream-based? I don't know and just like you, I'd love to learn more, so if you have an idea, feel free to add comments and resources in the responses below. Also, a good discussion on the topic is available on HackerNews.

Data on the frames

As mentioned above, the data can be fragmented into multiple frames. The first frame that transmits the data has an opcode on it that indicates what sort of data is being transmitted. This is necessary because JavaScript has pretty much nonexistent support for binary data at the time the specification was started. 0x01 indicates utf-8 encoded text data, 0x02 is binary data. Most people will transmit JSON in which case you'd probably want to choose the text opcode. When you emit binary data it will be represented in a browser specific Blob.

The API for sending data through a WebSocket is very simple:

var socket = new WebSocket('ws://websocket.example.com');

socket.onopen = function(event) {
  socket.send('Some message'); // Sends data to server.
};

When the WebSocket is receiving data (on the client side), a message event is fired. This event includes a property called data that can be used to access the contents of the message.

// Handle messages sent by the server.
socket.onmessage = function(event) {
  var message = event.data;
  console.log(message);
};

You can easily explore the data in each of the frames in your WebSocket connection using the Network Tab inside Chrome DevTools:

Fragmentation

Payload data can be split up into multiple individual frames. The receiving end is supposed to buffer them up until the fin bit is set. So you can transmit the string "Hello World" in 11 packages of 6 (header length) + 1 byte each. Fragmentation is not allowed for control packages. However, the specification wants you to be able to handle interleaved control frames. That's in case TCP packages arrive in arbitrary order.

The logic for joining frames is roughly the following:

receive the first frame
remember opcode
concatenate frame payload together until the fin bit is set
assert that the opcode for each package is zero

The primary purpose of fragmentation is to allow sending a message that is of unknown size when the message is started. With fragmentation, a server may choose a reasonable size buffer and, when the buffer is full, write a fragment to the network. A secondary use case for fragmentation is for multiplexing, where it is not desirable for a large message on one logical channel to take over the whole output channel, so the multiplexing needs to be free to split the message into smaller fragments to better share the output channel.

What is Hearbeating?

At any point after the handshake, either the client or the server can choose to send a ping to the other party. When the ping is received, the recipient must send back a pong as soon as possible. That's a heartbeat. You can use it to make sure that the client is still connected.

A ping or pong is just a regular frame, but it's a control frame. Pings have an opcode of 0x9, and pongs have an opcode of 0xA. When you get a ping, send back a pong with the exact same Payload Data as the ping (for pings and pongs, the max payload length is 125). You might also get a pong without ever sending a ping. Ignore it if it happens.

Heartbeating can be very useful. There are services (like load balancers) that will terminate idle connections. Plus, it's not possible for the receiving side to see if the remote side has terminated. Only at the next send would you realize that something went wrong.

Handling Errors

You can handle any errors that occur by listening out for the error event.

It looks like this:

var socket = new WebSocket('ws://websocket.example.com');

// Handle any error that occurs.
socket.onerror = function(error) {
  console.log('WebSocket Error: ' + error);
};

Closing the Connection

To close a connection either the client or server should send a control frame with data containing an opcode of 0x8. Upon receiving such a frame, the other peer sends a Close frame in response. The first peer then closes the connection. Any further data received after closing the connection is then discarded.

This is how you initiate the closing of a WebSocket connection from the client:

// Close if the connection is open.
if (socket.readyState === WebSocket.OPEN) {
  socket.close();
}

Also, in order to perform any clean up after the closing has completed, you can attach an event listener to the close event:

// Do necessary clean up.
socket.onclose = function(event) {
  console.log('Disconnected from WebSocket.');
};

The server has to listen on the close event in order to process it if needed:

connection.on('close', function(reasonCode, description) {
  // The connection is getting closed.
});

How do WebSockets and HTTP/2 compare?

While HTTP/2 has a lot to offer, it doesn't completely replace the need for existing push/streaming technologies.

The first important thing to notice about HTTP/2 is that it's not a replacement for all of HTTP. The verbs, status codes and most of the headers will remain the same as today. HTTP/2 is about improving the efficiency of the way data is transferred on the wire.

Now, if we compare HTTP/2 to WebSocket, we can see a lot of similarities:

As we have seen above, HTTP/2 introduces Server Push which enables the server to proactively send resources to the client cache. It does not, however, allow for pushing data down to the client application itself. Server pushes are only processed by the browser and do not pop up in the application code, meaning there is no API for the application to get notifications for those events.

This is where Server-Sent Events (SSE) become very useful. SSE is a mechanism that allows the server to asynchronously push the data to the client once the client-server connection is established. The server can then decide to send data whenever a new "chunk" of data is available. It can be considered as a one-way publish-subscribe model. It also offers a standard JavaScript client API named EventSource implemented in most modern browsers as part of the HTML5 standard by W3C. Note that browsers that do not support EventSource API can be easily polyfilled.

Since SSE is based on HTTP, it has a natural fit with HTTP/2 and can be combined to get the best of both: HTTP/2 handling an efficient transport layer based on multiplexed streams and SSE providing the API up to the applications to enable push.

To fully understand what Streams and Multiplexing are all about, let's first have a look at the IETF definition: a "stream" is an independent, bidirectional sequence of frames exchanged between the client and server within an HTTP/2 connection. One of its main characteristics is that a single HTTP/2 connection can contain multiple concurrently open streams, with either endpoint interleaving frames from multiple streams.

We have to remember that SSE is HTTP-based. It means that with HTTP/2, not only can several SSE streams be interleaved onto a single TCP connection, but the same can also be done with a combination of several SSE streams (server to client push) and several client requests (client to server). Thanks to HTTP/2 and SSE, now we have a pure HTTP bidirectional connection with a simple API to let application code register to server pushes. Lack of bidirectional capabilities has often been perceived as a major drawback when comparing SSE to WebSocket. Thanks to HTTP/2 this is no longer the case. This opens up the opportunity to skip WebSockets and stick to an HTTP-based signaling instead.

How to choose between WebSocket and HTTP/2?

WebSockets will certainly survive the domination of HTTP/2 + SSE, mainly because it's a technology already well adopted and, in very specific use cases, it has an advantage over HTTP/2 as it has been built for bidirectional capabilities with less overhead (e.g. headers).

Say you want to build a Massive Multiplayer Online Game that needs a huge amount of messages from both ends of the connection. In such a case, WebSockets will perform much, much better.

In general, use WebSockets whenever you need a truly low-latency, near realtime connection between the client and the server. Keep in mind that this might require rethinking how you build your server-side applications, as well as shifting the focus on technologies like event queues.

If your use case requires displaying real-time market news, market data, chat applications, etc., relying on HTTP/2 + SSE will provide you with an efficient bidirectional communication channel while reaping the benefits from staying in the HTTP world:

WebSockets can often be a source of pain when considering compatibility with existing web infrastructure as it upgrades an HTTP connection to a completely different protocol that has nothing to do with HTTP.
Scale and security: Web components (Firewalls, Intrusion Detection, Load Balancers) are built, maintained and configured with HTTP in mind, an environment that large/critical applications will prefer in terms of resiliency, security, and scalability.

Support ❤️

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

@layer in CSS

Andrew S. — Sun, 27 Apr 2025 15:49:24 +0000

Overview

The @layer directive, the optional layer() function, and the layer keyword give you the ability to control cascading layers.

Cascading layers is a way of grouping and ordering styles in a single source. They help browsers understand which styles to apply on a site.

The source in CSS is where the browser gets its CSS rules from. This can be your styles on the site, user settings in the browser and system, and default browser styles. Learn more about this and other concepts in the Cascade Principle article.

Example

With cascading layers, you directly manage layers with different sets of CSS rules and decide which styles are specific and in what order to apply them. So they are useful for:

resetting browser default styles;
overwriting styles from CSS frameworks and libraries;
styling components;
storing styles in one place, for example, for the states of - interactive elements;
colour themes, schemes and support for different colour modes.

For example, here are the styles with @layer for the state of the button when in focus and when inactive. In the states layer we set the styles for :disabled and :focus-visible, and in components we set the button's default styles.

@layer components, states;

@layer components {
  .button {
    display: block;
    min-width: 210px;
    border: 2px solid transparent;
    border-radius: 6px;
    padding: 9px 15px;
    color: #000000;
    font-size: 18px;
    font-weight: 300;
    font-family: inherit;
    transition: background-color 0.2s linear;
  }

  .button:hover {
    background-color: #FFFFFF;
    cursor: pointer;
    transition: background-color 0.2s linear;
  }
}

@layer states {
  :focus-visible {
    border: 2px solid #FFFFFF;
    outline: none;
  }

  :disabled {
    background-color: #DDDDDD;
  }
}

Without cascading layers, we need to set styles to the .button class with the right pseudo classes. At the same time, we can't store them in one place in the file so that other developers don't accidentally overwrite them.

.button {
  /* CSS-rules */
}

.button:hover {
  /* CSS-rules */
}

.button:focus-visible {
  /* CSS-rules */
}

.button:disabled {
  /* CSS-rules */
}

With cascading layers, it's easier to defeat third-party styles. For example, from Bootstrap. Let's imagine that we want to change the size of the first level header without painful search for the necessary Sass variables.

<h1 class="fs-1">Recent Updates</h1>

Bootstrap Styles:

.fs-1 {
  font-size: 2.5rem !important;
}

Our styles using cascading layers:

@import url("https://cdn.com/bootstrap.min.css") layer;

@layer {
  .fs-1 {
    font-size: 3rem;
  }
}

With older CSS features, this problem has to be solved in several ways. For example, with the !important modifier.

.fs-1 {
  font-size: 3rem !important;
}

How to Spell

There are several ways to declare cascading layers:

@layer directive;
layer keyword;
layer() function.

Layers can be named (named) or unnamed (anonymous).

With named layers, you directly control the style order or define it in one place in the CSS file.

Anonymous layers prevent other developers from manipulating the rules in them and ensure that all the rules you need are stored in one place in the file. This is especially useful when replacing styles from a CSS framework with your own.

After compiling styles with cascading layers, you get regular CSS code. In the developer tool, you will notice that your styles are taken from the project file. The rules also tell you what the layer is and what it's called. For example, "Layer typography" or browser styles "Layer user agent stylesheet".

⚠️ Watch the size of the final styles file when you use @layer. With this directive, it's easy to end up with a file with a lot of CSS rules that overwrite each other.

Directive @layer

For named layers, specify a name after the @layer directive and list the necessary rules inside. The name of the layer can be anything in Latin. For example, application, framework, base, utilities, typography or theme. The names must be unique and not repeated. Exception - layers nested in other layers.

@layer any-layer-name {
  /* One or more CSS rules */
}

Layers can be nested within each other - grouped. A layer with others inside it is called a parent layer, and nested layers are called children. Note that a child layer cannot "go beyond" its parent. It cannot be linked to other child layers or even parent cascading layers.

Here, the framework layer is the parent layer, and base and theme are the children:

@layer framework {
  @layer base {
    /* One or more CSS rules */
  }

  @layer theme {
    /* One or more CSS rules */
  }
}

Child layers can have the same names as others outside of its parent. In this example, there are two completely different layers named base and framework.base, because the second base layer is inside the framework:

@layer base {
  /* One or more CSS rules */
}

@layer framework {
  @layer base {
    /* One or more CSS rules */
  }
}

Layers can be listed in one place. Place their names separated by a comma after the @layer directive. Here we collected two layers in one line and got @layer layer-1, layer-2.

@layer layer-1, layer-2;

@layer layer-1 {
  /* One or more CSS rules */
}

@layer layer-2 {
  /* One or more CSS rules */
}

When listing child layers on a single line, specify the name of the parent layer first and the child layer after the dot. For example, we have a parent layer framework and child layers base and theme. When enumerating, the names of the children will be framework.base and framework.theme:

@layer framework.base, framework.theme;

@layer framework {
  @layer base {
    /* One or more CSS rules */
  }

  @layer theme {
    /* One or more CSS rules */
  }
}

Layers can be listed inside @layer as well. In this case, the name of the layer is again made up of the parent and child names. For example, in the framework layer we define the order in which the base styles base and theme dark styles are applied. The CSS rules themselves are stored in separate layers framework.base and framework.theme:

@layer framework {
  @layer base, theme;
}

@layer framework.base {
  /* One or more CSS rules */
}

@layer framework.theme {
  /* One or more CSS rules */
}

You can put other directives in @layer. For example, @media.

@layer framework {
  html {
    color: #000000;
    background: #FFFFFF;
  }

  @media (prefers-color-scheme: dark) {
    html {
      color: #FFFFFF;
      background: #000000;
    }
  }
}

For anonymous layers, only specify the @layer directive with the necessary rules inside.

@layer {
  /* One or more CSS rules */
}

Named layers can be inserted into anonymous layers. Other developers still cannot manipulate styles in them, as their parent remains anonymous. Here there are two children base and typography inside the anonymous layer:

@layer {
  @layer base {
    /* One or more CSS rules */
  }

  @layer typography {
    /* One or more CSS rules */
  }
}

How it Works

The order in which layer styles are applied affects the order in which they are arranged in the file or list. There are also peculiarities in the behaviour of CSS rules within them.

In a layer with CSS rules and another @layer, separate rules win. In this example, the paragraph text will be black (#000000) because the selector with this rule is outside the nested layer:

<p class="text--pink">
 Paragraph
</p>

@layer typography {
  /* I win: */
  p {
    color: #000000;
  }

  /* I lost: */
  @layer content;
}

@layer typography.content {
  p {
    color: #FFFFFF;
  }
}

To avoid confusion, you can always put such rules outside @layer:

/* I lost: */
@layer typography {
  @layer content;
}

@layer typography.content {
  p {
    color: #FFFFFF;
  }
}

/* I win: */
p {
  color: #000000;
}

When the rules aren't nested inside @layer, they always win. For example, here the text will be black despite the styles for the .text--pink class in @layer:

<p class="text--pink">
  Paragraph
</p>

/* I lost: */
@layer typography {
  .text--pink {
    color: #F498AD;
  }
}

/* I win: */
p {
  color: #000000;
}

A separate rule applies even if located above @layer, so the text is still black:

/* I win: */
p {
  color: #000000;
}

/* I lost: */
@layer typography {
  .text--pink {
    color: #F498AD;
  }
}

What if the layers have rules with the !important modifier? In this case, the order is defined as follows:

A layer with @layer with the !important property that sits above the others.
CSS rule outside @layer.
A layer with @layer with no property with !important.

The pink text colour with the !important modifier from the typography layer wins here:

<p class="text--pink">
  Paragraph
</p>

/* I win: */
@layer typography {
  .text--pink {
    color: #F498AD !important;
  }
}

/* I lost: */
p {
  color: #000000 !important;
}

/* I lost too: */
@layer typography {
  p {
    color: #FFFFFF !important;
  }
}

When you list the layers on a single line, the order of the layers is important. The first layer in the list is overwritten by the layer after it, and so on.

In the example, the <p> paragraph text will again be black because layer-2 is after layer-1 and therefore higher in presentation order:

@layer layer-1, layer-2;

/* I lost: */
@layer layer-1 {
  p {
    color: #FFFFFF;
  }
}

/* I win: */
@layer layer-2 {
  p {
    color: #000000;
  }
}

Even if you increase the specificity of a paragraph from layer-1 with id, layer-2 still wins. So the text in the paragraph will remain black:

@layer layer-1, layer-2;

/* I lost: */
@layer layer-1 {
  p#light {
    color: #FFFFFF;
  }
}

/* I win: */
@layer layer-2 {
  p {
    color: #000000;
  }
}

Listing the child layers in a single line works the same way. This example has a parent framework and two children framework.base and framework.theme. The paragraph text will again be black because framework.theme is listed after framework.base:

@layer framework.base, framework.theme;

@layer framework {
  /* I win: */
  @layer theme {
    p {
      color: #000000;
    }
  }

  /* I lost: */
  @layer base {
    p {
      color: #FFFFFF;
    }
  }
}

For anonymous layers, it matters where they are in the file. So you can't add them anywhere like named ones. Below, the anonymous layer is in front of the named base, so the paragraph text is black:

/* I lost: */
@layer {
  p {
    color: #FFFFFF;
  }
}

/* I win: */
@layer base {
  p {
    color: #000000;
  }
}

If you place the anonymous layer after the named base, the text becomes white (#FFFFFFFF):

/* I lost: */
@layer base {
  p {
    color: #000000;
  }
}

/* I win: */
@layer {
  p {
    color: #FFFFFF;
  }
}

Keyword layer

The layer keyword is needed when applying anonymous layer rules when importing styles from another file. This is done with the @import directive.

Specify the word layer after @import and the path to the desired CSS file. To make sure that other styles and developers don't overwrite the rules from the anonymous layer, place it at the very end of the file. This trick helps to gather in one place the most important and basic styles that you don't want to change under any circumstances.

Here we replace the necessary styles from the tailwind.css file with styles from the anonymous layer:

@import url(tailwind.css) layer;

@layer {
  /* One or more rules */
}

You can place an anonymous layer before the @import line as well. In this case, the priority of these styles will be lower than that of the layers behind them.

@layer {
  /* One or more rules */
}

@import url(tailwind.css) layer;

Rules from one anonymous layer can be applied multiple times. Let's use the styles from the anonymous layer in the files base-forms.css, base-links.css and base-buttons.css:

@import url(base-forms.css) layer;
@import url(base-links.css) layer;
@import url(base-buttons.css) layer;

@layer {
  /* One or more rules */
}

layer() function

With layer(), you refer to a specific layer when importing styles from one file to another.

Let's imagine that we need to add our own basic styles for a site where we already use a CSS framework such as Bootstrap. Let's create a base layer with the necessary CSS rules and apply them in bootstrap.css:

@import url(bootstrap.css) layer(base);

@layer base {
  /* One or more rules */
}

layer() gives reuse of styles from the same named layer. Here styles from base are combined with others from headings.css and links.css files:

@import url(buttons.css) layer(base);
@import url(links.css) layer(base);

@layer base {
  /* One or more rules */
}

The function also comes in handy when you need a specific child layer inside an anonymous one. Let's imagine that we are adding our own basic styles for a site where we are using Bootstrap again. Let's create a child layer base inside the anonymous layer and access it directly using layer(base):

@import url(bootstrap.css) layer(base);

@layer {
  @layer base {
    /* One or more rules */
  }
}

All together

Directive, function and keyword can be combined. In this way you can more precisely define the order of layers in one place before declaring styles.

At the beginning of the file, list the layers after @layer. Let's arrange them so that the tailwind layer has a lower priority for overwriting third-party styles, and the application layer has the highest priority for its own styles. On the second line, import styles from tailwind.css and overwrite the necessary ones with the tailwind layer using layer(). After that we will define the CSS rules we need.

@layer default, tailwind, application;
@import url(tailwind.css) layer(tailwind);

@layer default {
  /* One or more rules */
}

@layer application {
  /* One or more rules */
}

@layer tailwind {
  /* One or more rules */
}

@import can be placed between lines with @layer. The result will be the same.

@layer default;
@import url(tailwind.css) layer(tailwind);
@layer application;

@layer default {
  /* One or more rules */
}

@layer application {
  /* One or more rules */
}

@layer tailwind {
  /* One or more rules */
}

If you need to apply multiple layers in the imported file, list them comma-separated on the same line as @import. The specification prohibits importing other files after a single line @layer.

@layer default;
@import url(frameworks.css) layer(bootstrap), layer(tailwind);
@layer application;

@layer default {
  /* One or more rules */
}

@layer application {
  /* One or more rules */
}

@layer bootstrap {
  /* One or more rules */
}

@layer tailwind {
  /* One or more rules */
}

How to Realise

Cascading layers in CSS are similar to layers in image editors like PhotoShop. You can add multiple layers for images to flexibly manage different effects and filters. Since the layers are transparent and don't mix with each other, it's easy to fix a mistake or add a new effect without changing the old one.

@layer, layer, and layer() solve style problems without changing selectors, and help avoid conflicts between different layers due to their position in CSS files. Often these problems arise from multiple style sources. For example, frameworks and libraries that are mostly used in large projects.

Support ❤️

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

Architecture and Design Patterns in Front-End

Andrew S. — Sun, 27 Apr 2025 14:29:08 +0000

Writing comprehensible code is hard.

Each line of code increases the reader's load, so it is difficult to read a lot of code. On the other hand, if the code lacks details and explanations, it is also very difficult to understand its meaning. When writing programmes, we need to keep a balance between brevity and completeness, between abstractions and concreteness.

Finding this balance is helped by solutions that the community perceives as standard, template solutions. Sometimes these solutions get names and become patterns or architectural approaches.

In this article, we will give a brief overview of architectural approaches and design patterns that are used in modern frontend.

Overview

Application architecture is a set of decisions about how application modules will communicate with each other and with the outside world.

Architecture includes approaches: constraints, rules, and heuristics to follow when writing code.

A design pattern is a pattern solution to a frequent architectural problem.

The area of responsibility of design patterns is smaller than that of architecture in general. Patterns help us to solve problems at a "lower level", closer to the code itself. Architecture, on the other hand, solves design problems of the whole system.

To simplify, architecture is the instruction "How to build a house in general", it covers the whole project. And patterns are instructions for specific tasks: "How to drive piles", "How to mix cement", "How to lay wiring".

Architecture in the Front-End

Modern frontend is complex. For complex systems to behave predictably, they need to be managed. Architecture helps solve the challenges of designing such systems.

Why Architecture is Necessary

Humans are not good at predicting the future. It is difficult for us to predict how a programme or its requirements will change. The only thing we know for sure is that the requirements (and therefore the programme) will change.

Proper architecture helps to design and develop the system so that it is easier and more convenient to expand and change.

If communication between modules is regulated, it is easier to replace their implementation with another one.
If communication with the outside world is regulated, there are fewer chances for data leakage.
If the code is divided intelligently, the programme is easier to test.
If the code is organised in a clear way, it takes less time to add new features and search for bugs in old ones.
If the architecture is widely known, immersion into the project is faster.

What Architectural Approaches are Available

We can roughly categorise architectural approaches according to their goals and scope.

Part of the approach assigns responsibility to modules. They define which modules will be responsible for what.

The best known of these approaches is the Model-View-Controller. It distinguishes 3 "types" of tasks, according to which it assigns roles to modules.

Others determine how close each module is to the business logic. These approaches care about which part of the code deals directly with the application task and which part deals with infrastructure tasks.

For example, in a photo processing app, the business logic would be filter functions and the infrastructure tasks would be accessing the phone's camera API.

These approaches divide code into "layers" based on the degree of proximity to business logic. The most common approach among such approaches is the Three-Layer architecture.

The third manages the data flows in the application. They determine how modules communicate with each other: directly, indirectly, or through special services like the event bus.

In frontend, the most probably well-known approach is Flux and its most common implementation, Redux. This is an example of unidirectional data flow.

In addition to it, bidirectional flow is used, such as reactive data updates. We talk about each in detail in the article "Architecture: Data Flows".

Other approaches define the layout of the application. Whether it will be one large programme (monolith) or a set of several smaller programmes (microservices).

What are the Disadvantages of Architecture

Creating, organising, and following an architecture always requires resources: time, money, and mental effort. The choice should be made after comparing the costs and benefits of each candidate approach.

Design Patterns

Some problems are too small to be isolated into an architectural approach, but are common enough to spawn standard solutions. Such standard solutions are called patterns or templates.

For example, the server sends us data in the form of:

{
  some_data: ["Name", "LastName"]
}

And that's what we want them to be:

{
  someData: "Name LastName"
}

There is an Adapter pattern to solve such a problem. It makes an incompatible third-party API suitable for our application.

function serverToClientAdapter(data) {
  return {
    someData: data.some_data.join(" "),
  }
}

There are many such standard solutions. We can divide them into several groups.

Progenitors

Generating patterns help solve problems with the creation of entities or groups of similar entities. They remove unnecessary duplication and make the process of creating entities shorter and more straightforward.

Among the generating patterns we can distinguish:

"Factory";
"Factory Method";
"Abstract Factory."
"Builder."

Structural

Structural patterns help to solve the problems of matching and combining entities. They take care of how entities can use each other.

Among the structural patterns we can distinguish:

"Adapter";
"Decorator";
"Facade";
"Proxy.

Behavioural

Behavioural patterns allocate responsibility between modules and determine exactly how communication will take place.

Among the behavioural patterns we can distinguish:

"Chain of Responsibility."
"Strategy."
"Team."
"Observer."

Architecture and Patterns are not the Goal

Every design approach and pattern is first and foremost a means to solve problems. Developers should not treat them as a goal when writing code.

Sometimes a solution without a complex architecture will be simpler and faster. For example, when developing a prototype, architecture is often unnecessary.

Architectural approaches and patterns are tools. We advise bringing tools to a project as needed and comparing the benefits and costs of each.

Support ❤️

Make a contribution or Subscription to the author's content: Buy me a Coffee, Patreon, PayPal.

DEV Community: Andrew S.

Optimizing Web Application Performance

Overview

1. Minimize HTTP Requests

2. Optimize CSS and JavaScript

3. Compress and Optimize Images

4. Reduce Server Response Time

5. Optimize Database Queries

6. Eliminate Render-Blocking Resources

7. Optimize Web Fonts

8. Enable GZIP Compression

9. Implement Caching Mechanisms

10. Optimize Your Code

11. Use Lazy Loading

12. Database Optimization

13. Monitor and Optimize Performance Regularly

Conclusion

Support ❤️

Ways to Generate Pages: CSR, SSR, SSG, ISR

History

Client-Side Rendering (CSR)

Server-Side Rendering (SSR)

Static Site Generation (SSG)

Incremental Static Regeneration (ISR)

Support ❤️

The Rendering Engine

Overview

Overview of the rendering engine

Rendering engines

The process of rendering

Constructing the DOM tree

Constructing the CSSOM tree

Constructing the render tree

Layout of the render tree

Painting the render tree

Order of processing scripts and style sheets

Optimizing the rendering performance

Optimizing your JavaScript

Optimize your CSS

Optimize the layout

Optimize the paint

Support ❤️

Ways to Avoid Cross-Browser Compatibility Issues

Common Browser Compatibility Issues

1. DOCTYPE Error

2. Browser Detection

3. HTML/ CSS Validation

4. CSS Resets

5. Layout Compatibility

6. Vendor Specific functions

7. Website Feature Functionality

8. Use Cross-Browser Friendly Libraries And Frameworks

9. Use Separate Stylesheets For Different Browsers

10. Browser-specific Features

11. Media Formats and Codecs Issues

Support ❤️

What is Critical Rendering Path?

DOM construction

CSSOM Construction

Render Tree Construction

Layout Process

Paint

How to Optimize the CRP?

Support ❤️

How does Event Loop Work?

How code is executed in the JavaScript Engine?

Event Loop — When code has setTimeout.

When code has setTimeout and Promise both.

Understand Event Loop in Layman terms?

Support ❤️

How do Browsers Work?

Browser Overview

Request

Network Layer

Render

Render Engine

Javascript Engine

Display

User Interface:

Browser Engine:

Event Loop — When code has `setTimeout`.

When code has `setTimeout` and `Promise` both.