DEV Community: mrcaidev

Web Performance: Images

mrcaidev — Sun, 22 Jan 2023 04:00:16 +0000

High-quality images can significantly boost your website's appeal. They make an excellent first impression on users and effectively communicate your insights.

However, according to Web Almanac 2022 statistics, images are also the leading cause of website performance issues, with a staggering page weight of 1000+ KB, which is twice that of JavaScript.

We want to deliver high-quality images while minimizing performance loss, which necessitates extensive and in-depth image optimization.

🔽 Reduce Image Quality

Among all possible solutions, brute force always seems to be the most intuitive one. The less information in an image, the easier it is to compress, the better the performance.

Blur: If we only want to emphasize the foreground of image, we can blur the background, which reduces the amount of information while keeping all of the important parts.
Zoom: Zoom out to 87% of the original image, and then zoom in to 115% of the current one. In the end, the size did not change, but many pixels vanished during the zooming process.
Tool: Use tools like Squoosh to further compress the image.

After the above processing, the size of an image can be reduced to ~3%, with humans barely noticing the difference.

🎞️ Choose Correct Format

Scenario	Format
Ordinary Pictures	WebP, Jpeg
Complex graphics	PNG, Jpeg
With transparency	PNG, WebP
Icons	SVG
Dynamic	Video

🤔 Other

Adjust the width to somewhere between 320px and 1920px.
Opaque is preferred to transparent.
Remove all unnecessary shapes in SVG.
Integrate tools like Sharp and Imagemin into the build scripts.

🖼️ Responsive Images

If we provide a 1920px wide image for laptops, mobile devices will also receive the same 1920px wide image, which is completely unnecessary.

srcset is a native attribute of <img> that allows us to provide images of different sizes for devices of different widths. The size attribute can then be used to run media query based on these images.

<img
  srcset="image-small.jpg 320w   👈 for devices under 320px
          image-medium.jpg 600w  👈 for devices under 600px
          image-large.jpg 1200w  👈 for devices under 1200px
          image-full.jpg 1920w   👈 for devices under 1920px
         "
  size="(min-width:1200px) 1200px, 100vw  👈 1200px for devices above 1200px, or 100vw otherwise"
  src="image.jpg"
  alt="A nice image."
/>

Typically, 4-5 options would suffice. Going too far is as bad as not going far enough.

🛏️ Lazy Loading

The image is not loaded until the user scrolls to it.

<img src="image.png" alt="A nice image." loading="lazy" />

Simple as the attribute is, it can boost the performance a lot. loading="lazy" should be the default for every image.

Exception: It is not recommended to apply lazy loading to LCP. It would only have negative impacts on the performance.

How to Use Axios Interceptor in TypeScript

mrcaidev — Thu, 17 Nov 2022 05:01:22 +0000

It's a common practice to retrieve res.data in an Axios response interceptor, but TypeScript knows nothing about it. How can we inform the type system?

🤔 Problem

If we don't add a response interceptor, Axios will return such an object rather than the actual data:

{
  "data": {
    // Actual data
  },
  "status": 200,
  "statusText": "OK",
  "headers": {
    // Response headers
  },
  "config": {
    // Axios configuration
  },
  "request": {
    // Request details
  }
}

So it's a common practice to add a response interceptor:

const axiosInstance = axios.create();
axiosInstance.interceptors.response.use((res) => res.data);
const res = await axiosInstance.get("/api");

Thus, the res variable on the final line will be the actual data, saving the trouble of retrieving res.data every time.

But the problem is that TypeScript is not able to detect this interception. In the example above, although we actually get res of type T, TypeScript still assumes res to be of type AxiosResponse<T, any>.

💡 Solution

Coming from Axios repository's issues #1510.

We can override Axios' native type declaration by manually creating a .d.ts file:

// src/types/index.d.ts
import axios from "axios";

declare module "axios" {
  export interface AxiosInstance {
    request<T = any>(config: AxiosRequestConfig): Promise<T>;
    get<T = any>(url: string, config?: AxiosRequestConfig): Promise<T>;
    delete<T = any>(url: string, config?: AxiosRequestConfig): Promise<T>;
    head<T = any>(url: string, config?: AxiosRequestConfig): Promise<T>;
    post<T = any>(
      url: string,
      data?: any,
      config?: AxiosRequestConfig
    ): Promise<T>;
    put<T = any>(
      url: string,
      data?: any,
      config?: AxiosRequestConfig
    ): Promise<T>;
    patch<T = any>(
      url: string,
      data?: any,
      config?: AxiosRequestConfig
    ): Promise<T>;
  }
}

And notify TypeScript of this change in tsconfig.json:

// tsconfig.json
{
  // ...
  "typeRoots": ["node_modules/@types", "src/types"]
}

We can find the definition of typeRoots on their official documentation, which is a list of the directories containing all type declarations. In this example, we specify two directories, so TypeScript will look for the definitions of unknown types under these two directories.

The first directory, node_modules/@types comes from Definitely Typed, which contains common types like @types/node.

The second one is our custom type directory. So the next time TypeScript comes across Axios API, it will first find declarations here. Now, TypeScript knows res is of type T.

Design Patterns in One Sentence

mrcaidev — Tue, 08 Nov 2022 07:11:39 +0000

Factory Method

The abstract class focuses on business logic, while its subclasses determine the implementation details.

Abstract Factory

2D factory method. Create different products of the same variant.

Builder

Create product part by part, usually in chain.

Prototype

Provide a method to clone itself.

Singleton

Always return the same instance.

Adapter

Encapsulate an instance of old class, and provide new interface to the outside.

Bridge

Different abstraction layer and different implementation layer can be mixed at will.

Composition

A tree where all nodes provide the same interface, the leaves do the job, and non-leaves aggregate the results of their own leaves.

Decorator

Encapsulate an instance of a class, and provide the same interface to the outside.

Facade

Encapsulate complicated logic, and provide simple interface to the outside.

Flyweight

Create a new class for those memory-consuming, shared attributes, for which a factory is created for caching.

Proxy

Encapsulate an instance of a class, provide the same interface to the outside, and manage the lifecycle of the internal instance.

Chain of Responsibility

Process an object through a chain, where each link can determine whether to continue or terminate processing.

Command

Abstract a callback function as a class, and makes it fetch arguments - explicitly on initialization or on its own - every time the command is executed.

Iterator

Encapsulate an instance of a class, and provide the iteration method of this instance.

Mediator

Elements in a system send their interaction information to the mediator, and listen to its schedule, rather than directly interacting with each other.

Memento

Create snapshots of another class.

Observer

The object notifies all of its observers of its latest update.

State

Divide a class with volatile states into state and context, where the state executes all state-related operations and can modify the state on its own.

Strategy

Abstract different strategies into classes, and let the business logic pick which one to use.

Template Method

The template parent class implements a set of standard methods, while its subclasses overload methods according to their needs.

Visitor

The visited class redirects request to the visitor, who extends the interface of the visited class.

Design Patterns in Functional Programming

mrcaidev — Sat, 05 Nov 2022 05:50:06 +0000

The emergence of design patterns is primarily due to the fact that OOP organizes code into classes with data-centric methods.

As a result, we often find ourselves having to
abstract "an action" to "someone is taking that action". That is, we have to explicitly clarify the action's executor, and expand a verb into subject-verb structure.

FP, on the other hand, saves the trouble by treating action as-is, and passing everything else as arguments.

Design patterns in functional programming paradigm has two distinct features:

Decoupling of data and methods. The methods are no longer centered on the internal data of the class, but rather receives data via arguments. Pure functions are preferred.
First-class functions. Functions can be used as variables, arguments or return values, making FP comparable to OOP by closure, currying, etc.

✂️ Decoupling of Data and Methods

This renders many design patterns nearly pointless.

For example, Singleton. We can simply expost the instance as a constant and export the value using the language's built-in export methods. If you are familiar with Axios, you've probably seen this pattern a million times:

export const axiosInstance = axios.create({
  // Configuration of the instance.
});

This trick also applies to patterns like Flyweight, Composite, Prototype.

We can also see such scenarios in OOP design patterns where a class contains an instance of another class as a field, e.g. Adapter, Proxy, Decorator, Bridge. In FP actually, this is as simple as one function calling another, which is much more intuitive. Take adapter for example, this is how the code looks like under OOP:

interface LegacyService {
  call: (value: string) => void;
}

interface ModernService {
  call: (value: number) => void;
}

class LegacyLibrary implements LegacyService {
  call(value: string) {
    console.log(value);
  }
}

class LegacyToModernAdapter implements ModernService {
  protected adaptee: LegacyService;

  constructor(adaptee: LegacyService) {
    this.adaptee = adaptee;
  }

  call(value: number) {
    this.adaptee.call(String(value));
  }
}

const adapter = new LegacyToModernAdapter(new LegacyLibrary());
adapter.call(1); // 1

While FP makes the code above ridiculously troublesome:

function legacyCall(value) {
  console.log(value);
}

function adaptLegacyToModernCall(value) {
  legacyCall(String(value));
}

adaptLegacyToModernCall(1); // 1

... and that's why we can see many are arguing that we don't even need design patterns in FP.

🏷️ Functions as Arguments

Factory method makes this obvious.

The purpose of factory method is to decouple macroscopic business logic and specific implementation details. Take express as example, the business logic is "shipping, transportation and receipt", while the transportation part can be implemented in various details, e.g. by land, by sea or by air.

In OOP, we do this by placing business logic in an abstract class, and override its dependency with different subclasses.

interface Transportation {
  carry: () => void;
}

abstract class Logistics {
  // Does not care about implementation details.
  abstract createTransportation(): Transportation;

  // Only cares about business logic.
  deliver() {
    const transportation = this.createTransportation();
    console.log("Shipping");
    transportation.carry(); // Whatever can carry.
    console.log("Receipt");
  }
}

class Ship implements Transportation {
  carry() {
    console.log("By ship");
  }
}

class SeaLogistics extends Logistics {
  // Override abstract "transportation" with specific "ship".
  createTransportation() {
    return new Ship();
  }
}

class Plane implements Transportation {
  carry() {
    console.log("By plane");
  }
}

class AirLogistics extends Logistics {
  // Override abstract "transportation" with specific "plane".
  createTransportation() {
    return new Plane();
  }
}

const seaLogistics = new SeaLogistics();
seaLogistics.deliver(); // Shipping, By ship, Receipt
const airLogistics = new AirLogistics();
airLogistics.deliver(); // Shipping, By plane, Receipt

Reasonable, but unnecessary. For the sake of OOP, we have to come up with a ship for shipping, a plane for airlifting. To hide this difference for the abstract class, we then abstract a Transportation interface to unify ship and plane.

But once we've finished writing all of these codes, let's take a look back and ask ourselves: what do we really want to do? We simply want to enable dynamic selection of various actions between shipping and receipt!

This is as easy as pie in FP, since we can pass the action itself as an argument to business logic.

function carryByShip() {
  console.log("By ship");
}

function carryByPlane() {
  console.log("By plane");
}

function deliver(carry: () => void) {
  console.log("Shipping");
  carry();
  console.log("Receipt");
}

deliver(carryByShip); // Shipping, By ship, Receipt
deliver(carryByPlane); // Shipping, By plane, Receipt

As stated in the beginning of this post, there is no need to imagine an executor of the action in FP. We simply need to tell deliver by arguments how to transport. That's all!

It's worth noting that when OOP requires two classes to implement the same interface, FP will correspondingly require two functions to have the same signature. In this example, Ship and Plane both implement Transportation interface, so correspondingly carryByShip and carryByPlane should both have () => void signature.

🖇️ Function Composition

Builder pattern is a perfect example for this.

type House = string[];
type Builder = (house: House) => House;

const buildLivingRoom: Builder = (house) => {
  const nextHouse = [...house];
  nextHouse.push("living room");
  return nextHouse;
};

const buildBedroom: Builder = (house) => {
  const nextHouse = [...house];
  nextHouse.push("bedroom");
  return nextHouse;
};

const buildBathRoom: Builder = (house) => {
  const nextHouse = [...house];
  nextHouse.push("bathroom");
  return nextHouse;
};

function compose(...builders: Builder[]) {
  return (target: House) =>
    builders.reduce((result, build) => build(result), target);
}

const build = compose(
  buildLivingRoom,
  buildBedroom,
  buildBedroom,
  buildBathRoom
);
const house = build([]);
console.log(house);

Functions are often deeply nested, since FP cannot chain methods by returning this at the end of each method. As a workaround, we can apply effects layer by layer with reduce, flattening the functions to call.

This involves two concepts: Currying and pure functions, which are both important in FP.

HTTP Caching - Fresh, Stale and Revalidation

mrcaidev — Wed, 02 Nov 2022 02:43:53 +0000

HTTP caching is critical to the performance of a website. Resources can be reused for a set period of time, and then revalidated to keep their freshness.

It can save the client the time waiting for responses and relieve the server of the burden of handling requests.

🍎 Fresh and Stale

Let's do this together:

Open your DevTools Network tab.
Refresh the page, and inspect the headers of any incoming response.
You may well find such a field: Cache-Control: max-age=AGE.

This is where the magic happens! The value of age indicates how long the resource will remain fresh, i.e. reusable. During this period, the client no longer needs to query the server for this resource, but can instead reuse the cached version of it.

Prior to HTTP/1.1, Expires header was adopted, but it was later deprecated due to its drawbacks. See MDN: Expires or max-age.

The benefit is self-evident: No request issued, no response awaited, and a foreseeable boost in performance.

That's awesome, but it also comes at a price, since the server has completely lost control over the client, on that specific URL. This places a high demand on the setting of age. A long age makes it easier for the client to see an outdated version of resource, whereas a short age makes caching nearly useless.

When the magic fades, the resource becomes stale. Oops! That's definitely not what we want, as we cannot enjoy the blazing fast local cache any more.

One intuitive approach would be to fetch that resource again, right? And the magic can be replayed once again. This is adequate, but not optimal.

Revalidation is a better way to replay that magic.

🛏️ Revalidation

We'll still have to try to fetch that resource eventually. But this time, we will include some credentials with the request that will inform the server about the current state of our local resource.

After the server validates the credentials, it will inform us whether or not our resource has become obsolete. If not, the stale resource will be refreshed, and the client will be able to reuse it for another period of time. Now the magic is back, but the server no longer needs to send that resource!

Next, we'll talk about the credentials.

⏱️ Revalidation Based on Time

One of the credentials is the last modified time of the resource. The basic idea is straightforward: If a resource has not been touched since it was requested, then it's safe for the cache to be reused.

When the response first arrives, the server notifies the client of the last modified time via Last-Modified header, e.g. Last-Modified: Tue, 01 Nov 2022 22:00:00 GMT.
When the client tries to revalidate the resource, include this particular time in the If-Modified-Since header.
The server checks whether the resource has been modified since this time, e.g. by calling fs.stat() in Node.js.
If the resource has not been modified, the server returns "304 Not Modified" or "200 OK" and the new resource otherwise.

Isn't it easy? However, it has numerous drawbacks:

The datetime format is difficult to parse.
The datetime can be accurate only to the second.
The file system will consider it a modification, if the server touches the resource, but without modifying it.

And another approach is ready to come out, once those drawbacks are identified.

🏷️ Revalidation Based on Content

The server generates a unique tag based on the current content of the resource, such as a hash value or version number. After that, we can reuse the resource if the tag remains the same.

When the response first arrives, the server notifies the client of the tag via ETag header, e.g. ETag: W/"ccd3a8bea48cdd6151d60b9fcd70fea1".
When the client tries to revalidate the resource, include this particular tag in the If-None-Match header.
The server checks whether the tag is identical to the one owned by the server.
if the tags are identical, the server returns "304 Not Modified", or "200 OK" and the new resource otherwise.

🤝 Combination of Last-Modified and ETag

Whenever these two credentials appears together, ETag is preferred.

Ideally, ETag alone would suffice for revalidation. However, Last-Modified is also valuable in CMS and web crawlers, so we'll often see these two credentials go hand in hand.

🤔 Related Cache-Control Directives

🚫 no-cache

Force the client to revalidate the resource every time.

The resource will still get stored, but it turns stale immediately upon arrival. If you are wondering how is it different from max-age=0: 👇

It is often stated that the combination of max-age=0 and must-revalidate has the same meaning as no-cache.

...

But now that HTTP/1.1-conformant servers are widely deployed, there's no reason to ever use that max-age=0 and must-revalidate combination — you should instead just use no-cache.

—— MDN: Force Revalidation

🚫 no-store

Not storing the resource at all.

In most cases in practice, no-cache or private is often a better solution to no-store, while achieving the same goal.

You may think adding no-store would be the right way to opt-out of caching.

However, it's not recommended to grant no-store liberally, because you lose many advantages that HTTP and browsers have, including the browser's back/forward cache.

Therefore, to get the advantages of the full feature set of the web platform, prefer the use of no-cache in combination with private.

—— MDN: What's lost by no-store

👀 private/public

Private caches: Typically a browser cache. User-specific. Can be used to store private user information.
Shared caches: Shared among users.
- Proxy caches: A proxy can cache responses, but usually only plays the role of a tunnel under HTTPS.
- Managed caches: Like reversed proxies and CDN. Managed by developers.

📚 References

MDN: HTTP caching

Everything You Need To Know About 100 Continue

mrcaidev — Tue, 01 Nov 2022 11:39:44 +0000

The HTTP status code "100 Continue" indicates that the server feels good about the initial part of a request, and the client can go on with this request.

📌 Purpose

It’s intended to optimize the case where an HTTP client application has an entity body to send to a server but wants to check that the server will accept the entity before it sends it.

—— HTTP: The Definitive Guide

From the description above, we can see that "100 Continue" is mainly used as an optimization method.

In most cases where "100 Continue" is applied, the client is about to send a LARGE entity. Let's imagine that if the client decides to directly send this entity, without asking the server's opinion, an awkward situation is very likely to happen: the server refuses to accept that entity, because it's too large for it to process.

In some other cases, a user may be unauthorized to upload an image, video, etc, or simply has used PUT instead of POST due to carelessness.

These scenarios can all lead to a huge waste of time and network resources.

As such, both the server and the client need a way to reach consensus before sending a large entity. And that's where "100 Continue" comes in handy!

🪄 How It Works

The client can hold the entity for a while, and send the headers first, carrying information about the entity, e.g. Content-Length. If it receives "100 Continue" afterwards, that means the server is willing to accept the entity. Great, we can send the entity now!

... or the server can reject the request. But now the entity won't be sent either, saving a pointless delivery. That's much better!

Now that we've already had a rough idea of how "100 Continue" works, let's take a closer look, from the server, the client and the proxy's perspective respectively.

🔍 Client Behaviors

If the client is expecting to receive a "100 Continue" response, it must set Expect: 100-continue in its request headers.
If there is no entity to send, the client must not set Expect: 100-continue. Otherwise, it will confuse the server into thinking that it's going to receive an entity.
For historical reasons, the client should not wait forever for "100 Continue".
If the server times out, the client may directly send the entity.
After sending the entity, the client should ignore every "100 Continue".
A common misbelief is that: "417 Expectation Failed" means that the server refuses to receive the entity. This is not the case. "417 Expectation Failed" merely indicates that the response chain does not support Expect header, e.g. an HTTP/1.0 server or proxy. In such cases, the client should simply repeat that request, but this time without Expect: 100-continue.

🔍 Server Behaviors

The server must ignore Expect: 100-continue in an HTTP/1.0 request.
If the request headers do not contain Expect: 100-continue, the server must not send "100 Continue".
If the entity is received before the server can check and respond to the headers, it may omit "100 Continue", and directly send final resopnse.
Upon receiving a request with Expect: 100-continue:
- If the entity is acceptable, the server must respond with "100 Continue" to encourge the client to send the entity.
- Otherwise, the server must respond with an appropriate status code as the final response, e.g. "401 Unauthorized" if an unknown user attempts to upload files, or "413 Payload Too Large" if the entity is too large to process.

🔍 Proxy Behaviors

When receiving a request with Expect: 100-continue from a client:
- If the proxy knows the server only supports HTTP/1.0 or below, it must return either "100 Continue" or "417 Expectation Failed".
- Otherwise, the proxy must forward this request along with Expect: 100-continue.
When receiving a "100 Continue" response from a server:
- If Expect: 100-continue was added by the proxy itself on behalf of the client, it must not forward this response to the client. It should decide what to do with the response on its own.
- Otherwise, it must forward this response to the client, even if the client only supports HTTP/1.0 or below.

🛠️ Compatibility Issues

All 1xx status codes share some compatibility issues, since they were not introduced until HTTP/1.1. As such, the server, the client and the proxy should adhere to a set of principles:

Server: Must not send 1xx responses to HTTP/1.0 clients.
Client: Must be able to parse 1xx responses before the final response, even if they are unexpected.
Proxy: Must forward 1xx responses, except those requested by the proxy itself.

📚 References

RFC 9110 - 15.2.1. 100 Continue
HTTP: The Definitive Guide - 100-199: Informational Status Codes

My portfolio got 4x100 in Lighthouse

mrcaidev — Sun, 31 Jul 2022 09:44:00 +0000

💕 Appreciation

A few weeks ago, I built the 1st version of my portfolio with Chakra UI. To my surprise, I got many likes - more than I expected - after sharing it in this post:

Share your Portfolio

Ahmad Swalih ・ Jul 7 '22

#portfolio #webdev #javascript #beginners

So really really thankful for that! It gave me a lot of confidence in many senses: as a beginner to frontend, a newcomer to DEV.TO, and a non-native English speaker.

🔧 Decided to refactor

After that, I've seen some awesome portfolios on this platform, and they are really inspiring! So I decided to refactor it this week, this time with Next.js, Tailwind and Framer Motion.

After 2-3 days of work, I managed to pass all 4 tests with full score in the lighthouse, and learned a lot along the way. For those who would like to take a look: mrcai.space

🔬 What I've learned

Here's some of what I've learned:

Use lazy loading wisely

Lazy loading is an effective way to reduce bundle size, but too much lazy loading will only do more harm than good, e.g. longer LCP(Largest Content Painting), which is a significant indicator in Lighthouse performance calculator.

Avoid using it on the first page - I mean the first section of your website that visitors will see, like a cover. You will see a great improvement in your LCP.

Next.js provides many lazy loading features out of the box: The <Image /> component can lazy-load images by default, and dynamic() can lazy-load components. At first, I just apply them to every images and components, but this made LCP reaching 1.4s. I dealt with it in 3 ways:

Remove animation of image on the cover. (I doubt if this is reasonable but it does help)
Set priority to true on <Image /> on the cover image, so that Next.js knows this image should be preloaded.
Remove the lazy loading of component <Cover />, which is the cover section.

And LCP is thus reduced to 0.4s! 🎉

A11y matters

A11y is a much broader topic than I thought it was. I started to read MDN again, particularly the ARIA part, and tried to apply the best practices on my website, e.g. logical tab order, focus trap on modals, aria-label on icon buttons, ...

And I realized I had always been ignoring this important part of webdev. Next I will try to learn from famous websites like Facebook, and see how they deal with a11y.

👀 More to say

This portfolio still has many drawbacks, e.g. a11y and SEO. But I guess I may as well put this project away for now, and devote more time and energy to building new meaningful projects.

And when I become more experienced, and have more impressive projects, I will come back and polish it again.

Keep learning! 💪

📸 Some screenshots

mrcai.space