Forem: Kasper Andreassen

Meet the new Core Web Vital: Interaction to Next Paint (INP) 🎨

Kasper Andreassen — Fri, 11 Aug 2023 09:05:43 +0000

In March 2024, Interaction to Next Paint (INP) will replace one of the current Core Web Vitals, First Input Delay (FID).

This is a big deal since Core Web Vitals affect both user experience and your organic rankings on Google (Core Web Vitals became a part of Google's ranking algorithm in 2021).

Before we dive into what Interaction to Next Paint (ICP) is, let's do a quick recap by answering the following questions:

What are Core Web Vitals?
Why are they important?

💡 If you're already familiar with Core Web Vitals, you can skip to the "Meet the new kid on the block: INP"-section.

What is core Web Vitals?

Image source: https://web.dev/vitals/

Core Web Vitals represent a trio of essential user-centric metrics introduced by Google for evaluating and enhancing website performance. These three are:

Largest Contentful Paint (LCP): This metric measures the time the largest visible element takes to appear, influencing the perceived speed of a website's loading process.

First Input Delay (FID): FID measures the responsiveness of a webpage by quantifying the delay between a user's initial interaction (e.g., clicking a button) and the browser's ability to respond. It indicates how smoothly users can interact with a site.

Cumulative Layout Shift (CLS): CLS evaluates visual stability by calculating unexpected layout shifts during page load. These shifts can lead to accidental clicks or confusing user experiences. CLS aims for a smooth loading process without abrupt visual changes.

These metrics collectively offer insights into the user experience journey on a website, covering loading efficiency, interactivity, and visual consistency.

Why are Core Web Vitals important?

A poor user experience can both frustrate and infuriate users.

There are multiple reasons why it's essential to consider Core Web Vitals when developing a website, for instance:

User Experience (UX): Core Web Vitals directly address the factors that influence how users perceive and engage with websites. Websites can create a smoother and more satisfying user journey by focusing on loading speed, interactivity, and visual stability.

Search Engine Optimisation (SEO): Google has integrated Core Web Vitals into its ranking algorithm, making them a critical element for search engine optimisation. Websites that excel in these metrics are more likely to rank higher in search results, leading to increased visibility and organic traffic.

Conversion Rate Optimisation (CRO): Core Web Vitals are crucial in CRO strategies. Improved user experience, stemming from better loading times and interactivity, directly contributes to higher conversion rates. Users are more likely to complete desired actions when they have a seamless and engaging website experience.

Now let's look at the new Core Web Vital that will replace First Input Delay (FID): The new metric, Interaction to Next Paint (INP).

Meet the new kid on the block: INP

You can think of Interaction to Next Paint (INP) as First Input Delay (FID) on steroids 💉

Where FID only measures the first interaction, INP measures all page interactions. That means you get the latency of all the interactions the user has made with a page.

However, you are not getting the value (metric) of each interaction, but instead, a single value which all / nearly all interactions were below (longest interaction observed, ignoring outliers). INP gets calculated when the user leaves the page.

So, where FID tells you something about the first impression, INP tells you something about the overall experience.

A low INP will indicate that the page consistently responded fast to all (or the vast majority) of user interactions.

But why switch out FID with INP? According to Chrome usage data, users spend roughly 90% of the time on a page after it loads. Therefore, responsiveness throughout the page lifecycle is essential in determining the overall user experience. The INP metric precisely evaluates this aspect.

The goal is to provide good responsiveness to the user, which comes when the page responds quickly to the user's interaction. This response will be some sort of visual feedback. Visual feedback tells the user if an item has been added to the shopping cart, a login form is being authenticated, etc.

INP is not about showing the "end result" as quickly as possible but to cue the user that something is happening.

An interaction might be highly complex and take a long time. INP doesn't care how long a network fetch takes but rather how quickly you display visual feedback to the user. This could be with a loading spinner. INP only wants to know how long the next paint is blocked.

Why? Because poor responsiveness can cause multiple unintended responses (e.g., clicking a button too many times), which results in a poor user experience.

We've talked a lot about interactions, so let's look at exactly what an interaction is.

What is an interaction?

Image source: https://web.dev/inp/

The interactivity is often happening through JavaScript. However, native browser controls like checkboxes, radio buttons, and CSS-powered controls also provide interactivity.

INP doesn't measure all interaction types, but only:

Mouse clicking
Tapping on a touchscreen
Keystrokes (pressing a key on a keyboard)

This means that INP does not measure hovering and scrolling unless the user scrolls with their keyboard (space, page up/down, etc.) since this is a keystroke.

It's also important to note that an interaction may consist of multiple parts. For instance, when you hit a key, you trigger the keydown and the keyup events. In this case, the event with the longest duration within the interaction is chosen for the interaction's latency.

How many interactions there are on a website depends on the type of website/page. If a page is made up of mostly text and images, there may be few or no interactive elements. If, on the other hand, the page includes a text editor or a game, there could be hundreds or even more interactions.

What is a good INP?

Image source: https://web.dev/inp/

It can be challenging to rate responsiveness as "good" or "poor" since the capability of a user's device can vary a lot (e.g., older vs newer devices).

However, a good rule of thumb is to measure the 75th percentile of page loads (segmented across mobile and desktop devices). Then a good INP would be below or at 200 ms. If the INP is between 200 ms and 500 ms, your page's responsiveness needs improvement. Everything above 500 ms means that your page has poor responsiveness.

How do you measure INP?

The best way to measure INP is by using "field data", which refers to real-world performance data collected from users interacting with your website.

One way to get these field data is to use the Chrome User Experience Report (CrUX) – if your website qualifies for inclusion. You can find the CrUX in Pagespeed Insights.

Another way to get field data is by using a Real User Monitoring tool (RUM) like SpeedCurve. If you're using a framework like Next.js (v10+), Nuxt.js (v2+), or Gatsby (v2+), you can also use Vercels Speed Insights.

You can also test INP "in the lab" (synthetic testing), but it's recommended to have field data so that you can reproduce and identify slow interactions.

Read more about how to diagnose slow interactions in the lab.

💡 Tip: If you don't have any field data, the Total Blocking Time (TBT), which assesses page responsiveness during load, correlates very well with INP.

Can INP always be measured?
No, there are times when INP isn't measured, for instance:

The user never "interacted" (clicked, tapped, or pressed a key) - with the page. A bot accessed the page (e.g., a crawler or a headless browser).

How to optimize INP?

Before we can optimise INP, we need to know one crucial thing. Can you guess what it is?

We need to know what to optimise.

Yes, I know it seems obvious. But unlike other web vitals, such as Largest Contentful Paint (LCP), finding which interactions are slow can be difficult.

Ideally, you already have loads of field data showing which interactions need to be optimised.

Unfortunately, in the real world, this isn't always the case.

Maybe you don't have any Real User Monitoring (RUM) implemented on your site. Perhaps you don't have the required traffic amount to be present in the CrUX reports. Or maybe it's an entirely new site that you want to ensure performs well before shipping it.

So, let's see how we can find and diagnose these slow interactions "in the lab".

Diagnosing INP in the lab

To diagnose INP in the lab, you will need a Chrome browser and the Web Vitals Chrome Extension.

Once installed, locate the extension and open it. Click on the gear icon (settings) in the bottom right corner. Enable Console logging and click save.

Now all interactions will be logged into your console (You can open the console using the keyword shortcut Ctrl + Shift + J on Windows and Cmd + Opt + J on Mac), including other web vitals.

Next, it's time to put in the legwork. You need to go through your site interactions to test if any interactions need improvement.

If you have a larger site, you can write down common user flows and test them out. For instance, if you have an e-commerce site, the flow and interactions could look something like this:

Click on a product.
Select a variant (e.g., size, colour).
Select quantity.
Click "Add to cart".
Click the cart icon in the header.
Click the "Go to checkout"-button.
Apply a discount code.
Fill out the shipping address.
Choose a shipping option.
Go to payment.

Remember, the more interactions you can test, the better. For instance, you may find that the discount field is performing slowly without showing any loading indicator. Or maybe the Postal code field, which automatically fills out the City field, is the sinner.

Once you have been through all interactions (or the most common ones), you should have a list of interactions which need improvement. If you don't have any, give yourself a pad on the back and take a break.

If you're not that lucky, we will look into how we optimise the interactions.

Optimise interactions

Now you should have identified one or more slow interactions you can reproduce.

An interaction can be split into three phases:

The input delay: Starts when the user initiates an interaction and ends when the event callbacks begin to run.
The processing time: The time it takes for event callbacks to run to completion.
The presentation delay: The time it takes for the browser to present the next frame.

Add these three together, and you get the total interaction latency.

Reducing Input delay

Input delay, the time from user interaction initiation to event callback execution on a website, plays a crucial role in determining the responsiveness of web interactions. These are some of the ways we can reduce input delay.

Prioritise Brief Interactions: Shortening the duration of interactions is key to meeting the Interaction to Next Paint (INP) metric. While eliminating input delay entirely is challenging, focusing on reducing main thread workload during user interactions can significantly enhance responsiveness.

Optimise Timer Usage and Animation: Be careful about employing JavaScript timers like setTimeout and setInterval. Instead, try to use CSS animations over JavaScript animations, as they minimise the accumulation of animation frames that can cause delays.

Manage Long Tasks: Long tasks on the main thread contribute to extended input delays. Optimise task workload and consider breaking down lengthy tasks into smaller segments using yielding to improve overall responsiveness.

Address Interaction Overlap: Interaction overlap, where subsequent actions interrupt the rendering of the initial interaction, can worsen input delay. Use techniques like debouncing for user inputs and the AbortController to manage resource-intensive interactions.

Optimising Event Callbacks

After tackling input delay, the focus shifts to ensuring these callbacks respond swiftly to user interactions. Here are some of the ways we can optimise these callbacks.

Frequent Main Thread Yielding: Prioritise minimising work within event callbacks. Break tasks into smaller units using techniques like setTimeout to prevent long tasks from obstructing the main thread. This approach enhances overall responsiveness.

Efficient Rendering with Yielding: Yield immediately after an event callback that updates the UI to expedite rendering. Advanced techniques involve structuring code to prioritise rendering-critical tasks, deferring non-critical ones for subsequent tasks.

Preventing Layout Thrashing: Avoid synchronous layout issues (layout thrashing) by refraining from updating and immediately reading styles within the same task. Be cautious of properties causing this problem in JavaScript.

Minimising Presentation Delay

Now it's time for the presentation, where we need to minimise the delay as much as possible. The presentation delay occurs between event callbacks' completion and the browser painting the next frame to reflect interaction changes.

Reducing DOM Size: Smaller DOMs lead to quicker rendering, while larger DOMs increase workload. Efforts like flattening the DOM or strategically adding elements help, though large DOMs may remain challenging.

Lazy Rendering with content-visibility: Utilise CSS's content-visibility to render elements as they approach the viewport. It cuts rendering time, benefiting the Interaction to Next Paint (INP) metric.

Smart HTML Rendering via JavaScript: JavaScript-rendered HTML impacts performance, involving parsing, styling, and rendering. Balancing initial HTML with JavaScript content updates avoids delayed frame presentation.

Acknowledgement

These great articles have been used as the basis of this article. Some explanations have been quoted directly to avoid confusing the reader.

Interaction to Next Paint (INP): https://web.dev/inp/
Optimise Interactions to Next Paint: https://web.dev/optimize-inp/
Diagnose slow interactions in the lab: https://web.dev/diagnose-slow-interactions-in-the-lab/
Optimise input delay: https://web.dev/optimize-input-delay/

If you need to dive into the subject of INP even more, I recommend starting here: https://web.dev/how-to-optimize-inp/

Speeding up B2B pricing on your website

Kasper Andreassen — Wed, 10 May 2023 08:22:01 +0000

It's all 'bout the money. It's all 'bout the dum dum da da dum dum. If you were rocking it in the late 90s, you might remember this Meja lyric.

Now, more than 20 years later, not much has changed. Well, maybe the dum dum da da dum dum, but it is, in fact, still all 'bout the money.

When it comes to business, getting the price exactly right is an art in itself, which is why pricing is also one of the four Ps in the legendary "Marketing mix"-model.

Perfecting the price and finding the sweet spot in supply and demand is both a complex and continuous task.

The price P of a product is determined by a balance between production at each price (supply S) and the desires of those with purchasing power at each price (demand D). The diagram shows a positive shift in demand from D1 to D2, resulting in an increase in price (P) and quantity sold (Q) of the product. (Source: Wikipedia).

The complexity of this task doesn't decrease when it comes to B2B prices. Unlike regular B2C pricing, where the price is mostly the same – and visible – to all customers, B2B pricing often has custom prices (individual prices for different customer segments), and the price itself is often hidden behind a login.

There can be various reasons for this. The price may be tailored to the customers' use case and needs. They may have negotiated a better deal. Or the price/discount may have been set by how much money they're spending (e.g., a large company buying 1,000 bags of coffee a month will get a better deal than a company buying 50 bags).

If we take a traditional B2B eCommerce/catalogue site, a common way to handle custom prices would be to have predefined customer segments/groups to which each customer can belong. E.g.

Segment X
Segment Y
Segment Z

This is a relatively simple and easy way to manage it. The rules can be as complex as one wishes, e.g., different discounts on a category/product level, etc. The point is that the price is tied to the customer segment/group and not to the individual customer.

These rules are handled either by the eCommerce system or, especially for larger sites, a PIM system (Product Information Management).

A PIM system can help to greatly optimise the way a company manages and organises its product data. They come in all shapes and sizes but can quickly become both large and expensive.

However, what we're interested in isn't the cost nor the size. It's the speed. We want websites to be blazingly fast, no matter how complex the products are.

Now you're probably thinking: "Naturally, big expensive enterprise solutions offer fast responses with an easy API, right?"

Yeah, about that. There's a reason why, for instance, the banking industry still runs on COBOL (a 60-year-old programming language). Big enterprise solutions aren't famous for running bleeding edge solutions… or cutting edge solutions… or "whatever is 500 meters away from the edge"-solutions.

Please note that we're not saying this is true for all systems. Not at all. But we are saying that there are systems out there that could improve their performance and the APIs they offer.

Luckily there are solutions for this * clears throat *.

Yes, yes. Once again, we're tooting our own horn (but what a horn).

If you know anything about Enterspeed, you know the deal, so we'll make it quick.

We help you decouple your systems, be it CMS, eCommerce, or PIM, by storing your data in our blazing-fast network. Moreover, you can easily transform and combine data from multiple sources using our low-code schema designer to model your content.

But, Enterspeed also shines (sorry, this is the last toot – promise!) by essentially caching complex data like PIM data. You can read more about how we handle Automatic Cache invalidation.

So, the question is, how do we handle showing customer-specific prices without exposing them to other customers? Let's look at one way to do it.

Handling custom prices with Enterspeed

To keep this article short, let's say we've already ingested our data into Enterspeed and modelled the data, which now leaves us with X number of product views available to fetch via our Delivery API.

{
 "title": "Hamburger Earmuffs",
 "brand": "Frink inventions",
 "description": "The tastiest way to keep your ears warm!",
 "inStock": true,
 "currency": "EUR",
 "price": {
   "regular": 20,
   "sale": 18,
   "customer-x": 19,
   "customer-y": 18,
   "customer-z": 17 
 }
}

Here is the response we get when we fetch the URL "/products/hamburger-earmuffs". In this example, we have stored all the custom prices in the pricing object.

Now we want to show the correct price to the correct customer – and only show the price if they're authenticated.

Because we have all the information stored in a single view, we can't fetch it client-side since that would reveal all the prices in the GET request. So instead, we'll have to fetch it server-side.

If we use a framework like Next.js, that's really easy to do by using the getServerSideProps – and even easier if you're using their new app directory in Next 13, which uses server components.

So, let's build a function that does that. Then, let's break down what it should do.

It should fetch the data from the Enterspeed Delivery API
It should only return a price if a user is authenticated.
It should check to see if the user belongs to one of the groups on the price object.
If the user doesn't belong to any of the groups, it should return the regular price.
If there's a sale price present, it should check to see if it's lower than the customer's price since we don't want to cheat them out of any discounts we're running.

We start by creating a helper function to handle fetching the data from Enterspeed. You can check it out here in one of our demo repos.

const call = async (query) => {
  const url = `https://delivery.enterspeed.com/v2?${query}`;
  const response = await fetch(new Request(url), {
    headers: {
      "Content-Type": "application/json",
      "X-Api-Key": process.env.ENTERSPEED_PRODUCTION_ENVIRONMENT_API_KEY,
    },
  });
  return response.json();
};

export const getByHandle = async (handle) => {
  const response = await call(`handle=${handle}`);
  return response.views;
};

export const getByUrl = async (url) => {
  const response = await call(`url=${url}`);

  return {
    ...response.route,
    ...response.meta,
  };
};

Next, we create the function that handles the actual product logic. Let's call it getProduct.

An auth provider will handle the authentication, including the user's segment/group. In this example, we assume we have access to:

If the user is authenticated or not.
The user segment (if any) the user belongs to.
The URL of the product they want to view.

Having access to this, we can build a function that looks something like this:

import { getByUrl } from "/lib/enterspeed";

const getProduct = async (url, isAuthenticated, userSegment) => {
  try {
    const product = await getByUrl(url);

    if (!product) {
      throw new Error("Product not found");
    }

    let { price } = product.price;

    if (!isAuthenticated) {
      price = "Login to see price";
    }

    if (!userSegment || !price.hasOwnProperty(userSegment)) {
      price = price.default;
    }

    const customerPrice = price[userSegment];
    const salePrice = price.sale;

    if (salePrice && salePrice < customerPrice) {
      price = salePrice;
    }

    price = customerPrice;

    return {
      ...product,
      price,
    };
  } catch (error) {
    console.error(error);
    return {
      error: error.message,
    };
  }
};

export default getProduct;

Let's break down step-by-step what the function does:

Takes three parameters: url (a string), isAuthenticated (a boolean), and userSegment (an optional string).
Attempts to fetch a product object from the Enterspeed Delivery API using the getByUrl function.
If the product object is falsy (e.g. null, undefined, etc.), throws an error with the message "Product not found".
Extracts the price property from the product object and assigns it to a variable.
If isAuthenticated is false, sets the price variable to the string "Login to see price".
If userSegment is falsy or the price object doesn't have a property matching userSegment, sets the price variable to the default property of the price object.
Retrieves the price of the product based on the userSegment
Retrieves the sale price of the product, if it exists.
If a sale price exists and it's less than the customer price, sets the price variable to the sale price. Otherwise, sets the price variable to the customer price.
Returns a new object that contains all of the properties of the original product object, as well as the price property that was just calculated.
If an error occurs during the execution of the function, logs the error to the console and returns an object with an error property containing the error message.
Exports the getProduct function as the default export of the module.

That's it. By syncing our product data, including our custom pricing, to Enterspeed, we have essentially cached it. And because we handle all the price logic server-side, only the correct price will be visible to the user.

If you want to give Enterspeed a spin, you can sign up for our free plan, which includes 5,000 source entities and 500,000 delivery API requests per month. You can check out our pricing right here.

Unleashing the full power of Middleware with Enterspeed ⚡

Kasper Andreassen — Wed, 15 Feb 2023 09:00:00 +0000

For many years, middleware has played a crucial role in web development. It enables applications to operate smoothly and effectively to meet user demands.

It acts as a bridge between the UI (frontend) and the backend services, handling tasks such as authentication, routing, and data processing.

However, building and managing middleware isn’t always easy, especially when it comes to scalability, maintainability, and performance.

Luckily, frameworks like Next.js have moved the needle regarding innovating what is possible with middleware and how easy it is to use. For instance, they have made it really easy to work together with Edge functions, making it possible to personalise content based on the user’s geolocation.

💡 An edge function is a serverless function that runs at the edge. If you want to learn more about it, check out Netlify’s “Understanding Edge Functions: The Edge and Beyond”.

But as incredible as these innovations are, we’re still left with some challenges regarding middleware. Since it sits in the, you guessed it, middle, we risk that the middleware becomes a bottleneck, making the site slower and hurting the user experience.

The risk isn’t that high for small and simple sites, but as the sites become larger and more complex, the risk of introducing bottlenecks increases.

Fortunately, there are some great solutions out there which are designed to address these challenges. Can you guess the name of one of these solutions?

That’s right. Everything is coming up, Milhouse! I mean, Enterspeed (sorry).

Enterspeed lets you unleash the full power of your middleware. By acting as a middleware accelerator, it can optimise the performance of your application by reducing latency as well as server loads.

But first, let’s look at what middleware exactly is and what it can do.

What is middleware?

There are several types of middleware, each with its own use case. The type of middleware we will be focusing on in this article is Application middleware.

Middleware is a layer of software that sits between the UI and backend services. It acts as a mediator, which allows the UI and the backend services to communicate and exchange data seamlessly.

The concept of middleware isn’t a new thing – it has been around since 1968.

As the name might suggest, it handles specific tasks within the application, such as data fetching, authentication, request/response handling, etc.

An example could be a user trying to access a page that requires authentication – e.g. an article behind a paywall.

The user (client) sends an HTTP request to the server for the URL (e.g. nnytimes.com/hero-robot-rescues-valuable-money). Before the article is returned, a piece of middleware kicks in.

The middleware checks if the user is signed in. If not, it redirects the user to /sign-in, else it continues to the article.

The authentication is often done using JWT (JSON Web Token), which can also include details like user role (e.g. subscriber, premium subscriber, super-duper-ultra-premium subscriber).

Other use cases for middleware can be:

Data fetching
Analytics
A/B testing
Feature flags
IP blocking
Bot detection
Personalisation with geolocation
Translation based on geolocation
Power Parity Pricing strategies
Use-agent based rendering
Cookie handling
Redirects
Removing query params
Maintenance mode

As you can see, there are plenty of use cases to choose from.

Next, we’ll look into how we can use Enterspeed as a middleware accelerator.

Accelerating your middleware with Enterspeed

When looking at slow-performing websites, we often see bottlenecks occurring during data fetching.

The reasons for that can be many things, for instance:

Server placement: The data source is located far away from the client.
Server resources: The server may not have the resources to handle the amount of traffic.
Poor load balancing: The server may not have a good way of distributing traffic correctly.
Query complexity: The queries in the database may be complex, resulting in longer execution times.
Data fragmentation: The data may be stored in multiple locations (e.g. PIM, Commerce solutions, CMS, etc.).

The list could go on. It all depends on how your setup and architecture look.

So how can Enterspeed help avoid these kinds of bottlenecks? We touched upon this in our last article, “All you (probably) need to know about caching on the web”, but to sum it up:

Enterspeed helps you offload your data, which you can combine with multiple data sources (as well as transform) in a Redis cache (in-memory storage). This essentially decouples your server, as well as makes your dynamic content static.

So let’s see how an Enterspeed setup could solve the bottlenecks we looked at above.

For server placement, Enterspeed provides multi-region support globally. Additionally, our entire solution is built on Azure cloud services, which automatically handle scaling and traffic distribution.

All query complexity and data fragmentation are removed since we combine the user’s data into static views, which automatically regenerate as soon as the data updates.

That concludes today’s sales pitch. Now let’s actually try to build the middleware that fetches from the Enterspeed API. In this example, we will be using Next.js and Netlify.

Setting up middleware in Next.js with Netlify

To utilise the full power of our middleware, we will use Netlify’s Next.js Runtime, which allows us to rewrite and transform content at the edge.

Another one of its insanely powerful features is its ability to transform page props on the fly, which we will use in the examples below.

To get started, make sure you have the latest version of the Netlify CLI (and a Netlify account). The Netlify CLI allows us to use edge logic for custom headers and redirects, environment variables, and Netlify Functions on our local machine.

Next, spin up a new Next.js project and install the @netlify/next package, which allows us to use Netlify’s edge functions in our middleware.

Create a middleware.js (or .ts) file and place it in your root/src directory (same level as your pages folder). The file will run on every request, including static files, pages, assets, etc.

💡 The example below is based on the brilliant article “Rewrite HTML and transform page props in Next.js with Next.js Advanced Middleware” by Salma Alam-Naylor. Check it out for a more in-depth tutorial of how the Next.js Advanced Middleware on Netlify works.

Export an async function named middleware and pass in the request as nextRequest to the function.

Import { NextResponse} from “next/server” and { MiddlewareRequest } from “@netlify/next”.

Next, declare the following constants:

const pathname = nextRequest.nextUrl.pathname; (We get the pathname from the request)
const middlewareRequest = new MiddlewareRequest(nextRequest); (We initialise a new Netlify MiddlewareRequest, passing in the nextRequest)
const response = await middlewareRequest.next(); (We get the next response in the HTTP chain by awaiting middlewareRequest.next())

Next, since the file runs on every request, we check to see if the pathname matches some of our unwanted resources. If it does, we simply move on to the next response in the HTTP chain by returning response.

💡 This can also be done using matcher in the config object. However, there seemed to be some problems with this and the Netlify middleware in this case.

Afterwards, we get the actual content from Enterspeed using our Delivery API. We have made a helper function called getByUrl, which simply fetches from the API using the URL as the query parameter.

The data we’re getting back from Enterspeed is based on the schema we have designed. The data also includes a status (200, 301, 404, etc.) and a redirect property, which can include the path to where the content has been moved.

If we receive status 301, we redirect to the URL provided in the redirect property. If we receive status 404, we throw a 404 response.

However, if all goes well, we pass the data from Enterspeed using response.SetPageProp, which makes the data available as props in our pages, and afterwards return the response.

💡 To keep the example simple, we simply look at these three status codes. For real-world applications, you should handle all possible exceptions.

Now, we can create a page using dynamic routes to handle the content we get. For this simple example, we have created a simple article that returns a few properties. The properties we get are:

Now you’re probably thinking, what’s with the “premium” boolean? Glad you asked!

Say we have paywalled content, which requires a subscription to read. We then need to check to see if the user has an account before they can access it. This can be done using JWT (JSON Web Token).

By implementing authentication in the middleware, we’re able to authenticate users before they hit any endpoints – we can even do it right at the edge. You can check out Vercels JWT Authentication template right here.

Once authentication has been added, we can make a simple function checking if they’re signed in and if the premium property is true.

If they’re not signed in and the premium property is true, the user will be redirected to the login page.

💡 As previously mentioned, we can store data like the user role in the token, which can be implemented in the logic above.

Interesting, but what if we still want the user to be able to access a page but not view all of its information? For instance, a B2B website that only shows prices to its current customers.

The data could look something like this, where we want to hide the price.

Then we simply change the price property before setting the page props. We can either delete it or change its value, like in the example below.

Ah, you spotted it, didn’t you? Once again, you sit with a puzzled look on your face thinking, “What the dickens is the ppp-property?”

…And just like a hungry salmon swimming in the crystal-clear river, you took my bait 🎣

Poor naming convention aside, let’s look at how we can transform prices based on geolocation.

But why change prices based on geolocation? The answer is Purchasing Power Parity (PPP) strategy.

Purchasing Power Parity is a pricing strategy where companies set product prices based on local market conditions and production costs in different countries, using PPP exchange rates to ensure price consistency and stability.

The data could look something like this.

Here we have different prices for “DK” (Denmark), “US” (United States), and “UK” (United Kingdom).

In our middleware, we have access to the visitor’s geodata via the nextRequest.

We can then change our price, depending on the visitor’s country, with some simple logic. First, we check to see if the ppp-property is true, and then we change it to the price for the specific country.

If we don’t have a price for the user’s country, we use “US” as a fallback.

How cool is that!

Closing thoughts

You may be sitting in your chair, fingers stretched, screaming, “UNLIMITED POWER!” to the thoughts of all the possibilities of middleware.

That’s great! The purpose of this article was to show you how you can utilise middleware for your application in a performance-friendly way using Enterspeed.

You can view other use cases for middleware in Vercels template library.

The question is then, should you use middleware? To quote every software developer on the planet:

_“…It depends”.
_
There are a thousand ways to skin a cat. What makes sense for your setup may not make sense for others.

Simply fetching data and manipulating props can also be done using getServerSideProps, the same goes for checking authentication.

However, what middleware can do, in this case, edge middleware, is to personalise content with very low latency since it’s running on the edge.

Moreover, because the middleware runs before the cache, it can manipulate statically generated content.

All you (probably) need to know about caching on the web 🗃

Kasper Andreassen — Fri, 06 Jan 2023 10:39:59 +0000

Every developer has most likely bumped into the concept of caching at some point in their career.

For some, it’s a vital instrument in their everyday work that helps their code to run as fast and cost-effective as possible.

For others, they might only have worked with it that one time they activated “that cache plugin” on a client’s WordPress site.

If you belong to the first group, you probably won’t need this article. Instead, you can enjoy a nice game of “Chrome dino”. Open a Chrome browser and type: chrome://dino/ (send me your high score afterward!).

For all you people not so well-travelled in the world of cache, I know you’re dying to also play a nice game of “Chrome dino”, but patience you must have my young Padawan – your time will also come.

First, let’s look at what cache is and how it works.

What is cache?

Caching is the process of temporarily storing copies of data, so it can be accessed more quickly.

It’s a concept that has been used in computer science for ages, going all the way back to 1965 when British computer scientist Maurice Wilkes introduced memory caching.

But copying things doesn’t necessarily make them faster, Let’s look at three examples.

In the first example, we’ll see how you can reduce the server’s workload by turning your dynamic content into static content.

Making dynamic content static

Back in the early days of the web, all websites that existed were static – it was all pure, simple HTML.

Then in the mid 90’s that all changed when multiple server-side languages were released (PHP, ASP, etc.), as well as one client-side scripting language called JavaScript

Dynamic pages revolutionised the web and made websites more personalised and interactive. However, it also made the web a bit slower since the user now had to wait for a server to render the content.

Having the server create the content every single time a user visited, even though nothing had changed, seemed a tad bit silly, so developers started implementing caching.

The caching worked by saving a copy of the “server response”, turning the dynamic content into static content.

That way they could generate content upfront and serve it both quicker and cheaper to the user – they just had to remember to invalidate it when the content changed.

Let’s see what this could look like in the real world.

Example: Soup of the day

Imagine a restaurant serving “soup of the day”. Each day a new, different soup is available.

Which soup is available that day, may depend on which ingredients are in surplus in the kitchen and what the chef feels like making.

Since the restaurant doesn’t know what the soup of the day will be, they can only write “Soup of the day – ask the waiter” on their menu.

(It’s really difficult for me not to write a witty ‘ask the server’-pun here).

That’s fine for a small restaurant, or one where a waiter takes your order each time. Now imagine a busy street food restaurant serving hundreds of customers throughout the day.

Getting asked, “What is today's soup?” a hundred times a day, every single day, would turn any man or woman into a Soup Nazi, yelling “NO SOUP FOR YOU!” the 249th time this question was asked.

The restaurant could instead “cache” this request by writing “Soup of the day: Chicken soup” on a blackboard above the counter.

The chef could then easily “invalidate” this cache once a day, when the soup changed, or when the soup is sold out.

In the next example, we will see how we can get the soup… Sorry, I mean content, closer to the user by using caching.

Moving the content closer to the user

The location of a server hosting a website can greatly impact the website’s speed.

If the user is located far away from the server, their response will be slow compared to someone located close to the server.

The closer the user is to the server, the quicker the response. This is also why there’s big money in renting out servers as close to the stock exchanges as possible – for high-speed trading bots, every millisecond counts.

Luckily, we don’t need to have the servers quite as close to the users, as a trading bot needs to be to a “trading floor”, but we need it to be somewhat close to their geographic area.

Setting up multiple independent servers to serve multiple geographic areas can be both inefficient, costly, hard to scale, and a nightmare to manage. Luckily there’s a better solution – a CDN.

A CDN, Content Delivery Network, is a group of servers distributed geographically that work together to deliver your content fast to the user.

It stores a copy of your data, including HTML pages, JavaScript files, stylesheets, images, and even videos.

CDN providers have a ton of locations available. Cloudflare, for instance, has 275 servers in more than 100 countries – imagine if you had to set that up yourself!

Let’s try to translate a CDN into a real-world example.

Example: The electrician and his van

Say you are an electrical contractor and run a successful company with several employees under you. Since you’re an electrical contractor and not a baker, you need to go to your customers instead of your customers coming to you.

The customers can be located far away from the workshop, where you store all your tools, cables, and other supplies.

Having to go back and forth from the workshop to the customer, each time you need a tool or cable would be quite cumbersome.

Instead, the electrician “caches” his most used tools and supplies in his van. That way the things he needs are close to him, and he can quickly grab what he needs.

Each day when he gets back to the workshop, he can “revalidate his cache” by filling up the vans with new supplies, charging his electrical tools, and preparing the van for the next job.

Image source: https://www.fieldpulse.com/blog/electrician-van-setup/

In the last example, we will see how we can cache our data to faster storage solutions.

Moving the data to faster storage

All storage is not “built the same”. You'll know what I'm talking about if you have ever switched from using a hard drive to an SSD.

Hard drives, which store the data on mechanical spinning disks are great at storing a large amount of data since they are incredibly cheap when it comes to “cost per GB”.

However, having mechanical parts just isn’t as fast as something without any moving parts, like an SSD, which stores its data on flash memory. SSDs are much faster, but (as you may already have guessed) also more expensive.

Over the years many web hosts have started offering plans with SSD hosting to make their services even faster.

But do you know what’s even faster and way more expensive than SSD storage? RAM storage.

That’s right, you can store your files in the RAM. Benchmark has shown read speeds that were 6.3 times faster than the speed of an SSD – insane!

But no sane person would store websites in memory (RAM), would they? Indeed, they would.

Redis is an in-memory data store that you can use as a database – or a cache in front of your regular database. The speed of Redis makes it ideal to cache database queries, complex computations, API calls, and session state.

Now, I know what you are thinking. “I’m just a simple developer trying to make my way in the universe. I’m not going to set up and maintain a separate database merely for caching.”

I get that, boy do I get that. As the late Phil Karlton once stated: “There are only two hard things in Computer Science: cache invalidation and naming things”.

If only there was a way to reap the fruits of in-memory storage, without the hassle of setup, maintenance – and more importantly cache invalidation.

You can see where this is going, can’t you?

Yes, this is indeed shameless self-promotion. Don’t worry, I’ll be sure to whip myself 3 times afterward and put on the cone of shame for the rest of the day.

Enterspeed is a way to cache your data in a high-speed, in-memory storage, without the hassle of maintenance and cache invalidation.

We offload your data, which you can combine with multiple data sources (as well as transform), in a Redis database. What this does is essentially decouple your server, as well as make your dynamic content static.

If you want to know more about how this all works, head over to Enterspeed.com to read more.

Well, that’s enough self-promotion (for now). Let’s look at the real-world example for this.

Example: RV with a car storage

After thinking about it for many years, you’ve finally decided that you’re going to see Europe. You’ll take some months of work, rent an RV, and visit all the places you’ve dreamt about seeing.

An RV is perfect since you don’t have to plan far ahead and can stay at each place for as long as you like. One problem though. While an RV is great for many things, it isn’t exactly an easy or fast vehicle to operate – especially not on those tiny European streets.

You’ll need something else for those small sightseeing tours. Therefore, you decide to add a car to your travel plans.

What solves this problem, is an RV with built-in car storage. That way you can use your RV to travel from location to location, and the car to go sightseeing within the location.

Image source: https://www.concorde.eu/modelle/liner

If you’re not Scrooge McDuck, this could also simply be a bike, or a scooter placed on the back of the bus – but how cool is a freaking built-in car garage!

Now, before moving on to the “how to” of the article, let’s look at some of the different types of web caching.

Web caching types

There are several types of caching. Some of the most used in web caching includes:

Client-side caching: A cache that is stored on the user’s computer.
Browser caching: A cache that is stored on the user’s computer.
Server-side caching: A cache that is stored on the server.
CDN caching: A cache that is stored across multiple CDN servers.
Reverse proxy caching: A cache stored on a reverse proxy server.

Now you’re properly thinking: “Wait, isn’t client-side caching and browser caching the same thing?”.

Not exactly. They’re similar in the way they store their data (on the client), but they’re not the same thing. To add to the confusion, the way client-side caching can be implemented is by using the browser’s storage APIs.

However, what differentiates them isn’t how they store data but rather what types of data they store.

Client-side caching is used to store responses from the server, e.g., API requests, which then reduces the number of requests that need to be made to the server.

Browse caching on the other hand stores static resources like images, videos, fonts, stylesheets, HTML files, JavaScript files, etc.

Both client-side caching and browser caching are controlled by the user’s browser. The developer can control the cache headers (for instance when the cache should be invalidated), but it is ultimately up to the web browser to interpret and enforce them.

This brings us to Server-side caching which stores the cache on… you guessed it – the server. Here the developer is in full control. There are several types of server-side caching, some of those are:

Page caching: Stores all the HTML of a page, so the server doesn’t have to generate it dynamically (as explained in the “Making dynamic content static”-example).
Database caching: Stores data that are frequently used in the database (As explained in the “Moving the data to faster storage”-example).
Object caching: Stores complex data structures or objects, which reduces the number of database queries needed (Also explained in the “Moving the data to faster storage”-example). The next type of caching is CDN caching, which we explained in the “Moving the content closer to the user”-example, so we won’t dive too much into that.

Finally, we have reverse proxy caching. A reverse proxy cache, also known as a reverse HTTP cache, is also a type of server-side cache.

It sits in front of the server(s) and acts as a buffer between the client and the server. When a request arrives, it’s forwarded to the server by the reverse proxy which then caches the response. Thus, future requests can be served from the cache instead of hitting the server.

A reverse proxy cache is therefore a great way to improve not only the performance of a website but also its scalability – a reverse proxy cache is also able to work as a load balancer.

Before moving on to some of the ways you can implement cache on your website, we need to look at two more types of cache – private and public cache.

Private caching is a cache that can only be accessed by a specific user or user group. It can be stored both client-side and server-side.

Some examples of things that can be stored in a private cache are:

User preferences (Preferred language, dark mode, etc.)
Personal data (Name, e-mail address, etc.)
Private messages

Public caching, on the other hand, is accessible to all users and is often stored on the server. Some examples of things that are stored in a public cache are:

Commonly accessed resources (Images, videos, product catalogues, etc.)
Public content (articles, blog posts. etc.)

Now that’s all set, it’s time to move on to how you can use cache on your website using some “easy wins”.

Using cache on your website

Designing and setting up a caching strategy can be difficult. There are several ways to tackle cache and it all depends on how your setup looks and what your needs are.

Installing a caching plugin

If you’re using a CMS like WordPress, one of the quickest ways to start utilising cache is by installing a cache plugin.

One of the most beloved WordPress caching plugins is WP Rocket. They’ve managed to take something complex and make it extremely easy, yet still powerful and configurable. They have also made it easy to integrate with a CDN in just a few clicks.

Setting up a CDN

Implementing a CDN is an extremely easy way to implement caching on your website.

If your site is built on the Jamstack principles, you are probably already using it via a provider like Netlify, Vercel, Cloudflare Pages, etc.

If not, then it’s as simple as setting up an account at a CDN provider and updating your nameservers. Cloudflare offers a generous free plan and is really simple to set up. You can read more about the setup here.

Implementing ISR (Incremental Static Regeneration)

It’s no secret that I’m a big fan of Next.js and its many fantastic features. One of the features I adore is their Incremental Static Regeneration.

When rendering a page, the choice is usually between SSR (Server-side Rendering) or SSG (Static Site Generation). Due to the risk of poor SEO and slow initial load, CSR (Client-side Rendering) isn’t often used on “regular websites” (non-app websites).

SSR is great since it makes your pages dynamic but can be slow since it must wait for the server each time.

SSG is great since it’s super-fast but isn’t easy to update since you will have to do a deployment each time you want to change something.

Well, ISR completely changed the game. Like a peanut butter and jelly sandwich, it took two great things and combined them, making something even better. It combined the power of SSR with the power of SSG.

ISR caches each page individually. When a user visits the page, it will check if there is new content available. If there is, it will start regenerating the page and once it’s done, invalidate the cache and show the updated page for the next visitor.

You can read more about Next.js ISR here.

Caching API responses

If you are fetching data client-side, e.g., showing your visitors data from the Star Wars API, you should cache these responses.

If the user has already made a request to see all the starships in Star Wars, there’s no reason to make an identical request if the user wants to see it again. Instead, the response should be cached.

You can implement this yourself, for instance by using a state management solution, or something as simple as the State hook in React.

You can also use data fetching packages with built-in caching management, for instance, TanStack Query, SWR, etc.

I hope you enjoyed this article about caching. You are now free to play all the “Chrome Dino” that you wish.

The “Chrome Dino” game is shown in Chrome when you are offline. If you want to make your website/app work offline (making it a PWA), one of the ways you can store data is by using cache. You can read more about “offline data” here.

The illusion of speed – why perceived performance matters

Kasper Andreassen — Mon, 28 Nov 2022 07:50:59 +0000

Time is relative.

We have all heard this expression a million times before. Many years ago, some German dude went on and on about it, and even developed some theories about the same thing.

But what does it actually mean? With the risk of going all “Neil deGrasse Tyson” and start answering questions that nobody has asked, we can circle back to the aforementioned German dude.

The German dude, let’s call him Albert, had a secretary who got burdened with questions from reporters about the meaning of relativity. To help her out, Albert told her to simply answer these questions with the following example:

“When you sit with a nice girl for two hours you think it’s only a minute, but when you sit on a hot stove for a minute you think it’s two hours. That’s relativity.”

Interesting. This means that how we perceive time depends on our frame of reference. Moreover, the time we see on a clock doesn’t necessarily reflect our “brain's time” (psychological time).

“Cool stuff, nerd. But what the heck does this have to do with website performance?”.

Hang on, hang on, I’ll get to it. Just like taking your partner on a date, we must first set the mood. So let me light some candles and throw on some Barry White before diving into it.

When we talk about web performance, we often tend to focus solely on the metrics. “What is your Lighthouse score? What about your LCP? And have you optimized your FID?” often gets thrown around.

We are so enthralled in those goddamn Lighthouse scores, that we risk forgetting about the user.

“Wait, what? But I do this FOR the user!”. Yes, and that’s great. Optimizing your web vitals is important to the user experience, but it doesn’t tell you whether the user perceives your website as fast or slow.

You can have two websites with identical web vital metrics, meaning one loads just as fast as the other, where one is perceived as fast by the user and the other as slow.

I know, it’s weird.

We call this perceived performance. Where traditional performance optimization focuses on objective speed, perceived performance optimization focuses on subjective speed, and according to Mozilla, it’s even more important than the “actual performance”.

“The perception of how quickly (and smoothly) pages load and respond to user interaction is even more important that the actual time required to fetch the resources.” – MDN Web Docs.

Just like any other subject in tech, the rabbit hole goes quite deep when we start looking into perceived performance. So deep in fact, that a 224 pages book called “Designing and Engineering Time: The Psychology of Time Perception in Software” has been written about it.

Therefore, we’re not going to follow the white rabbit to the end of the hole in this article, but merely glance into it… we simply don’t have the time (bad dum tss!).

What we want to do is to keep the user in a state of “flow”. But what is flow?

Authors Rina A. Doherty and Paul Sorenson describe flow in their paper “Keeping Users in the Flow: Mapping System Responsiveness with User Experience” as:

“…flow is commonly described as the natural, fluid state of being productively engaged with a task without being aware of the technology that is driving it. As such, if successful, technology can become virtually forgotten when a user is immersed in the experience, or is in the flow”.

A way to make sure we don’t break this flow is to avoid users going into the dreaded “passive state”.

The active and the passive state

The way humans perceive time depends on the activity they’re doing. An activity can be broken into two states – the active state and the passive state.

In the active state, we have a high level of mental activity, and in the passive state, our mental activity is low.

We often enter the passive state when we're waiting for something, for instance standing in a queue. Professor Richard Larson ran an experiment for this very thing. His research showed that we tend to overestimate the time that has passed in the passive state by a whopping 36% (Source).

“Okay, so avoid queues on my website. Got it. Why are you telling me this?”.

Because we are constantly switching between the active and the passive state – including when we browse the web.

We of course are in the active state when we are navigating the web. Can you guess when we enter the passive? Bingo. When we’re waiting for a page to load.

The good news is we don’t enter this state immediately. It takes about a second for us to transition to this state, according to research done by the Nielsen Norman Group.

This means, that whenever the load time for a page is 1 second or more, we risk the user entering the passive state. What’s worse is, they experience the load time as much longer than it is.

As we saw, people on average overestimate the passive state by 36%. If we have a page that takes 4 seconds to load, the user will actually experience this as 5 seconds (25% slower than it really is).

The first second is in the active state, but in the next three seconds, the user risks moving to the passive state, which they then will experience as 4.08 seconds (3*1.36), which will result in a total perceived load time of 5 seconds (1 + 4.08).

You may be slamming your fist on the table by now, saying “TIME IS TIME! This isn’t fair!”.

And no, it isn’t (to both statements). But luckily, there are tricks we can use to overcome this hurdle.

We have two options here:

Avoid users entering the passive state by keeping them in the active state.
Making the passive states feel faster.

Let’s look into each.

Keeping the use in the active state

Loaders

The first thing we can do to keep the users in the active state is to be mindful of when we use loaders (spinner, loading bars, etc.).

I know this seems counterintuitive but hear me out. Remember the scene in the first “The Fast and the Furious”-movie (yes, I’m that old), where Jesse presses the Nitrous too early? Johnny then says “Too soon junior”, presses the nitrous, and overtakes poor Jesse. This is the same thing (except, not quite as cool).

We don’t want to show the loaders too soon.

We know it takes the user about a second to naturally transition to the passive state. This means that showing them the loaders when the wait (loading) is under 1 second, is not only unnecessary, but it can also harm the perceived performance.

Since loaders tell the user that “now they have to wait”, it will force them from an active state into a passive state. Therefore, we should avoid using loaders if we anticipate the wait time to be under a second.

Avoid layout shifts

Image from Web.dev.

Content “jumping around“ can make it feel like the page is still loading and send the user into a passive state.

We call them layout shifts and they are often caused by images being loaded, which then causes the content to “jump”.

Another culprit can be custom fonts being downloaded. If the custom font isn’t the same size as the fallback font (the font being loaded before showing the custom font), it might cause layout shifts.

To avoid these layout shifts, make sure you give your image element a width and a height (required if you’re using next/image). For layout shifts caused by fonts, make sure to preload your custom fonts and find a fallback font that matches the custom font in size.

Layout shifts are measured in Google Lighthouse via the CLS (Cumulative Layout Shift) metric.

Animations

Another way to keep the user in the active state is by making sure your animations are smooth. If your animations don’t feel natural and don’t move how the user might expect (for instance a slight lag), this can cause the experience to feel slow. If the animations start feeling “laggy”, it can cause the user to transition to the passive state.

So, make sure your animations aren’t too complex for the user and that they feel natural. A good way to provide a smooth experience is to render your animations at 60 fps.

The :active selector

Image from Adobe.com.

The secret to keeping the user in the active state is to provide immediate feedback. The user likes to know, that something is happening at the other end when they take an action.

This immediacy keeps the users from going into the passive state.

A super easy way to implement this in your UI is to add an :active selector to all your button and link elements.

The active pseudo-class represents that an element has been activated by the user. Changing the background color of the button (or shadow, border color, etc.), when the user clicks (activating the :active pseudo-class), provides the user with feedback, that something is happening.

Preloading

As the word might suggest, preloading means that we load something in advance. There are two ways we can think about preloading. One way is that we start loading something which we will need later on. Another way is to show something before it’s done loading. Let’s look at each one.

In the first case, loading something before we need it, we anticipate what the user will do next. Instagram for instance does this by beginning to upload your image as soon as you select it. They anticipate you will publish your post, so they do the heavy work before you hit the post button.

We can do a similar thing on our website by preloading pages before users navigate to them.

Frameworks like Next.js have this feature built into their router. In Next.js, when using next/link, you can add the “prefetch”-prop. By adding this, any link that is in the viewport (initially or through scroll) will be preloaded.

In the second case, we start showing something before it’s completely done loading. We see this all the time on various streaming platforms. If you open a YouTube video, it will start playing, even though it hasn’t downloaded the whole video. Instead, it will estimate how fast you can stream it and wait for that portion of the video to be loaded.

This is the same, as when we chose to load above-the-fold content first on our website. We want the user to be able to interact with the page right away, without having to load the entire page. A way we achieve this is by lazy loading images and components, as well as deferring non-essential scripts.

Okay, now let’s look at how we can make the passive state feel faster.

Making the passive state feel faster

All right then, it’s time to manipulate time. Don’t worry, we’re not going to create any time paradoxes – we wouldn’t want to unravel the very fabric of the space-time continuum and destroy the entire universe (Great Scott!).

Instead, we will use smoke and mirrors to make the passive state feel much faster than it really is. Let’s first look at a real-world example.

Back in the early industrial age, buildings started growing taller and taller, which meant more people started using elevators. Back then elevators were quite slow, so naturally, people did what people do best – they began complaining about it.

As a result, elevator companies started tackling this problem by designing elevators that were faster and safer. Unfortunately, at the time this was a very expensive thing to do.

However, in another elevator company, one engineer had a different take on the problem. Speaking like a true (software) engineer he blamed the user, as he said:

“I think our elevator speeds are just fine, people are crazy.”

This guy was basically a real-life Principal Skinner!

His theory was, that the problem wasn’t about the elevators' speed (objective), but rather that the users thought it was slow (subjective).

So, while the other companies went off trying to optimize their motor and pulley design, this company tackled the problem differently – they wanted to solve why the user thought it was slow.

Turns out that being trapped inside a metal box suspended many meters up in the air, held up only by a metal wire, isn’t exactly fun. The time seemed much longer when you had nothing to do but stare at the wall, trying to cope with your fear of being trapped.

So how did they solve this problem? They installed mirrors.

Yes, mirrors. Seems silly, but that was really all it took. Suddenly the users perceived the elevator rides as much faster than before.

Now the users could look at themselves, check if their hair and makeup were okay, and become distracted by their own reflection. As an added benefit, it helped people suffering from claustrophobia since the space now seemed bigger than it really was.

And by that, we conclude today’s history lesson. Let’s look at what you can do to make the passive state feel faster.

If we can’t keep the users in the active state, we have to utilize loaders in the best way possible.

Experiment with the design of the loader

There are many ways to design a loading animation – just look at cssloaders.github.io.

Probably the most famous loading animation is the spinner. However, even a spinner can be designed in multiple ways.

If you look at the different variations, you will probably realize that you interpret some as slow, whereas other seems fast.

As we learned earlier, how an animation is designed can have a big impact on the user’s sense of speed.

If you want to be devious like Facebook, you can even try to shift the blame of a slow site/app to the user’s own operating system.

Doing an A/B test, they found out that by mimicking the iOS loading animation, the user started to blame iOS for the slowness instead of Facebook. Oh Zuck, you sneaky Lizard-man.

Use Skeleton loaders

Skeleton loaders, even though they might sound spooky and scary, are a fantastic way to make your website seem faster.

A skeleton loader is an animation placeholder that mimics the structure and looks of the content being loaded. They often have a gray color along with a pulsing or waving animation.

It gives the user an idea of how the content is going to look and feel.

You’ll see skeleton loaders implemented on big sites like Facebook, LinkedIn, Medium, etc.

Example of Skeleton loader from React Native Skeleton Content.

There are plenty of packages available for frameworks/libraries like React, Vue, etc., and if you’re using a UI framework, it might be built in, as Chakra UI has.

Tell the users what’s going on

If your website or app has a multi-step process that takes time, it can be beneficial to tell the user what’s going on, instead of simply saying “loading”.

At Enterspeed, when bulk deploying schemas, we have implemented a loader that tells you if it’s validating or deploying schema, as well as how many schemas are left. Often you won’t get to see this, because it goes fast, but just in case you have a slow connection, you can see what’s going on.

Moreover, if the process takes more than 4 seconds, you should switch the spinner out with a progress bar, so the user can see the progress being made.

Image from Microsoft.com.

Distract the user in fun ways

For processes that take a very long time, you can try to find a fun way to distract the user. A real-world example is the crosswalk in Germany with a built-in pong game.

To distract the user while they wait, you can show them a random fact (e.g., a random cat fact via the Cat Fact API), or maybe something related to your industry.

For instance, in a performance monitoring tool I helped build, we implemented a random fact about Conversion Rate Optimization, which changed every 10 seconds, while the user waited for their report to be generated.

Netlify also does a great job distracting the user, while you wait for your site to deploy. They give you the option to play a game while you wait, and even show you the deployment process meanwhile – how cool!

How do we measure perceived performance?

It’s always quite difficult to measure and quantify a subjective thing. The same goes for perceived performance.

We can interview our users and ask them if a site felt slow or fast, using feedback plugins, or by performing user tests. However, this can be difficult to do for smaller websites

Luckily, we also have metrics available that we can use as indicators for perceived performance.

I began the article by saying “We are so enthralled in those goddamn Lighthouse scores, that we risk forgetting about the user.”

But truth be told, Lighthouse has done a lot to make sure that a website is perceived as fast, rather than just loads fast.

Back in the day, we used to simply measure load time and page size – these were the two metrics we were focusing on. That was until one day Google changed the way we thought about performance by introducing Google Lighthouse (…and of course by making it a ranking factor, which we couldn’t ignore).

The metrics we find in the Google Lighthouse performance report are a way to quantify and measure user experience, here including the perceived performance.

Some of the metrics you can use as indicators are:

First Contentful Paint
First Input Delay (can't be measured synthetically)
First Meaningful Paint
Largest Contentful Paint
Cumulative Layout Shift
Speed Index
Time To Interactive

You can run a Lighthouse test via Chrome DevTools or via PageSpeed Insights.

Just remember, these are only indicators and not a metric on how fast your site “feels”. For this, you need to ask the users.

Conclusion

The way humans perceive time doesn’t necessarily match the time we see on a clock. The way we perceive time depends on the activity we’re doing.

Activities can be broken into two states – the active state and the passive state.

In the active state, we have a high mental activity, whereas in the passive state our mental activity is low. In the passive state, we tend to overestimate the time passed by an average of 36%.

We’re constantly switching between the active and the passive state – even when browsing the web. When we wait for a page to load, we risk moving into the passive state.

You can improve your website’s perceived performance by avoiding users switching to the passive state. If they do end in the passive state, you can make tweaks to make the passive state feel faster.

It’s difficult to measure and quantity perceived performance, instead surveys and user tests can be used. The metrics in Google Lighthouse can be helpful indicators for measuring perceived performance.

Acknowledgment

A huge shout-out to Eli Fitch and his great video about “Perceived performance: The only kind that really matters”, which helped form this article!

The same goes for Raelene Morey’s fantastic article on “What is Perceived Performance and Why You Need to Optimize It”, and Luke Jones’s awesome article on “A Designer’s Guide to Perceived Performance”.

Y’all rock 🤘

Examples, as well as tips and tricks, have been shamelessly stolen from these great resources.

Making a fast website is SUPER EASY 😏

Kasper Andreassen — Mon, 19 Sep 2022 07:26:18 +0000

That's right, I said it. Making a fast website is super easy, barely an inconvenience.

I've built a website that gets a perfect score in Google Lighthouse and that can be deployed right to the edge.

It's built completely in a high-performant, battle-tested language that will last for ages.

Want to see for yourself how fast it really is? You can check it out right here: https://enterspeed-hw.netlify.app/

Did you see how fast it was?

Okay, I’ll admit, this was a cheap shot. Some of you might sit with a bitter feeling in your mouth, feeling cheated about this almost clickbaity article. But hang on, there’s a point to the madness.

The point is anyone can make a fast website. Making a website that looks good and has the functionality you want while being high-performant is where the challenge lies.

We have properly all stumbled on a post on LinkedIn where someone is bragging about their website scoring 100/100 in Google Lighthouse.

A score like that is also quite an achievement and should indeed be celebrated. However, I think many of us also have seen high performant websites which, how should I put it… Looks like shit. Excuse my language.

You know the type. Late 2000’s-look, barely any images, maybe a few sorry-looking icons, and just text as far as the eye can see.

Don’t get me wrong – for some websites, e.g., blogs, this makes perfect sense. However, for a website whose goal is to convert customers by selling goods or services, the website should also be attractive to look at.

Whether a website looks good or not is of course, unlike a performance score, highly subjective. As the saying goes: “The beauty is in the eye of the beholder”.

The visual aspect of a site can be costly. Each image, video, custom font, animation library, etc. is an extra request for the user and additional kilobytes which must be transferred to the client.

Another side of the coin is the website’s functionality. My beautiful “Hello world”-example above, written in pure HTML, properly doesn’t scale that well to a full-blown company site.

Then we introduce some kind of framework that increases the bundle size and the response time. How much overhead this framework adds can also vary depending on which you choose, as we found out in our previous article: We measured the SSR performance of 6 JS frameworks - here's what we found.

Okay, now we got the foundation in place – now for the content. Marketing comes up with new ideas almost as often as a new JS framework is introduced. They don’t want to bother you all the time, and just as important, you don’t want to be bothered every time there’s a tiny change to be made.

So now we go and implement a CMS. Depending on how we implement it, this can also introduce additional overhead in the performance. If we render it using SSG, it won’t have any meaningful performance changes. However, if we use SSR (or for some reason you choose CSR – please don’t), then we start seeing some extra requests enter the picture.

Okay, now we have given marketing what they want – a way to edit and publish content, they’re properly satisfied now, right? Oh, my sweet summer child, you have clearly never worked with a marketing department.

Remember the scene in Lord of the Rings where the thousands of orcs attack Minas Tirith? Picture this scene, Minas Tirith is your website, and the thousands of orcs are the shitton of tracking scripts that marketing wants to implement. In this case, you're Gandalf, trying your best to defend Minas Tirith.

As fun as it is to blame marketing for everything, the truth of the matter is they of course play a vital role.

If a website doesn’t get any visitors, it doesn’t matter how fast it is. Moreover, if these visitors don’t convert (buy, sign up, book a call, download material, etc.) it also doesn’t matter.

So, should we then just give the marketing department free rein?

Eh…

Just like a kid with a bowl of sugar, we should still keep a watchful eye and not allow them to turn their bowl of oatmeal with sugar into a bowl of sugar with oatmeal.

As many studies have shown, there’s a direct correlation between how fast a website is and how well it converts.

Also in terms of search engine optimization, core web vitals became an official Google ranking factor in 2021.

Therefore, we must balance the visual elements, the website’s functionality, and the website’s performance so they all can co-exist.

I know what you’re thinking: “Enough fluff talk, this isn’t marketing, what can I actually do”? (Sorry, having switched from marketing to development myself, I simply can’t help it).

And don’t worry, in the second part of this article we will look at some actionable tips.

Making your website fast, functional, and visually pleasing 👌

Let’s try to hit that magical trifactor that makes everyone happy.

Images

Let’s start with one of the big performance sinners – images. Images take up a huge part of the website's total size.

As of August 2022, images made up on average 45% on desktop and 44% on mobile of a page’s total weight. The number of image requests made up 32% on desktop and 30% on mobile of a page's total requests (Source: HTTP Archive).

Optimizing the images can therefore result in big and easy wins. I’ve previously made an article about this exact subject: How to optimize your images for performance.

I will quickly summarize the points from the article and move on to a concrete example.

1. Choose the right image format (JPEG, PNG, GIF, SVG, WebP)
Each image format has its purpose. For instance, PNGs can be great for icons and smaller images, but the file size can quickly become pretty huge for larger images.

2. Be careful with using animated GIFs
GIFS can be fantastic for small “videos”, for instance in tutorials, but they come with a cost. File sizes can be enormous, so consider using a video instead.

3. Always try to compress images
It always amazes me how many kilobytes can be saved by running images through a compressing tool. I once managed to compress an SVG file with around 97% – absolutely bonkers.

One of my all-time favorite tools to use is TinyPNG (aka. TinyJPG). Their UI is beautiful, dead simple and more importantly – they have some insane compression results. They allow compression of PNGs, JPEGs, and WebP-files.

Remember to always check the quality after. One thing many compression tools don’t do well is trying to compress gradient colors – the result can be quite janky.

Online tools I can recommend:

💡 Tip: Squoosh lets you adjust the quality (compression rate) and see the results live.

4. Scale down your images
There’s absolutely no reason in serving a 3000px width image. Moreover, there’s no reason in serving a 500px width image if you only render it in 300px.

5. Serve responsive images
Instead of using a single image for both desktop and mobile, consider serving 3 – 5 different sizes of the image depending on the viewport.

Check out Mozilla's article on responsive images here: Responsive images on MDN.

6. Lazy load images
Never load images until it’s necessary. Lazy loading images helps reduce the number of initial requests and page size resulting in a much faster site.

Nowadays we’re blessed with a built-in lazy loading attribute supported by all major browsers: Browser-level image lazy-loading for the web.

⚠Warning: Never lazy-load your LCP element!

Now, let’s look at an example of how we could optimize one of the big image performance sinners – the hero image.

Optimizing the hero image

Almost all modern websites use some kind of image in their hero section (the area right under the logo and navigation – often mostly used on the homepage).

The hero section may be the most important part of your website since it is responsible for quickly telling the visitor:

What you offer (your product or service)
What your USPs are (Unique Selling Proposition)
Communicating trust (why the visitor should trust your site)
The main call to action (Sign up, book call, buy now, etc).

There are a thousand ways to design a hero section, but for now, we will split it into two categories:

A) Full-size hero image (background)
B) Partial-size hero image (often placed in the right section of the screen and taking up somewhere between 1/2 to 1/3 of the width).

The reason why the hero image is interesting from a performance perspective is that it often will be the LCP element (Largest Contentful Paint), which in the Lighthouse performance scoring is the second largest weighted metric with a 25% weight, only outdone by TBT (Total Blocking Time) with a 30% weight.

Moreover, the hero image tends to also be one of the largest when it comes to file size (especially for full-size hero images).

For the partial-size hero images, depending on their size, they may not be the LCP – this can very well be the heading text – especially on mobile where designers tend to shrink the image to make room for the text and buttons.

So, let’s optimize our hero image. For this example, our hero image will be a full-size hero image.

The first thing we should do is make sure we don’t lazy load our hero image (some might choose to add the lazy=true attribute to all images) since this will negatively impact our score.

The next thing we should do is preload it. Setting your hero image to preload will enable the browser’s preload scanner to load the element early in the page lifecycle.

Source: https://web.dev/preload-scanner/

Be aware, that if you use responsive images (different images depending on viewport size), then you need to specify the imagesrcset attribute on the element.

Thing brings us to the next tip. Use responsive image sizes.

We’re using a full-size background image with a width of 1920px. Loading a 1920px width image on for instance an iPhone SE which has a 375px width viewport would be absolutely insane.

By shrinking from 1920px width to 375px width you can reduce your image size to just a 1/10 of the original size. Talk about saving data.

I know what you’re thinking. Making all these variations sounds like a lot of work. I feel you – I’m lazy too, but luckily there are awesome tools available.

The Responsive Image Breakpoints Generator automatically creates the number of images you wish based on your resolution range. Moreover, it even generates the HTML img tag for you.

The tool is created by Cloudinary (another fantastic service), which also has an API available to upload your images to the cloud and automatically generate breakpoints programmatically.

Long live the lazy 🙌

Now let’s look at optimizing the main image size. In this example, I will be using Photoshop, but there are plenty of free tools available for doing the same.

We want to build this fantastic hero for our website:

We have found this beautiful image we want to use (Shout out to the photographer Matheus Cenali).

Our largest image size will be 1920x1080. Unfortunately, the image is a bit too big with a resolution of 1920x1440. Time for some cropping.

I select the crop tool in Photoshop and input the resolution I want.

Sweet, no redundant pixels here.

Next, I click File > Export > Exports as. Here I can choose image format – and for JPG select image quality while inspecting quality and file size.

If you don’t want to use their predefined Quality scale (Good, Very Good, Excellent, etc.) you can use their legacy export tool, which lets you select a quality from 0 – 100, similar to Squoosh. You’ll find the under File > Export > Save for Web (Legacy).

I usually end up selecting the “Good”-quality, since it often hits the sweet spot between quality and file size.

Now, we could be satisfied with the 188,9 KB file size, which also isn’t that bad for a large background image, but let me show you another cool trick.

As you could see from our hero example above, we want to have a black overlay over the image to better view the text and make the CTA’s stand out.

Aha! Then we just add some CSS to create a black overlay with some opacity, right? Yes, we could do that, but check this out.

Now I take the same Apple image as above, open it in Photoshop and right click the layer, and select Blending options. Click color overlay, select a black color, and chose an opacity (in this example we use 60%).

Now let’s try to export it again in the “Good”-quality as before, which resulted in a 188,9 KB file size.

Our file size has shrunk to 99,5 KB! That’s almost a 50% reduction. Fewer image details result in a smaller image size.

The same would have been the case if we have chosen to blur our image:

Now we have a 78,7 KB file size. I wonder what happens if we add a black overlay to our blurred image?

We will end up with an impressive file size of 49,7 KB. This gives you an idea of how many kilobytes can be saved when playing around with effects in Photoshop.

Okay, enough about images – we could go on forever optimizing the various assets. Let’s take a look at fonts.

Fonts

If there are one thing designers absolutely love, it’s fonts. So, it was no wonder that the entire web design community almost went bananas when Google recently launched their Color Fonts on Google Fonts, which to be honest is a pretty cool feature.

So, let’s talk about fonts and how to optimize them. We’re not going to cover every aspect in this article since, believe it or not, actually is quite a big subject.

First, why are fonts/typography important for web design? Let’s take a look.

1. Readability
Remember the old days of the web where it seemed like a universal law that your site should have an 11px body font? (What is this? A website for ants?)

Luckily the days of squinting our eyes together to browse the web are over. Now most, but definitely not all, websites run a decent font size.

The choice of font is of course also important. The Bureau of Internet Accessibility has recommended the following fonts for accessibility: Times New Roman, Verdana, Arial, Tahoma, Helvetica, and Calibri.

2. Legibility
Related to readability, legibility is the measure of how distinguishable individual characters and words are to the eye of the reader; readability is the measure of how easy it is to read the text overall (Source: Legibility & readability).

3. Color and contrast
Not everyone perceives colors the same way. Some color combinations can be very difficult or impossible for some people to read.

Usually, this is because of poor color contrast (the foreground and the background color being similar).

The WebAIM guidelines recommend an AA (minimum) contrast ratio of 4.5:1 for all text. However, large text (120 – 150% larger than the default body) is an exception, here the ratio can go down to 3:1 (Source: Color and contrast accessibility).

4. Branding
That’s right, you thought we were done with marketing, but just like the Undertaker, they sneak their way in when you least expect it.

Fonts are a crucial part of the brand. They can evoke emotions and communicate what the core of the brand is to the consumers.

Don’t believe me? Check out these fantastic logo swaps and prepare to feel uncomfortable.

Choosing the right font combination for your website can be what makes or breaks a good design. Check out Canva's ultimate guide to font pairing.

Before moving on to how to optimize fonts for performance, we also need to talk about the two basic types of web fonts: Web-safe fonts and Web fonts.

Web-safe fonts
These are the fonts that are pre-installed on your device – also known as system fonts. Examples of these are Arial, Times New Roman, and Courier.

Web fonts
These are fonts not pre-installed on your device and which must be downloaded by the browser before they can be displayed. These can either be self-hosted (on your own web server) or via a third-party host like Google Fonts, Adobe Typekit, etc.

The attentive reader properly already knows which type we’re going to optimize – that’s right, web fonts. As nice as it could be to only use web-safe fonts in your design, it’s hard to make a website look good with just these.

So, let’s see what we can do.

The first thing you should do is to make sure you’re not downloading unnecessary font variations.

If you’re using a theme, boilerplate, etc., it may come with a lot of unnecessary font variations.

Take for instance the popular Roboto font – it comes in 12 different styles (6 different font weights with an italic and non-italic version of each). Each variation is extra kilobytes the user must download.

Luckily, it’s easy to find out which styles you are using and which you are not. Afterward, you can change your link / @import to only download these variations.

Next, let’s see how these fonts may impact our performance score. Web fonts can negatively impact core web vitals like Cumulative Layout Shift (CLS) and Largest Contentful Paint (LCP), and non-core web vitals like First Contentful Paint (FCP), which is also used to calculate the Lighthouse performance score with a 10% weight.

So, how do we optimize all of these? We can’t.

Wait, what? We can’t?

No, optimizing fonts for CLS and LCP/FCP conflict with each other. It all has to do with how we use the font-display property.

When loading custom fonts, each browser has its own behavior. Edge swaps it out with a system font until it’s ready, Chrome and Firefox will wait 3 seconds before swapping it out with a system font and Safari will simply hide it until the font is ready.

We can modify this default behavior by using font-display.

So first let’s try to optimize for LCP/FCP.

The First Contentful Paint will often be your text which, as we learned previously, also can be your Largest Contentful Paint. The quicker these elements load the better.

Therefore, the loading behavior of Chrome, Firefox, and Safari, can potentially harm these metrics. The same if you choose to manually set font-display to “block”, which gives the font face a short block period and an infinite swap period.

We can avoid these “invisible fonts” by setting the font-display to “swap” making the block period extremely small. This will load a system font and “swap the font” when the custom font is ready.

Pretty nifty, but do you know what can happen when you “swap content” during load? Your layout can shift, resulting in a poor Cumulative Layout Shift (CLS) score.

So, unfortunately, there’s no solution that fixes all things. If your text is your LCP, it makes sense to use the swap method, since LCP and FCP have a total weight of 35% (25% + 10%) in the Lighthouse performance score.

But there’s also a way we can reduce the amount of layout shift happening. We can make sure our fallback font best matches our custom font. You can use the Font style matcher tool for this.

Now, let’s try to optimize how fast we get the actual font. We can use preconnect to establish early connections to important third-party origins, here our fonts.

The next thing we can do is to tell the browser to load our font early in the page’s lifecycle. We do this using preload in the link element.

That way our font is less likely to block the page’s render since it will load before the browsers' main rendering engine starts.

Lastly, if you choose to self-host your fonts, make sure you use a modern web font format – here WOFF 2.0. WOFF 2.0 offers up to 30% better compression than its predecessor WOFF.

Third-party scripts (Tracking scripts and other fun stuff)

Now for something that’s even more frustrating than the Game of Thrones ending (I’m sorry Bran, but anyone has a better story than you) – third-party scripts.

From Facebook to Google Analytics, to LinkedIn Insight Tag. The amount of third-party scripts almost seems endless.

When a certain department, who shall remain nameless, then comes to you and ask you to also add the Facebook Page Plugin so “our customers easily can follow our company page”, you can almost feel your soul leave your body.

But don’t worry, there’s a way to overcome these obstacles. Remember what we said about balance?

Let’s start with the easy one – a third-party script rendering content, like the Facebook Page Plugin.

Scripts which are responsible for rendering some kind of content should always be lazy-loaded, meaning the request is first made when you scroll to the content.

The Facebook Page Plugin actually has this built in. Simply insert data-lazy=”true” and you’re good to go.

Now for the more annoying part – all the tracking scripts.

If your website only targets European visitors, you’re in luck. Due to the GDPR, and the ePrivacy Directive you can’t legally set a tracking cookie until the user has accepted it.

This means your initial load time – and here your Core Web Vitals won’t be affected by these third-party scripts.

Problem solved. Shut down your website for the rest of the world and move to Europe – don’t worry, we got beer 🍻

No? Okay, let me show a trick then.

Hold back your requests

First things first. You should of course only load third-party scripts which are needed on the particular page. This means, that if you have a cool animation that requires animate.css (not a script but a stylesheet but bear with me) that you use on your company page – then this shouldn’t be loaded on every other page.

You can use a tool like Google Tag Manager to manage and orchestra all your scripts. This is exactly also what we are going to use for this nifty trick.

Third-party scripts like Facebook Pixel, LinkedIn Insight Tag, or even your chat plugin aren’t strictly necessary to request right away. They can wait until the user has interacted with the site – or some time has passed.

I don’t necessarily recommend doing this with Google Analytics, since you might risk losing valuable data.

However, for all the nice-to-have stuff, they can wait their turn.

So how do we do this?

Inside Google Tag Manager you set up Triggers that tell the tag/script when to fire. These triggers can be conditional, meaning you also can chain them into an OR statement.

So, for our non-critical scripts, we could set up a condition that looked for if:

The user has clicked on any element (useful for navigation)
Has scrolled 5% (indicated the user starts interacting with the site)
5 seconds have passed (our initial load is done).

Be sure to test these things out and see if everything works. As someone who lives under Margrethe Vestager’s watchful eyes, I don’t use this technique myself.

Loading content from your CMS

That’s right, we’ve saved the best for last – serving the actual content.

There are multiple ways to go about it and not a subject we can cover completely in this article.

One way to make sure your content loads really fast is to use Static Site Generation (SSG) which renders your content at build time and serves it as (you guessed it) – static content.

This is really performant, but not always that flexible. Another alternative is to use something like Next.js’ Incremental Static Regeneration (ISR), which is a hybrid between Server Side Rendering (SSR) and Static Site Generation (SSG).

Again, cool stuff – but not everyone can utilize these rendering strategies – many organizations have some dynamic content that needs to be rendered via SSR.

These organizations are also typically not the type you can easily convince to move away from their old CMS and on to the latest and greatest headless CMS.

Fetching data from these CMS’ can be slow and risk creating a bottleneck. So, what do we do?

We decouple it, baby.

If you read my previous article, Using Google Sheets as your CMS, you might be familiar with the concept.

Using a solution like our own product, Enterspeed, you can sync your data to a high-performant data store, and still keep the editor experience. Moreover, you’re able to also transform and combine multiple data sources into a single call – reducing the number of requests.

Decoupling your CMS also brings other benefits. You’re able to scale down your server since it’s no longer going to take the high traffic load.

If you need to do maintenance, you can even shut it off without affecting your site.

Syncing your data to Enterspeed also makes it possible to migrate to another CMS – or a newer version of your current one. Check out how we migrated from a Umbraco V7 setup to an Umbraco V10 setup in no time.

Not to toot our own horn, but that is pretty sweet 🙌

Closing thoughts

This article could go on forever (and it kind of feels like it already has), but we must stop at some point. We haven’t covered all the topics of performance optimization, since there’s enough content there to cover a full book.

Some of the things we didn’t cover were:

The importance of choosing a good web host (We ♥ Netlify).
Lazy-loading videos
Utilizing three shaking when possible
Minifying and compressing your CSS and JavaScript
Using a CDN
Reducing your TTFB
Removing unused code
Removing unnecessary redirects
Utilizing caching
Eliminating render-blocking resources
Using code splitting when possible
Deferring non-critical CSS

Conclusion

It’s not hard to build a superfast website. It can be hard to do this while making it look visually stunning and having the functionality all department wants.

Luckily, we can solve many of these obstacles by doing some optimization tweaks and learning to achieve a balance between speed, functionality, and visual elements.

Remember, Rome wasn’t built in a day. These things take time and comprise sometimes must be made. Talk to each stakeholder for the website and make sure they understand why there needs to be a synergy between all elements.

We measured the SSR performance of 6 JS frameworks - here's what we found

Kasper Andreassen — Mon, 05 Sep 2022 06:35:44 +0000

To say that there are quite a few JS frameworks to choose from would properly be the understatement of the year.

It seems like every few months a new, revolutionary framework enters the ecosystem with promises of unseen performance and/or ease of use.

It's gotten to the point where we almost need a framework to choose our next framework (Yo Dawg).

Although, as nice as it would be for a developer to be able to take a vacation and come back without having to learn yet another framework, we also kind of dig it.

New frameworks often bring innovation to the JS ecosystem. This can be in how we build apps and/or how performant they are.

These performance improvements help push the boundaries on what is possible - and as a result, also help inspire other frameworks to implement similar solutions.

But now for the fun question - is there really that big of a performance difference across the different frameworks? This is the question we wanted to answer.

However, as the quite gruesome saying goes: "there's more than one way to skin a cat" 🙀

As the title of this post might already have spoiled, we chose to test which framework was the fastest when it came to SSR - Server-Side Rendering.

The results were interesting, but just like Formula 1, it was often milliseconds that separated the good from the great.

But before we get into the nitty-gritty, first a very big disclaimer.

🔔 DISCLAIMER - YOUR MILEAGE MAY VARY!

As anyone who has ever run any kind of performance test can tell you - results can vary. You can try your best to make the conditions as uniformly as possible and still get different results.

We have tried to set up each demo similarly to the others. However, there may have been a better way of doing this in one particular framework that we were not familiar with at the time.

If you feel something could have been different and/or better, please drop a comment or send us an email at info@enterspeed.com. The source code for each demo can be found in our demo repo: https://github.com/enterspeedhq/enterspeed-demos

Meet the 6 contestants

The 6 contestants we chose, are a mix of some of the most popular frameworks and some of the newer more hyped ones.

The frameworks we tested were:

Astro: 18,2k stars on Github, created March 2021
Gatsby: 53,4k stars on Github, created May 2015
Next.js: 91,8k stars on Github, created October 2016
Nuxt 3: 8,7k stars on Github, created March 2021
Remix: 19k stars on Github, created October 2020
SvelteKit: 10.1k stars on Github, created October 2020

All 6 frameworks were set up using SSR.

What is SSR?

SSR stands for Server-Side Rendering and is a rendering strategy that converts your application into HTML on the server.

Some other rendering strategies are:

CSR - Client-Side Rendering, which renders in the browser.
SSG - Static Site Generation, which generates the HTML on build (and therefore only fetches data once).
ISR - Incremental Static Regeneration, which is a combination of SSG and SSR that allows you to create or update static pages after you’ve built your site.

Unlike traditional SPA's (Single Page Application) which use CSR to render their content, SSR gives a faster "time-to-content" and is better for SEO, since crawlers will see the fully rendered page.

What we build

Our demo site which we replicated for each framework is a beautiful blog containing 6 blog posts.

It uses Tailwind for styling and fetches its content from Enterspeed (a high-performant data store).

Bonus info - all thumbnails were generated using Dall-E 2 with these phrases:

"A cat driving a formula 1 car digital art"
"A Llama flying a fighter jet, pixel art"
"A cool, fearless bee riding a motorcycle"
"A falcon flying through outer space in a photorealistic style"
"A person outrunning a cheetah, digital art"
"A photo of a teddy bear riding a rocket"

All demos are public and hosted on Netlify:

Astro - https://enterspeed-astro.netlify.app/
Gatsby - https://enterspeed-gatsby.netlify.app/
Next.js - https://enterspeed-nextjs.netlify.app/
Nuxt 3 - https://enterspeed-nuxt.netlify.app/
Remix - https://enterspeed-remix.netlify.app/
SvelteKit - https://enterspeed-sveltekit.netlify.app/

The GitHub repo for all the demos can be found here: https://github.com/enterspeedhq/enterspeed-demos

What we measured and how

To measure the SSR performance of our JS frameworks we used Google Lighthouse (here Web.dev/measure). We ran each audit 5 times and calculated the average for each metric.

💡 An explanation of each metric (and acronym) will come further below.

Google Lighthouse measures Core Web Vitals (LCP, FID, CLS), which has become a ranking factor in the Google Search Algorithm, as well as other web vitals (FCP, Speed index, TTI, TBT, and CLS).

We didn't measure FID (First Input Delay), since this cannot be measured in the lab. However, TBT (Total Blocking Time) correlates well with FID in the field.

CLS (Cumulative Layout Shift) isn't included in the results either, since all the demos scored 0 in this category.

Lastly, we wanted to measure TTFB (Time To First Byte), since it can help measure the web server responsiveness which is highly relevant when it comes to SSR.

To measure TTFB we used hey, where we send 250 requests to each demo and measured the average TTFB.

We noticed that the results fluctuated quite a bit when sending requests to our hosted sites on Netlify, so we chose to run each application locally and measure it that way.

We also chose to reduce the number of concurrent workers from 50 to just 1 since our Nuxt 3 application kept crashing when sending multiple requests.

What does each metric mean?

All metrics (except TTFB) are based on Google's initiative: Web vitals. Google made these metrics to provide unified guidance for quality signals.

✂️ Explanations borrowed from Web.dev

Google Lighthouse Performance score

The Performance score in Google Lighthouse is a score from 0 - 100. It is a weighted average of the Web Vitals score. Each Web Vital is weighted as follows:

First Contentful Paint: 10%
Speed Index: 10%
Largest Contentful Paint: 25%
Time to Interactive: 10%
Total Blocking Time: 30%
Cumulative Layout Shift: 15%

The performance score is grouped into three categories (Poor, Needs Improvement, and Good): Needs Improvement,

0 to 49 (red): Poor
50 to 89 (orange): Needs Improvement
90 to 100 (green): Good

Note: A "perfect" score of 100 is extremely challenging to achieve and not expected.

First Contentful Paint (FCP)

The First Contentful Paint (FCP) metric measures the time from when the page starts loading to when any part of the page's content is rendered on the screen.

Speed Index

Speed Index measures how quickly content is visually displayed during page load.

Largest Contentful Paint (LCP)

The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport, relative to when the page first started loading.

Time to Interactive (TTI)

The TTI metric measures the time from when the page starts loading to when its main sub-resources have loaded and it is capable of reliably responding to user input quickly.

Total Blocking Time (TBT)

The Total Blocking Time (TBT) metric measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input responsiveness.

Time To First Byte (TTFB)

TTFB is a metric that measures the time between the request for a resource and when the first byte of a response begins to arrive.

The results

Drumroll, please... The results are as follows.

Google Lighthouse Performance score

1. 🏆 Astro - 99,2

SvelteKit - 99
Nuxt 3 & Remix - 98,8
Next.js - 98,6
Gatsby - 95,6

First Contentful Paint (FCP)

1. 🏆 Astro, Gatsby, and Remix - 0,8s

Next.js & SvelteKit - 0,9
Nuxt 3 - 1,1

Speed Index

1. 🏆 SvelteKit - 2,3s

Astro & Remix - 2,8s
Nuxt 3 - 2,9s
Next.js - 3,2s
Gatsby - 5,6s

Largest Contentful Paint (LCP)

1. 🏆 Astro - 0,8s

SvelteKit - 0,9s
Next.js, Nuxt 3, Remix - 1.2s
Gatsby - 1,9s

Time To Interactive (TTI)

1. 🏆 Astro - 0,8s

SvelteKit - 1,0s
Nuxt 3 - 1,2s
Remix & Gatsby - 1,5s
Next.js - 1,7s

Total Blocking Time (TBT)

1. 🏆 Astro - 0ms

Nuxt 3 - 20ms
Gatsby - 28ms
Remix - 30ms
SvelteKit - 36ms
Next.js - 54ms

Time To First Byte (TTFB)

1. 🏆 SvelteKit - 62ms

Next.js - 63 ms
Gatsby - 133ms
Remix - 136ms
Astro - 137ms
Nuxt - 438ms

The conclusion

Now, now, before you start burning down the place, remember what we said in the beginning - your mileage may vary!

Based on our results, it seems Astro really is the new, fast kid in the class - although not as much in TTFB.

However, the TTFB results can also be the development server not showing itself from its best side.

SvelteKit also had some impressive results and is also one of the new frameworks getting a lot of praise when it comes to speed.

Does this mean you should skip the other frameworks and choose one of these two? Absolutely not.

Each framework has its use case and its benefits. We are personally big fans of all the fantastic features Next.js provide.

Moreover, many people use a combination of rendering strategies, e.g. SSG for their homepage, SSR/ISR for their blog pages, and so on.

Therefore, choose the framework that best fits your needs.

🩸🔥 Is your blood still boiling and do you need to calm down? Don't worry, we got you.

What is Enterspeed? 🏎

Enterspeed is a high-performant data store that makes it possible to gain speed & flexibility by combining your services.

Connect and combine all your services into a single API endpoint. Easily transform your data with our low-code editor, to get exactly what you need – all stored in our blazing-fast edge network.

Enterspeed is used in this article to give the data layer (the blog posts) high and consistence performance across all the tests.

Sprout endless sites from a single Next.js and Umbraco instance

Kasper Andreassen — Thu, 14 Jul 2022 14:50:16 +0000

Has building ordinary, single websites become monotonous for you? Do you need to let loose and just try something new for a bit? Well, you're in luck, we've got just the thing to spice up your developer life.

In this article, we will show you how to build multiple different websites using just a single Umbraco instance as the CMS and a single Next.js as the frontend. And to get that sweet, sweet performance, we're also going to use Enterspeed as a speed layer to serve our content.

Some of you might sit with a puzzled look on your face, thinking: "Why on earth would one do that? Is this merely an insane idea like using Google Sheets as a CMS?".

Even though I'll admit that we love to push the envelope here at Enterspeed and try out crazy things, there are actually several use cases for this scenario. One of these scenarios is microsites. Microsites can, if used correctly, be an extremely powerful marketing strategy for your business.

Pssst... Don't care about marketing and strategy but simply want the geeky stuff? 🤓 Then you can safely skip the section below.

The power of Microsites 🐜

First of all, what the dickens is a microsite?

A microsite is a small website that exists separate from the primary website, often on its own domain or subdomain. Unlike the primary website, it often has just a single goal, for instance, to promote a single product, service, or event.

Even though they share similarities, a microsite is not a landing page since a landing page is just a single page. A landing page is also focused mainly on hard conversions, whereas a microsite focus can be more about an experience, which can help to assist conversions later down the road.

Let's look at a few examples.

Say we are a business that owns several sub-brands or product lines. Each of these brands/products may have its own unique design and may also be targeting different demographics. This could for instance be a brewery selling both alcoholic and non-alcoholic beers.

Having a unique microsite, where they can fully control the visual identity and the communication, would not only make the message more powerful - it would also help with ad relevance when driving paid traffic to it.

Another similar example could be a brand with a single product that targets different demographics - this could be a nutrient supplement.

The target groups for this nutrient supplement could be:

Older people who wish to reduce the risk of diseases like osteoporosis
Athletes who are interested in gaining the extra performance
Health-focused adults who are all about a healthy lifestyle

Just to name a few. How you market a product to these three groups differs highly - both in communication and design.

A third example could be a product or a service with an extremely long and complicated buyer's journey - for instance prefabricated houses.

The time it takes for a family looking for a house to go from idea (top-funnel) to actual purchase (bottom-funnel) can be literal years.

This whole sales funnel can contain hundreds of touchpoints and consist of several questions like:

"Rent or buy?"
"How much money for a down payment?"
"New house vs. old house"
And much, much, much more...

Having strategic microsites, which assist along the whole buyer's journey can be their bytes worth in gold.

Last example, before jumping into the nitty-gritty details. Say you are a pest control company. You want to increase your organic presence in the search engines to gain more customers and reduce your reliance on SEM (paid advertisement in search engines).

A strategy here could be to build a microsite for each type of house pest, e.g. flies, bed bugs, wasps, rats, termites, etc.

Each of these sites will be highly relevant for this specific topic - and can be easier to build links to (some website owners prefer to link to a topic website instead of a company website).

Phew, that was a lot of marketing talk. To quote Linus Torvalds: “Talk is cheap. Show me the code.”

Setting up your project

This example will be built around our fictional company - Enterbrew.

Enterbrew is a brewery consisting of 4 subbrands targeting different demographics.

Dev Beer
ToBeer
Lorem Beer
Ice beer

Each of these microsites will have a homepage, a page listing the different beers, individual product pages for each beer, and finally an about page.

However, even though we're going to run all of this from the same backend and the same frontend, we're not limited to this structure. If we wanted, we could use different page types for each page.

Let's start by setting up a Umbraco instance.

Setting up Umbraco

Start by downloading and installing Umbraco, e.g. on your local machine (You can also use Umbraco Cloud if you prefer).

Note: We're currently working on an Enterspeed-integration for version 10, for now, we're only supporting V7, V8, and V9.

Afterward, go to the Umbraco Backoffice, click on Settings select Document Types. In this example we're using 4 document types:

Home - the homepage which will also be our root node
Beers - the parent page of all our beers
Beer - the single product page
Content page - used for general content - here our about page

We're not going to go over all the properties of each template, since they can be whatever you want. The important thing is that you set one of your document types, in our example, Home, as your root node. This is done under Permissions in the template, where you set the Allow as root to true.

Next, go to Content and create a new item with the root node type, in our example, Home, you just created. Once it's been created, right-click on it and choose Culture and Hostnames. Add the domain you wish to use for this site, e.g. https://www.devbeer.com.

Repeat the step above for all the sites you wish to create.

Now it's time to set up the Enterspeed integration. Once we've connected our Umbraco site with our Enterspeed account, all of our content will be automatically synced to Enterspeed providing us with a blazing-fast speed layer, and essentially decoupling our Umbraco instance.

But before we start blasting content into Enterspeed, we first need to create a data source inside Enterspeed, which provides us with an API key.

Go to Enterspeed, click on Settings and select Data sources. Click Create Group and give your group a name and a type. Next, add a data source (our Umbraco instance) and select an environment, e.g. Development. Click Add and then click Create.

Pssst... If you don't have an account already, you can create one right here 👉 https://app.enterspeed.com/signup (no credit card required).

Awesome, now we got an API key. Let's head back to our Umbraco instance.

Start by adding the Enterspeed integration via NuGet. We currently have integrations for versions V7, V8, and V9.

Once you have installed the integration, you'll see a new tab under Settings called Enterspeed Settings. Add https://api.enterspeed.com as the Enterspeed endpoint and the API key you just created under API key.

Test your connection and click Save configuration if everything goes well.

All content will now be synced to your Enterspeed account when you save and publish. If you need to seed already published content then click on Content and select the Enterspeed Content tab. Choose Seed and click on the Seed-button.

Excellent - now it's time to set up Enterspeed.

Setting up Enterspeed

Verify that all your content has been synced, by going to Source entities under Home. Choose your data source and check if all your content is present. Furthermore, confirm that the domain you entered under Culture and Hostnames in Umbraco matches the one in the URL column.

If everything is good, then it's time to create our first schemas. So first, what is a schema, and why do we need them?

One of the powerful things about Enterspeed is its ability to transform and model content into exactly the views you need. This is done by creating schemas.

Schemas make it easy to combine multiple data sources, and to make deeply nested properties more accessible.

For our example, we will create a schema for each document type we created in Umbraco, and two for the navigation (one for single navigation items and one containing all the navigation items).

Once we have created and deployed the schemas, a view will be generated for each source entity that matches the schemas trigger.

💡 A trigger defines what you want the schema to "trigger on". It consists of a source group (your data source) and contains an array of one or more soure entity types (types of content).

In the trigger property, we first define the source group (here our Umbraco data source group), and next the source entity types (e.g. our page types).

Furthermore, we also need to define how we want to access these generated views when called from the front end. Here we have two options: Handle and URL.

All the schemas that are based on document types from Umbraco reflect an actual page, therefore we will use the URL route option.

The navigation on the other hand is an entity that will be used across the entire app, therefore we will use the Handle route option.

Let's take a look at each schema.

Beer-schema

This schema gets its content from the Beer source entity type and is routable via URL. The URL value will reflect the one in the source entity, which is identical to the page URL in Umbraco.

We have also set up some actions. The actions here will trigger a process of another schema. Since our Beer is a child of Beers, which will show a list of all its children (Beer), we need a way to update the view whenever its children (Beer) change. This is done via the action type process.

In the process action, we also need to provide an originId, which is the ID of the source entity given upon ingest (In Umbraco it reflects the page ID). We want this originId to be the same as our current source entities' (Beer) originParentId (also given upon ingest, here reflects the page's parent - Beers).

So to sum up actions. Every time one of our Beer views changes, it triggers a processing of its parent, here the Beers view.

Below we have properties, which is the actual content. Here we define a type, that we will use for rendering logic in our frontend and the URL to the page, which we will use to link to the individual beers on the overview page. Last, but not least, we grab all the content we have from Umbraco for this page, by using dynamic mapping. We group all of this under content and map it all out by using: "*": "p"

Beers-schema

Just like the schema above, we have defined triggers, set route to URL, and specified beers as the type under properties.

Under content, there's suddenly a lot going on, and even though it might seem complex at first, it's actually quite simple when we go through it step by step.

Where we before had been working mapping out strings, we now want to output an array. So let's look at the structure.

First, we define the type as an array. The reason why you don't have to do this on strings is simply syntactic sugar since strings are the most commonly used property type.

Next is the input property. This is where you wish to retrieve the collection from. We use the $lookup type to define a query-like criteria that the source entities have to match.

The operator we want is the equal operator and the sourceEntityProperty we want to look at is originParentId. This should matchValue of originId (which here is the Beers originId).

So in other words. We want to source entities that have Beers originId as their OriginParentId. All the children of Beers.

Cool. Now the last part - the content. The items field is used to map the results.

The type we are using here is a reference type, which is used to reference another schema - in this case the Beer schema we created before. We reference another schema using the schemas' alias - which happens to also be beer.

Lastly, we need to specify the ID of the source entity, which is found under id, and since we're looking for it "inside" one of the items, we prepend it with item, which then becomes: item.id

And voilà. We now have an array of all our beers 🍻

Home-schema

And now to relax with a simple schema. We grab the home source entity type, make it routable via URL, set the type to home, and dynamically map all the content under content.

Page-schema

This schema is structured the same way as the Home-schema.

Navigation item-schema

Now it's time to create our individual navigation items. First, we define which source entity types we want the navigation to consist of. In our example, we just want a very simple navigation, consisting of only parent pages (meaning not the individual beers). We also don't want it to include our homepage since we will use the logo for navigating back to it.

Unlike our previous schemas, we don't include a route, since this schema only will work as part of our navigation schema, and never will be called from the front end.

Under actions, we do the same as we did in the Beer schema. We tell it to process its parent whenever something new happens to views with source entity type page or beers. The parent in this case the site node, home.

For properties, we grab the metaData.name for the label, the type we have given our other schemas, and the url for href. From Umbraco, we also get a sortOrder, which we can use to sort our navigation in the front end.

Navigation schema

Just like a decorative oriental rug, it's time to tie it all together. We use our root node, home, as our source entity type.

In route, we will use handles, since the navigation is a component that will be fetched throughout the website, and not just a page.

However, since we're building a multi-site solution, we need a way to differentiate the navigation for each site from the other. We do this by appending the handle, navigation, with -{url}, which inserts the URL for home, which is the root URL.

Inside properties, we create an array that, just like our Beers schema, uses a reference to another schema, here navigationItem.

That was the last schema we needed to create. Now we just need to deploy our schemas so our brand new views can be generated.

Once you have deployed the schemas, you can navigate to Generated views under Home to see the result.

Creating environment client(s)

The last thing we need to do is to create one or more environment clients.

"Well, what is it, one or more?" you ask.

Normally you have one environment client per website and, as the same suggests, per environment.

However, we are building a multisite based on a single Next.js instant, which makes it a little different.

If you want to use Enterspeeds Routes API, for instance, to build a sitemap, then you need individual environment clients. If not, then you can do it with just a single environment client. So, the choice is yours.

Don't worry, we will show you how you can support multiple environment clients later on.

To create an environment client, go to Settings and select Environment settings.

If you have done everything correctly, then you should already see a list in the Domains section of all the domains you have entered in Umbraco under Culture and Hostnames. If not, then you need to manually create them and their hostnames. But for now, let's assume you've done everything correctly - well done 🎉

Go to Environment clients and click Create. Give your environment client a name and choose an environment. Then click Create. Next, choose all the domains you want to attach to this environment client. If you're planning on only using one, then select them all.

Note: If you add more sites in the future, you need to go to edit the environment client and add these domains.

Now that we're ready to move on to the front end - our Next.js instance. Here we will also meet a very famous, red crustacean, which unfortunately is not Zoidberg.

Setting up Next.js

Now it's time to set up our front end. For this, we're going to use Next.js, Express, and the secret sauce which makes it possible to use just a single Next.js instance, Krabs.

What is Krabs? The author describes it as: "...an enterprise-ready Express.js/Fastify middleware for serving thousands of different websites from a single Next.js instance."

Pretty freaking cool - and with an awesome name nonetheless.

Shout out to Michele Riva for this awesome package 👏

Note: Krabs forces you to use a custom server. Therefore, deployments to Vercel are not supported. Krabs is also only supporting SSR at the moment, and not SSG nor ISR.

First things first - start by creating your Next app. Next, install Krabs and Express.

Note: The steps for the Krabs configuration are borrowed from their documentation.

Create a new file called server.js. This will be the entry point for our custom Express.js server, which handles our Next.js instance.

Next, create a file called .krabs.js (or .krabs.config.js) inside your project's root folder. Krabs will automatically import the configuration from this file.

We have extended the standard configuration by also adding a property called enterspeedDomain. The value for the enterspeedDomain should be the same as the one given in Enterspeed (and Umbraco).

To actually see what we're doing, we need to configure our hosts file. Insert all the domain names you want to view in your local environment.

Awesome, now to create the "home" for each website. Inside your pages directory, create a folder for each of your websites matching the name provided in the Krabs configuration file.

Note: _app and _document pages are common to every website.

To test out that everything is working, you can create an index.js file with a simple "hello world"-function for each of the websites.

To see the result run: node server.js

If everything is working correctly, you should now be able to view each website using the URL you entered in your hosts file and Krabs configuration.

Next, let's create our connection to Enterspeed. Create a file called enterspeed.js

We have a call function and a function for each route type: getByHandle and getByUrl. You will notice that we in the getByUrl function have extended the response with meta, that way we can correctly handle 404-errors. Each of the functions calls our call function with a handle/url and a "tenant" (the website name configured in Krabs).

The reason why we include "tenant" is so we can differentiate between our websites and use a different environment client for each - if we choose. In our example, we have simply used the same.

Next, create an _app.js file in the pages directory. Here we will get the tenant name (website name), the enterspeedDomain, and also fetch our navigation.

In our App.getInitialProps you'll see we fetch the navigation via getByHandle and we add the ${enterspeedDomain} to the name, which matches the route name we created in our navigation schema in Enterspeed.

The tenant and enterspeedDomain are then added to the pageProps, which gets returned alongside the navigation. These are now available in our App function.

In our App function, you'll see we expand the tenant object to also include something called tenantDetails. This is simply some extra layout configuration we've added, which also could have been done in Umbraco. This is just to show how the front-end developer could do this if they didn't have access to the Umbraco instance.

We've chosen to add it in a separate file and not the Krabs configuration, so as to not mix layout specific into the Krabs configuration.

Lastly, we wrap the App Component with a component called MainLayout, where we pass tenant and navigation as props. Let's take a look at that component.

We've made a simple layout, based on the awesome UI framework - Chakra UI, but here's the neat part. We could have used a completely different UI framework/library for each of our sites - without hurting the main performance.

Yes, you read that correctly. Talking about bringing power and flexibility to the developer.

No more internal battles between developers on which UI framework/library to use. No more trying to argue if Tailwind CSS is pure evil or not. Just like an old Burger King commercial, everybody gets it their way.

You are now able to choose the UI framework/library that best fits the use case.

We can achieve this by using Next.js' Dynamic Import. In our _app.js file, instead of using the MainLayout component, we could have used a unique component for each website, based on the tenant name (website name). This could look like this:

Now, let's look at how we could set up the pages. We're going to use Next.js' Dynamic Routes - more specifically their Optional catch all routes. This will allow us to catch all routes and match them with the corresponding view in Enterspeed.

Inside each of your website folders, create a file called [[...slug]].js

In our getServerSideProps function, we hook into its context and grab the tenant, domain, and slug. We pass these three variables on to the getByUrl function we wrote in our enterspeed.js file, which we set as our data variable.

We then check to see if data.status is equal to 404, if so we change the statusCode in our response object to 404 and set our notFound variable to true.

The data and the notFound are then returned as props.

In our Content component we check to see if notFound is true, if so we use Next.js' Error component, if not we return our custom Entity component.

Our Entity component is responsible for rendering the correct components, based on the type we defined in our schemas earlier.

You may be thinking: "Hmm, but what if I want to have a custom layout for just one specific page? Should I then create a whole new schema with its own unique type?"

Nope. Next.js got your back. Predefined routes always take precedence over dynamic routes.

This means if you want a unique layout for your Contact page, you simply create a page called "contact.js", and this will now respond to domain.com/contact.

Well, to round things up, let's look at how we would use our data to display a list of our beers.

All of the data has been passed to the view prop, so all that is left is to map over our array of beers and render them in a nice grid view, which will look like this:

The code, which is based on Chakra UI, could look something like this:

That's it. We hope you enjoyed the article and it provided some inspiration on how microsites can be used.

Cheers 🍻

Using Google Sheets as your CMS

Kasper Andreassen — Thu, 16 Jun 2022 10:02:15 +0000

Spreadsheets. They are everywhere.

Managers especially seem to love them, which is why the world properly would stop functioning without them.

Like some twisted version of Murphy's law, it seems that anything that can fit into a spreadsheet eventually will end up in a spreadsheet.

This can result in abominations like a Microsoft Excel database for Covid-19 results.

Well, following in the spirit of using spreadsheets other ways than intended, I thought - what if we could use a Google Sheet as a CMS?

Hold on. Hold on. Lower your pitchforks and torches - this is merely a proof of concept to see how it could work. However... there might be some use cases for this - stick around to the end to find out.

So first thing first, how do we do it in a performant way? We could set up a script to generate a static site, which is something other developers also have played around with before.

However, we don't want to have to trigger a build each time we push a change in our sheet. We want to be able to use SSR, ISR, or CSR in a performant way.

What we want to do is decouple our Google Sheets so that it only works as a CMS and not a database.

Luckily, decoupling data is where Enterspeed really shines.

So let's get to it.

Step 1: Set up a Google Sheet

First, start by creating a Google Sheet. In our example, we're going to make a list containing all the movies from the best movie series in the world.

No, not Marvel or Star Wars. I'm of course talking about the one and only: Olsen Banden (The Olsen Gang).

The list contains the following columns:

The number it has in the series (Number)
The movies name (Name)
Which year it was produced (Year)
A link to the movie cover image (Image)
A link to its IMDB page (IMDB)
A short description (Description)

All content above is shamelessly copied from IMDB.com.

Now that we have all of our data, it's time for step 2 - setting up a script that ingests all the data into Enterspeed.

Step 2: Set up a Google Apps Script

Inside your Google Sheet, click on Extensions and select Apps script.

First, we create a function called ingestToEnterspeed.

Next, we declare two const to make the code easier to read:

sheet which equals SpreadsheetApp.getActiveSheet() - this grabs our active sheet.
sheetData which equals *sheet.getDataRange().getValues()*this grabs all the data from the active sheet.

Now, we take our sheetData-*const and run a *forEach function. We grab the index (i) of each, so we can:

Skip the first row, since this is the header
Know which row number to grab data from

Since our row numbers, unlike our index, don't start at 0, we declare a const called rowNumber which equals i + 1.

Next, we declare a const for the ingest URL to Enterspeed (ingestUrl). The part after /v2/ will be our originId inside Enterspeed and needs to be unique.

Since we're only going to be ingesting "Olsen banden"-movies, we will simply use "olsen-banden-" + the movie's number in the series - here found in column A. We could also have made a function that grabs the sheet name and combines it with the row number instead, to make it more dynamic.

The function we use to grab the cells content is: sheet.getRange('A' + rowNumber).getValue() - this takes the active sheet, finds the defined column for the defined row number and gets the value.

Now, we create an object called payload, which specifies what we will send to Enterspeed.

In the object, we need to define three properties:

A type (in our case we simply call it 'movie')
A URL, if we want it to be routable (if not, we can simply write null)
Properties, which is our actual content

Our URL follows the same pattern as our originId "olsen-banden-" + the movie number.

Inside the properties object, we define all the data which we wish to use. The name of the keys can be whatever you like - to keep it simple we just matched the name of our columns.

Then we use the same function as before to grab the content from the cell we want.

Once we have defined our data (payload), we need to make an options object, which we will use in our fetch function.

Create a method property and set it to post. Then create a headers object where you define a x-api-key property. Insert the API key for your data source, which you have created inside Enterspeed. Lastly, create a payload property and insert JSON.stringy(payload).

Next, for 💩 and giggles we can choose to log out each row inside Google Apps Script, to see what's going on, using Logger.log('Ingesting: ' + row).

Now, it's time to ingest the data using the build-in UrlFetchApp. *Use the *fetch *method and set *ingestUrl *and *options as parameter: UrlFetchApp.fetch(ingestUrl, options);

Click Save project and then click Run. You should now be able to see your content inside Enterspeed. Hooray 🎉

As a bonus, we can create a function that adds a menu item to your Google Sheets menu. This makes it easier to ingest data from the sheet.

Google Apps Scripts even support triggers, which means you can set it up to ingest at time-driven events. That's pretty neat.

Next, we need to ingest a parent source into Enterspeed, which acts as a parent for all our movies.

Step 3: Ingest a parent source

Since we want to create a list of movies, we need to have each individual movie attached to a parent.

You might have noticed that we added "originParentId": "movies" in our Google Apps script. This is the one we're going to create.

We could add many interesting details to this source entity, e.g., a description of the movie series, trivia, etc. But for now, we will simply ingest an empty source entity into Enterspeed since it only needs to act as a parent.

So bring out your favorite API platform, e.g., Postman or Insomnia, and ingest an empty source entity into Enterspeed with the originId "movies": The URL should look like this: https://api.enterspeed.com/ingest/v2/movies

Remember to add your source API key as a header using the "X-Api-key"-key.

Awesome. Now that we got all of our data into Enterspeed, it's time to create a schema that generates the view we wish to use.

Step 4: Create a schema in Enterspeed

Open Enterspeed and create a new schema.

We're going to create a collection schema, which generates a single view for all the movies.

Since we have ingested all of our rows individually (with the URL property), we also have the option to make separate pages for each movie.

However, for now, we will simply make a collection schema.

We start by setting up our triggers, where we define which data source it should use - and which source entity type (here, we use the "movies"-type which we just ingested in our "parent" source entity).

We then choose how we should be able to "get the content" – this can be either via a handle or via a URL. In our case, we choose a handle called movies.

In the properties-object is where we define the actual content. We create a property called movies, which has the type array. In the input property, where we define the items we want to work with, we look for source entities with an originParentId that matches our originId (the "parent" source entity - movies).

For ease of use, we set the collection iteration variable name to movie instead of the default item using the var property.

Under items, which are used for mapping results, we choose to grab all the data and wrap them in an object called movie. We're able to grab all the data by using dynamic mapping.

That's it. Then we save the schema and deploy it to the environment we wish.

All that's left now is to fetch the data from the frontend

Step 5: Fetching the data

Now to actually show the data.

We fetch it using the Enterspeed Delivery API. We call the URL and add the handle we wish to fetch (here movies): https://delivery.enterspeed.com/v1?handle=movies

In our headers, we insert our Environment Client API key in the X-Api-key property.

Afterward, we iterate over all the movies and insert them into a card component (in this case we have used Bootstrap).

Voilà. We have successfully used Google Sheets as a CMS - but is this merely a proof of concept, or?

Google Sheets as a CMS - madness?

So could Google Sheets work as a CMS? In my opinion, yes.

Now, I know what you're thinking: "Madman! You're a madman! No man, developer or client, should use Google Sheets as a CMS!"

But oh, I've chosen my words carefully.

(P.s. if you don't get the reference - here you go).

Which CMS you should use all depends on the use case. Should you use Google Sheets for a blog? Properly not. A full fledge company website? Also no.

But say you are a small café, that often switches up its menu and wants to display the dish of the day. Or a small soccer club, that wishes to showcase all their players. Then yes, it could definitely work.

Since we decouple the data from the actual Google Sheets, it doesn't really matter performance-wise where you edit your data.

Also, Enterspeed allows you to transform and combine multiple data sources, which means you could use Google Sheets only for a small section of your site - e.g. your team section.

So the moral of the story is - once you have decoupled your data, it doesn't really matter how/where you edit it.

I hope you enjoyed the article. You can find all the code used here: https://github.com/enterspeedhq/enterspeed-demos/tree/master/vanilla-js-google-sheets

Enabling Preview mode in your Next.js application

Kasper Andreassen — Wed, 08 Jun 2022 09:41:12 +0000

There's no doubt about it - Jamstack is here to stay. Since Matt Biilmann took the concept mainstream back in 2016, a whole ecosystem based upon this architecture has sprung up (including our very own Speed layer, Enterspeed - but more on that later).

Developers love the benefits a Jamstack architecture can bring to both the site itself and the workflow of the project. We won't dive into the many benefits in this article since books could be (and have been) written about this subject.

However, a site is rarely run by developers alone, but by a wide range of people, e.g., content creators like copywriters, marketers, supporters, etc. All of these people have to be taken into account when developing a new site.

Most content creators have worked with some sort of CMS in the past, for instance, WordPress, and have gotten accustomed to the editor experience.

One of the key functionalities, that content creators often use, is the option to preview their content before publishing.

This can be kind of tricky when using SSG (Static Site Generation) since we want to render these pages at request time instead of build time.

And even though we developers consider our IDE our second home, most content creators aren't that keen on booting up a local instance of the project in order to preview their content (I know, right?).

Luckily, the awesome team behind Next.js came up with a brilliant solution to this problem - Preview mode.

Setting up Preview mode enables you to bypass SSG and render the page at request time. So how does it work and how do we enable it? Let's look into it.

Setting up Preview mode in Next.js

👉 Note: This article is based on the Next.js' fantastic documentation, therefor similar phrasing and code examples will occur.

In the Next.js repo, you'll find plenty of examples of how to set up your headless CMS with Next.js' Preview mode. In this tutorial, we will base the examples on our own solution, Enterspeed.

What is Enterspeed?

Enterspeed is a Speed layer that lets you connect and combine all your services into a single API endpoint. Our low-editor makes it easy to transform your data, to get exactly what you need – all stored in our blazing-fast edge network.

This makes it ideal for speeding up legacy systems, e.g. Umbraco solutions.

Well, enough self-promotion - this was simply to give you some context for the examples below.

1. Creating a Preview API route

Next.js provides a solution to build your API. This is done by creating a folder called api inside the pages folder (pages/api). Any file inside this folder will be treated as an API endpoint instead of a page.

Create a file called preview.js (or .ts if you're using TypeScript) inside the pages/api folder.

On the response object (res), we will call setPreviewData, which will turn on preview mode by setting some cookies.

Once you've accessed the API route, you can open your browser's developer tools to see that the __prerender_bypass and __next_preview_data cookie have been set.

💡 Tip: You can specify the preview mode duration. setPreviewData takes an optional second parameter (the options object). Inside the object, set the key to maxAge and the value for how long the preview session should last (in seconds).

All requests to Next.js which have these cookies will now be seen as preview mode, which will modify how statically generated pages behave.

Since you don't want anybody accessing your preview content, a good idea is to create a secret token string for your preview URL. You can use one of the many token generators out there, for instance, RandomKeygen.com to generate your secret token.

💡 Tip: Store your secret in an environment variable and have your team save the preview URL (including the secret token) in a password manager like 1Password.

👉 Note: If your headless CMS supports setting custom preview URLs, you can implement a fetching logic that redirects to the fetched post. In this example, we simply redirect to root.

Next, let's implement a way to disable preview mode again, by clearing the Preview mode cookies.

Create a new file in the api-folder (pages/api) called clear-preview.js. Here you need to call clearPreviewData on the response object.

Once you've accessed this API route, you can open your browser's developer tools to see that the __prerender_bypass and __next_preview_data cookie have been removed.

💡 Tip: For a cleaner URL structure, you can create a folder inside the api-folder called preview and rename preview.js to index.js. Then you can simply name clear-preview.js to clear.js, which will be available via /api/preview/clear.

2. Updating getStaticProps

The getStaticProps function is used in SSG to pre-render a page at build time using the props returned by getStaticProps.

However, when Preview mode is enabled, getStaticProps will be called at request time instead of at build time.

It will also have a context object where context.preview will be true, which is the one we will use. To make the code easier to read, we can destruct the context object like this.

Next, we will fetch different data based on whether preview is true or not. How this is done can vary based on your CMS.

In our case, using Enterspeed, we have an API call function that takes the preview context as a parameter. Based on its value (true/false), it will either fetch content from our preview data source or production data source.

👉 Note: Enterspeed stores preview data in a separate data source, this may not be the case for your solution.

Inside our getStaticProps function, we pass the Preview context to our getByUrl function, which passes it to our API call function.

Bonus tip: Implement a preview bar

To help our content creators know if preview mode is enabled or not, we have implemented a "preview bar" in our project.

There are multiple ways of doing this, each with its own drawbacks.

Since we wanted the preview bar to be visible across our entire site (to make sure the content creator knew they had preview mode enabled), we decided to set a session cookie once Preview mode had been enabled.

We could have used getInitialProps, to check for the Preview context in our _app.js, unfortunately, this disables Automatic Static Optimization, which we are not interested in.

Since we can't set a session cookie via our API route, we passed the query /?preview=true&secret=${process.env.ENTERSPEED_PREVIEW_SECRET}

on our res.redirect in api/preview.js. The secret isn't strictly necessary, but simply to help ensure that the preview parameter is set via the API route.

Next, we created two helper functions, one of which checks to see if the previewMode session cookie is set to enabled, and one which manages the previewMode session cookie. It checks to see if the preview parameter is true and if the secret parameter matches our secret, by using the next/router.

If so, we set the session cookie previewMode to enabled. If the preview parameter is equal to "clear", we then remove the cookie again.

In both functions, we also check to see if we have access to the window object, so we can set the cookie.

Inside our _app.js we then call our managePreviewSessionStorage() function. We also check to see if checkPreviewSessionStorage returns true, if so we render our PreviewBar component.

And that's it. Now both developers and content creators can be happy 🙌

👋 I hope you enjoyed the article if you are interested in knowing more about Enterspeed you can check us out at enterspeed.com

What is "White Screen of Death 💀" (WSoD), and how do you detect it in time?

Kasper Andreassen — Wed, 21 Apr 2021 09:27:52 +0000

⚠️ NOTE: This article and its solution are based on our own product - Alertdesk, which is a paid product. If you have an alternative solution to the problem, feel free to post it in the comment below.

Website errors. They come in all shades and are every website owner's fear.

What if I told you that there was an error so cunning that it was named after Death itself? Then you would be scared. Very scared 😱

If we turn down the drama a bit, then "White Screen of Death" (WSoD) is an extremely irritating error. Why?

It makes your page inaccessible to visitors.
It can shut you out of your backend (e.g., the WordPress admin area).
It can occur suddenly and without you making any changes yourself.
Most "Uptime Monitoring" services will not necessarily catch the error.

To put it mildly, it's annoying as hell.

But what exactly is the "White Screen of Death," and how does it occur?

What is White Screen of Death?

"White Screen of Death" is an error that gives the visitor a white/blank screen. There is often no information about the error, just the color white as far as the eye can see.

It may occur as a result of a PHP and database error. Therefore, it also affects many CMS', including Magento and PrestaShop.

But where the error is most prevalent is probably at the world's most popular CMS, WordPress, where it has even found a place in the official documentation. Therefore, this article will also be based on WordPress.

The most common cause of a WSoD-error is a faulty plugin or theme. Other reasons can be:

A syntax error in the code - e.g., if you have made edits yourself.
The Memory Limit is set to low in either your wp-config.php file, .htaccess file, or php.ini file.
A failed auto-update of WordPress - e.g., due to a server timeout.
Problems with your File Permissions.

How do you fix it?

You start by finding out what is causing the error. It may sound easier said than done when all you have to work with is a blank screen. But fear not.

WordPress has a built-in debugging mode that makes errors visible on your page.

To enable it, open your wp-config.php file and find the following line:

define( 'WP_DEBUG', false);

Then change false to true, so it looks like this:

define( 'WP_DEBUG', true);

Error messages will now be visible on your page.

💡 Tip: If you are not that much into messing with files, then the WP Debugging plugin does the same (obviously requires you to be able to get into the WordPress admin area). However, this is Dev.to so this properly isn't the case.

In the vast majority of cases, it will be a plugin that is causing the error. You will be able to see the name of the plugin in the error message.

If you have access to your WordPress admin area, simply deactivate the plugin on the "Installed plugins"-page.

If you can't access the admin area, you can deactivate the plugin manually via an FTP program or your web host's "File Manager"-tool.

Go to your plugin folder (wp-content -> plugins) and find the plugin that throws the error. Then rename the folder to something else, e.g., from "hello-dolly" to "hello-dolly-1". The plugin will now be disabled.

💡 Tip: Plugins can also be disabled via phpMyAdmin and WP-CLI - I just find this solution the easiest.

Reload your page and see if the issue is resolved.

What can be done to detect it in time?

One of the most annoying things about the WSoD error is that it can occur suddenly - even without you actively changing anything on your website.

What's worse, if you have traditional "uptime monitoring" enabled, it will not necessarily catch the error.

Yes, you read that right. Most services, including Alertdesk, look at your site’s HTTP status code. If the page gives a status code 2XX or 3XX, it gets interpreted as up, where status code 4XX and 5XX gets interpreted as down.

"There's got to be a better way!" you may think - and for fear of sounding like a classic American infomercial: Yes, there is.

When you set up an Uptime-check in Alertdesk, you have the option to set up specific "rules" for that check. We call this Assertions.

One of the rules you can set up is that a piece of text must be present on the page in order for it to be "up".

This is a super powerful tool when it comes to checking for WSoD errors.

If the text is not visible (which it won't be in the event of a WSoD error), your check will get marked as "down". You will then get notified immediately by E-mail, Push, Slack, or the channel you have selected.

How to set up an Uptime-check with Assertions in Alertdesk

Start by creating an account on Alertdesk. Go to Monitoring, click the "Add check"-button and choose "Uptime check". Enter your URL and click the "Advanced settings"-toggle in the right corner.

Scroll down to Assertions and select "Text body" under "Source", Contains under "Comparison," and then paste the piece of text that should be present on your page under "Target" (is case sensitive). Then click the Add-button.

⚠️ NOTE: There may be issues with special characters, as they may be converted to HTML characters instead, which will not match. Therefore use text without special characters.

Then click the Next-button. Select who to notify and then click the Next-button again. Give your check a name and make sure everything looks fine. Finally, click Save check, and you are done.

Easy peasy lemon squeezy 🍋

You will now get notified immediately if your website should get a “White Screen of Death” error.

Make your pages look good on social media 🤳

Kasper Andreassen — Mon, 19 Apr 2021 07:16:30 +0000

You’ve made sure your pages look good and attract customers. But how do your pages look “offsite”?

More specifically, how do your pages look when they get shared on social media sites like Facebook, LinkedIn, Twitter, and Pinterest?

This is how our site, Alertdesk.com, looks:

How Alertdesk.com looks when shared on Facebook.

How did we achieve that? The answer is social tags.

Social tags refer to Open Graph and the Twitter Cards, which are meta tags you place in the

-section of your pages.

Setting up social tags can make your pages more eye-catching when shared on social media. Properly set up tags can also help sites like Facebook to better understand what your content is about.

Types of social tags

There are essentially two types of social meta tags – those who work on Twitter and those who work on every other site, roughly speaking.

These two types are called Twitter Card and Open Graph.

Twitter Card, developed by Twitter (who would have guessed?), mainly works on Twitter. By adding it to your pages, users who share your pages on Twitter will have a “card” added to their tweet. You can read more about Twitter cards here.

Open Graph, developed by Facebook, works on a few more sites than just Facebook. LinkedIn and Pinterest, to name a few, also support the Open Graph-format. You can read more about the Open Graph protocol here.

Which tags should you use?

There are many kinds of Open Graph- and Twitter Card tags and attributes. We’re not going to cover them all in this article.

The tags below are the ones you should have to help sites like Facebook and Twitter better understand your content.

Open Graph tags

og:title – The title of your page (doesn’t have to match your page title).
og:url – The canonical URL of your page (all shares will go to this URL).
og:image – The URL of the image you want to appear in your social snippet (recommended resolution 1200×627 px).
og:description – A description of your page (doesn’t have to match your page’s meta description).

It can also be a good idea to add:

og:type – The type of content (Article, website, video, etc.).
og:locale – Your page’s language (Facebook will assume this is “en_US” if no other is set).

Twitter Card tags

twitter:card – The type of card you want – choose between 4 types.
twitter:title – The title of your page (doesn’t have to match your page title).
twitter:description – A description of your page (doesn’t have to match your page’s meta description.
twitter:image – The URL of the image you want to appear in your social snippet (1:1 aspect ratio – minimum 144×144 px and maximum 4096×4096 px).

Note: For Pinterest, there are a few more Open Graph tags available. You can view Pinterest’s documentation here.

How to set up your tags

If you are using WordPress, several plugins can get the job done. SEO plugins like Yoast SEO and RankMath both have a social feature, where you can customize your Open Graph and Twitter Card data.

Almost all CMS’ either have this functionality natively, like Squarespace, or has some kind of plugin or add-on for it like Magento.

How to view and debug your tags

Sometimes you may need to test and debug your tags. For that, you can use these tools to get the job done:

🤳 Use Alertdesk to check your social tags

In our social & content reports, you can see how your page will look on Facebook and Twitter when shared.

We also check to see if you are missing any of the recommended social tags (the ones mentioned above).

Check your social tags today with Alertdesk. Try us free for 14 days.