We share tips, tutorials, and lessons from recent experiments on the web.

Blog

When building a microfrontend in React using tools like 

 you might expect plain CSS files and CSS modules to just work, but they don’t 😱.

Here is an example of a CSS module in a React component:

import styles from './ConfirmButton.module.css';
...
const ConfirmButton = () => <button className={styles.confirmButton}>Ok</button>;
// It renders something like: <button class="confirmButton_fwi4g3">Ok</button*

And here is how that CSS was injected into DOM by the bundler:


<html>
  <head>
    <style type="text/css">
      .confirmButton_fwi4g3 {
        ...
    </style>
    <my-microfrontend>
      #shadow-root
      <button className="confirmButton_fwi4g3">Ok</button>
    </my-microfrontend>
  </head>
</html>

 tags. In both cases the CSS doesn't get applied to our microfrontend.

The problem is that Shadow DOM prevents CSS from leaking in and out of it, which is the whole point of using it. Styles need to somehow be placed within a web component instance. And when every new web component gets created, the styles must be copied into them as well!

The solution is to extract URLs to the CSS files from a special JSON file and insert them into our Web Components. That special JSON file is called an 

. You can build one using an option in a Webpack/Vite config. Create-React-App generates one by default.

For Webpack you can generate an asset manifest file with 

These files might have slightly different structure, here is an example for Vite:

You will need to filter URLs that end with .css extension. They all are relative to the base URL of your app. If your app is a CommonJS-based bundle, you can discover the base URL from 

 and if you built a ECMAScript module-based bundle use 

export function ProdStyles() {
  const [cssUrls, setCssUrls] = useState(null);
  useEffect(() => {
    const assetManifestUrl = new URL('manifest.json', import.meta.url).toString();
    getAssetsFromWebpack4AssetManifest(assetManifestUrl).then((assets) => {
      setCssUrls(assets.cssUrls);
    });
  }, []);

  return (
    <>
       {cssUrls?.map((url) => (
          <link
            type="text/css"
            rel="stylesheet"
            href={url}
            onError={incrementLinkCount}
            onLoad={incrementLinkCount}
          />
        ))
      )}
    </>
  );
}

const Root = () => {
  // <App> component would ideally only render
  // after all of the CSS assets were loaded,
  // but I omitted the check for simplicity.
  return (
    <>
      <ProdStyles />
      <App />
    </>
  );
}

async function getAssetsFromWebpack4AssetManifest(baseUrl) {
  const getAbsoluteUrl = path => new URL(path, baseUrl).toString();
  const response = await fetch(getAbsoluteUrl('/asset-manifest.json'));
  if (!response.ok) {
    throw new Error('Failed to get manifest');
  }
  const manifest = await response.json();
  const relativeCssUrls = manifest.entrypoints.filter(x => x.endsWith('.css'));
  return {
    cssUrls: relativeCssUrls.map(getAbsoluteUrl),
  };
}

We can make styles apply in development mode in two steps.

 plugin that prepends a comment with some unique web component ID to every CSS file. The ID could literally be the name of your web component, e.g. 

// insert-comment-plugin.js
module.exports = (opts = {}) => {
  return {
    postcssPlugin: "postcss-prepend-comment",
    Root(root, postcss) {
      root.prepend(`/* ${opts.comment} */`);
    },
  };
};
module.exports.postcss = true;

PostCSS config file
//`postcss.config.js`
const insertComment = require("insert-comment-plugin");
module.exports = {
  plugins: [insertComment({ comment: "my-account-page" })],
};

// postcss.config.js
const insertComment = require("insert-comment-plugin");
module.exports = {
  plugins: [insertComment({ comment: "my-account-page" })],
};

export function DevStyles({ webComponentId }) {
  const [container, setContainer] = useState(null);

  useEffect(() => {
    if (!container) {
      return;
    }

    const sourceStylesContainer = document.head;

    const tagIdComment = `/* ${webComponentId} */`;

    const moveStyles = () => {
      container.innerHTML = "";
      container.append(
        ...Array.from(sourceStylesContainer.children)
          .filter(x => x instanceof HTMLStyleElement)
          .filter((x) => x.textContent?.includes(tagIdComment)) // finds all <style> tags containing your web component ID
          .map((x) => x.cloneNode(true)) // copies styles into the current instance of your web component. You might need to have multiple instances, so all of them need to track the styles.
      );
    };

    const observer = new MutationObserver(moveStyles);
    observer.observe(sourceStylesContainer, {
      characterData: true,
      childList: true,
      subtree: true,
    });
    moveStyles();
    return () => {
      observer.disconnect();
    };
  }, [container]);

  return <div ref={setContainer}></div>;

const Root = () => {
  // here will also be your prod CSS fetching logic
  return (
    <>
      <DevStyles webComponentId="my-account-page" />
      <App />
    </>
  );
}

Finally, in Chrome Dev Tools you will see your web component rendered like this:

<my-account-page>
    #shadow-root
    <div>
      <style type="text/css">
        /* my-account-page */
        .confirmButton_fwi4g3 {

That is it, your web component should now correctly apply CSS and not leak it outside.

To wrap my react app into a Web Component I used 

 package. It has quirks but is pretty simple to set up.

If you are choosing your CSS tech, you might want to look into CSS-in-JS solutions, like 

, etc. They usually provide a way to directly inject CSS into your react components with a simple API, completely avoiding the mess with CSS assets. For example, in Emotion you can configure a DOM element you want your CSS to be injected into. User 

When building a microfrontend in React using tools like create-react-app, Webpack, or Vite you might expect plain CSS files and CSS modules to just work, but they don’t 😱.

Here...

Using CSS files in web components

A React application is JavaScript code that gets transformed into static HTML. This transformation is called "rendering".

Whenever you build a React application, you're inevitably making a decision on when to render it and you usually have 3 choices:

Client-side rendering: the application is rendered on the browser when the script loads.

Server-side rendering: the application is rendered on the server at every page request.

Static site generation: the application is rendered on the cloud provider (e.g. 

A while ago, we faced this scenario when 

, an energy news aggregator that showcases thousands of posts daily.

In this article, we'll talk about the performance problems we faced and how we ended up leveraging Next.js and Vercel to solve them.

illuminem's architecture consists of a service that crawls RSS feeds and web pages for energy-related posts, categorizes them, and pushes them to a 

On the CMS, content managers create collections of these posts based on filters like "category".

For example, they can create a collection called "Renewables" and use the "category" filter to only include posts that match the "renewables" category:

Renewables category created from the CMS

The frontend is a Next.js application that fetches these collections and displays them as carousels.

illuminem's architecture

Building a product is not easy because requirements change throughout the process, so we played it safe to make sure we can be flexible enough to handle these changes and reach the finish line ahead of time.

We were not sure how often we'd get new posts from the crawler, so we rendered most of our pages server-side.

 to fetch pages data from the CMS at every request.

Here's a simplified example from the homepage:

export default function HomePageContainer({ data }) {
  return (
    <Layout>
      <HomePage data={data} />
    </Layout>
  );
}

// Called on the server after each request
export async function getServerSideProps() {
  try {
    const data = await fetchHomeDataFromCMS();

    return {
      props: { data },
    };
  } catch (error) {
    console.error("Error fetching homepage data", error);
  }
}

By the time we were done, the crawler had been running for 2 months and we started to feel the heavy page load.

Even after limiting the number of posts per collection, each carousel could have hundreds of posts and most of our pages had dozens of carousels, so we're talking about thousands of posts per page.

On average, it took 5 seconds to load a page on a very good WiFi connection.

It was no surprise that our TTFB (Time to First Byte) was heavily impacted since every time a user visits a page:

The server had to make a request with a huge query to the CMS.

The CMS had to parse that query and form the response data.

Once the server received a response from the CMS with thousands of posts, it had to render the React application before sending it to the browser.

Some of the pages were not making any requests in 

 to get data before rendering. Next.js made these pages static by default.

But what if a page needs to fetch data before building?

 that allows to fetch the data and render the page at build time. This would create static pages that load instantly.

export default function HomePageContainer({ data }) {
  return (
    <Layout>
      <HomePage data={data} />
    </Layout>
  );
}

// Called at build time
export async function getStaticProps() {
  try {
    const data = await fetchHomeDataFromCMS();

    return {
      props: { data },
    };
  } catch (error) {
    console.error("Error fetching homepage data", error);
  }
}

Unfortunately, most of the other pages could not be completely static. In fact, most of them have a "Most Trending" carousel to display the most viewed posts in the past 48 hours, so it had to be up-to-date with the actual views metrics.

If we fetch the data at build time, the "Most Trending" carousel wouldn't be updated until the next build.

Most Trending carousel

At this point, we wondered: why not make these pages render client-side?

The server wouldn't have to make any heavy work querying data and rendering the page.

Instead, each carousel can make a request to fetch its collection of data and then render it.

The main advantage would be that the TTFB would drastically decrease, making the page reach the browser pretty fast.

However, knowing that each page has on average 12-15 carousels, that would result in 12-15 queries per page visit. Our CMS payment plan is based on the number of queries we make, so this would make us reach the limit in no time and would certainly blow up when illuminem picks up more users.

On top of that, what we gain in performance in the server is lost in the client. The page would reach the browser fast, but it will be mostly a bunch of spinners. Each carousel would yet have to make a request to get its data and then render it.

Because of these two reasons, client-side rendering was out of the table.

 in the 9.5 version release, making it possible to generate static pages at run-time.

We can now generate static pages at build time, which makes them load instantly.

But, how can we keep the "Most Trending" carousel content up-to-date?

Every time a user visits one of these pages, 

 is run by the Next.js server in the background.

 is different from the previous run because the CMS data changed, the stale page is replaced by an updated one.

The updated page is generated at run-time without affecting the user experience.

The best part is that we only had to set the 

export default function HomePageContainer({ data }) {
  return (
    <Layout>
      <HomePage data={data} />
    </Layout>
  );
}

// Called at build and run-time
export async function getStaticProps() {
  try {
    const data = await fetchHomeDataFromCMS();

    return {
      props: { data },
      // Revalidates the page every hour
      revalidate: 60 * 60,
    };
  } catch (error) {
    console.error("Error fetching homepage data", error);
  }
}

For pages that depend on a route parameter (e.g. 

), we were able to generate a static page for each possible parameter by using the 

import categories from "../categories";

export default function CategoryPageContainer({ data }) {
  return (
    <Layout>
      <CategoryPage data={data} />
    </Layout>
  );
}

export async function getStaticProps({ params: { category } }) {
  try {
    const data = await fetchCategoryDataFromCMS(category);

    return {
      props: { data },
      revalidate: 1,
    };
  } catch (error) {
    console.error("Error fetching homepage data", error);
  }
}

export async function getStaticPaths() {
  const categories = await fetchCategoriesFromCMS();

  return {
    paths: categories.map((category) => ({
      params: { category },
    })),
  };
}

Solving edge-cases with client-side rendering

Users can click on a post to see its details in a modal and share it on social media.

Modal to share social media

Each post modal has a URL and we could add the 

 tags required to show a card preview snippet on the social media platforms.

Unfortunately, when such URLs are shared, social media platforms could not get the right 

 tags since they are only added once the modal appears in the client.

To fix that, we generated at run-time a static page for each post.

Such pages only have the post modal rendered statically with the right 

 The rest of the page is rendered client-side.

We then used the URLs of these pages when sharing on social media.

export default function PostPage({ postData }) {
  const [homeData, setHomeData] = React.useState({});

  React.useEffect(() => {
    fetchHomeDataFromCMS().then(setHomeData);
  }, []);

  return (
    <>
      <Layout>{!homeData ? null : <HomePage data={homeData} />}</Layout>
      <PostModal data={postData} />
    </>
  );
}

export async function getStaticProps({ params: { postId } }) {
  const postData = await fetchPostDataFromCMS(postId);

  try {
    return {
      props: { postData },
      revalidate: 60 * 60,
    };
  } catch (error) {
    console.error("Error fetching post data", error);

    // Fallback to 404 page in case of error
    return { notFound: true };
  }
}

// Nothing is generated at build time
export async function getStaticPaths() {
  return {
    paths: [],
    fallback: "blocking",
  };
}

 to only return the page once it has finished loading. You can read more about the other 

The first request to such pages might be a bit slow, but all the following requests resolve immediately because their static version was already generated.

Social media platforms display now a proper snippet of the shared post because its required 

 tags are available immediately in the HTML response.

Twitter card validation

Are you building a product with Vercel and Next.js?

If you plan to build or need help building a product using Vercel and Next.js, 

A React application is JavaScript code that gets transformed into static HTML. This transformation is called "rendering".

Whenever you build a React application, you're inevitably...

Using Next.js and Vercel to instantly load a data-heavy website

This post is part of the series Explain Like I'm Five (#eli5), which aims to make tech concepts and terms easy to understand.

In this post, we explain in 4 minutes what a headless CMS is and show you how it's used.

When the web was first introduced, only developers could create and manage websites.

As the Internet expanded and the web became more accessible, non-developers couldn't be kept on the side without the ability to make sites.

As a remedy, Content Management Systems (CMS) came into place, with the purpose to allow its users to create and edit content on a website without any knowledge of code whatsoever.

One could open a CMS, create a website with different pages, place images, write text, and 

, go live without writing a single line of code.

The adoption of this tool increased and so did the number of CMS providers out there.

Of course, it's not all sunshines and roses, building a site with a CMS and not controlling the code comes with its limitations.

For example, the interface cannot be fully customized and styled considering how it is based on templates, meaning that a lot of these websites look alike and can't always have a distinguished brand.

There is also a limitation when it comes to functionality, considering that without code, it is very difficult to build certain features.

Also, if one is able to build and edit a website without code, it is because there is a lot of running code in the background allowing them to do so, and as a result, the 

 is slower and does not match users' expectations.

This begs the question: are we back to square one? Do non-developers have to give up their CMS superpowers for a website to be fast, unique, and customized?

Thankfully, they don't. A new breed of CMS called "headless CMS" came into place to combine the advantages of writing code with some capabilities of the initially described CMS, which we'll refer to as "traditional CMS".

A headless CMS is built solely to handle content, in constrast with the traditional CMS which offered capabilities beyond what it was meant to do (CMS stands for 

 Management System, not Content Design Frontend Backend Hosting Management System).

It's called "headless" because the interface (head) and the content (e.g. text, images) are separated, in contrast with the traditional approach, which entangles both. When both interface and content are glued, it is harder to change the content without breaking the interface.

Also, because it is glued, there is no choice in terms of which technology to use for the interface, meaning the content is "locked" in the traditional CMS interface.

Headless CMS separates interface from content

Also, by separating the content from the interface, it is possible to distribute the content to different interfaces (e.g. smart watch application, mobile application, or an information kiosk). This becomes more relevant as businesses spread their messaging in different platforms and devices.

Centralizing content in one single place avoids inconsistent messaging and outdated content.

Centralized content makes distribution easier

When building a website with a headless CMS, developers focus on writing quality code, and content creators, editors, marketers, and non-developer business people focus on delivering fresh content to users, and what to say, instead of how to present it.

illuminem is an energy news aggregator that launched its first version using a traditional CMS. After validating their idea, they wanted to make their platform more sophisticated with a specific design, faster speed, automated articles sourcing, and machine learning content categorization.

This was impossible with a traditional CMS.

, we've designed and built the interface for them with custom code, and connected it with a headless CMS for them to control, edit, remove, and organize content.

The illuminem team members picked up the headless CMS in a matter of minutes (no learning curve), and are now independently managing their platform without our involvement.

Building a website with a headless CMS requires structuring content in a modular way (build once, use multiple times).

Brands like National Geographic, Nike, Channel, Atlassian, Sonos, Bang & Olufsen, ALDO, Spotify, WeWork, Danone, Peloton, Intercom, Mailchimp, TUI Nordic, Oasics, Zalando, and others, welcomed the headless CMS to their set of tools.

Do I have to give up on traditional CMSes?

Not at all. In some instances, it is still possible to use a traditional CMS (e.g. WordPress) as if it was headless.

To do so, the interface is built independently from the CMS, which only acts as a source of content.

It's less convenient, since CMSes like WordPress were not built to be headless, but doable.

If your business is evaluating such a migration, don't hesitate to 

 (one of our favorite headless CMSes), for a music conference website we've built for a client:

We made it possible to create as many pages as necessary, chose among predefined customized templates (e.g. standard page or artist page), give them a title and set a URL:

Creating pages with Sanity

Select URL for each page

Thanks to the modular structure of the website, the client not only controlled the content but also the structure of the page (e.g. banner at the top, schedule at the bottom):

Modular structure

Text can be edited like on Microsoft Word or Google Docs:

Rich Text editor

Changes can be previewed before publishing them. This made it possible to avoid publishing the wrong content by seeing how the website would look like with the updated content.

Preview Page

The CMS has been used as a storage for some files that were to be downloaded directly from the site:

Storage for documents

It is possible to use the CMS from mobile to make changes on the go:

Sanity Mobile Version

While content in a traditional CMS is locked with the platform, it is possible with Sanity to export the content and move to another headless CMS should that be required, making vendor lock-in inexistent when it comes to content ownership.

Different team members can collaborate to create pages and edit content in real-time.

This post is part of the series Explain Like I'm Five (#eli5), which aims to make tech concepts and terms easy to understand.

In this post, we explain in 4 minutes what a headless...

Explain Like I'm Five: Headless CMS

In this two minutes read, we'll explain why website speed matters, how to measure it, and how to improve it.

A fast website encourages users to stay long enough to purchase products or consider getting in touch.

. Let's look at the most important metrics:

When you type "tinloof.com" on the address bar and hit ENTER, the browser will ask for the page content from tinloof's servers.

The Time to First Byte is the time it takes for tinloof's servers to send the first byte (tiny piece of data) to the browser.

Once the browser receives the page content, it starts painting it.

The First Contentful Paint is the time it takes the browser to paint the first chunk of text or image of the website.

The Largest Contentful Paint is the time it takes the browser to paint the largest visible block of content.

 homepage, the largest visible block of content is the 3D illustration.

Tinloof's largest homepage block

The Time to Interactive is the time it takes for the website to become fully interactive (e.g. you can click on buttons and links).

The previous metrics are quite helpful but they only exist to guide us towards our end goal: provide a good user experience.

In fact, there are some tricks we can do that improve this perceived website speed without affecting the metrics.

For example, we progressively load images on our 

While loading an image, we first show a blurry version of it.

The HD image then replaces the blurry one once it's ready.

Although the final image takes the same time to load without this trick, progressively loading the image gives users the impression it loads faster.

There isn't a magical forumla that will make any website fast. If there was, we wouldn't be writing this article.

However, we'll share two tips that are quite effective in making any website faster.

The most effective way to make a website faster is to keep it as simple as possible.

Why? Because a simple website makes the browser process less code.

To determine a website speed budget, we ask ourselves: what's an acceptable speed for our site?

It's fine to exceed this budget during the implementation phase because the main focus is to make things work ahead of deadlines.

That's when optimizations come into place: we first audit the website speed, identify issues causing the website to be slow, and then do our best to solve them.

If you read the performance section of our 

, you'll see that although we initially exceeded the speed budget, we were able to optimize illuminem to only take 1.3 seconds to load.

This post is part of the series Explain Like I'm Five (#eli5), which aims to make tech concepts and terms easy to understand.

In this two minutes read, we'll explain why website...

Explain Like I'm Five: Website speed

In this post, we explain in two minutes what React is and why it is used.

React is a technology used to build the interfaces of websites and mobile applications. It was created by Facebook and has been made available to the public in 2013.

Since then, it grew in popularity and has been adopted by thousands of companies, including Uber, Netflix, Bloomberg, Walmart, Airbnb, WhatsApp Web, Instagram, PayPal, and The New York Times.

npmtrends

Graph showing the number of React downloads

Code written in React can be reused, both within the same project or across different projects. The idea is to build once and use multiple times.

For example, the "Get in touch" button at the top of this page can be used in different parts of this website or in a totally different website. Let's place it here for demonstration purposes:

Looking at examples, Netflix reuses code to display movies in identical horizontal lists that contain a title (e.g. Award-winning Crime TV Shows) and movie posters:

Netflix carousels

The New York Times has a similar approach:

NYT components

A website written in React can be split into multiple pieces (called "components"), making it easier to plan a project and eventually implement modifications.

Let's take Airbnb's homepage as an example, which has an "Explore nearby" section. If they decide to remove this section, it can easily be done without impacting the rest of the website:

Airbnb components

As we can see in the example above, a React website or application is a bunch of components glued together.

This post is part of the series Explain Like I'm Five (#eli5), which aims to make tech concepts and terms easy to understand.

In this post, we explain in two minutes what React is...