frontend - freeCodeCamp.org

The Front-End Monitoring Handbook: Track Performance, Errors, and User Behavior

Gordan Tan — Tue, 03 Jun 2025 01:55:18 +0000

A complete frontend monitoring system is essential for tracking application performance, errors, and user behavior. It consists of three main components: data collection and reporting, data processing and storage, and data visualization.

This article focuses specifically on the first component – data collection and reporting – and shows you how to build a monitoring SDK from scratch. By the end of this article, you'll understand how to gather critical metrics about your application's performance, capture errors, track user behavior, and implement efficient reporting mechanisms.

Below is an outline of the topics we'll cover:

                       ┌────────────────────┐
                       │  Data Collection   │
                       └──────────┬─────────┘
                                  │
         ┌─────────────────┬──────┴──────────────┐
         │                 │                     │
┌────────┴────────┐ ┌──────┴──────┐     ┌────────┴────────┐
│ Error Monitoring │ │ Performance  │     │ Behavior       │
│                  │ │ Monitoring   │     │ Monitoring     │
└────────┬─────────┘ └──────┬──────┘     └────────┬────────┘
         │                  │                     │
┌────────┴────────┐ ┌──────┴──────────┐  ┌────────┴────────┐
│                 │ │                 │  │                 │
│ Resource Loading│ │ Resource Loading│  │     UV, PV      │
│     Errors      │ │      Time       │  │                 │
│                 │ │                 │  │  Page Access    │
│   JS Errors     │ │  API Request    │  │     Depth       │
│                 │ │     Time        │  │                 │
│ Promise Errors  │ │                 │  │   Page Stay     │
│                 │ │   DNS, TCP,     │  │    Duration     │
│ Custom Errors   │ │ First-byte Time │  │                 │
│                 │ │                 │  │  Custom Event   │
│                 │ │   FPS Rate      │  │    Tracking     │
│                 │ │                 │  │                 │
│                 │ │ Cache Hit Rate  │  │   User Clicks   │
│                 │ │                 │  │                 │
│                 │ │  First Screen   │  │ Page Navigation │
│                 │ │  Render Time    │  │                 │
│                 │ │                 │  └─────────────────┘
│                 │ │  FP, FCP, LCP,  │
│                 │ │   FID, LCS,     │
│                 │ │ DOMContentLoaded│
│                 │ │    onload       │
└─────────────────┘ └─────────────────┘

Once data is collected, it needs to be reported to your backend systems for processing and analysis:

                  ┌─────────────────┐
                  │ Data Reporting  │
                  └────────┬────────┘
                           │
          ┌────────────────┴────────────────┐
          │                                 │
┌─────────────────────┐           ┌─────────────────────┐
│  Reporting Methods  │           │  Reporting Timing   │
└──────────┬──────────┘           └──────────┬──────────┘
           │                                 │
     ┌─────┼─────┐               ┌───────────┼───────────┐
     │     │     │               │           │           │
┌────┴───┐ │ ┌───┴────┐ ┌────────┴────────┐ │ ┌─────────┴─────────┐
│  xhr   │ │ │ image  │ │ requestIdle     │ │ │ Upload when cache │
└────────┘ │ └────────┘ │ Callback/       │ │ │ limit is reached  │
           │            │ setTimeout      │ │ └───────────────────┘
     ┌─────┴─────┐      └─────────────────┘ │
     │ sendBeacon│                          │
     └───────────┘                ┌─────────┴──────────┐
                                  │    beforeunload    │
                                  └────────────────────┘

Prerequisites

Before diving into this tutorial, you should have:

Basic knowledge of JavaScript and web development
Familiarity with browser APIs and event handling
Understanding of asynchronous programming concepts
Some experience with performance optimization concepts

Since theoretical knowledge alone can be difficult to grasp, I've created a simple monitoring SDK that implements these technical concepts. You can use it to create simple demos and gain a better understanding. Reading this article while experimenting with the SDK will provide the best learning experience.

Collect Performance Data
Error Data Collection
Behavior Data Collection
Data Reporting
- Reporting Methods
- Reporting Timing
Summary
References

Collect Performance Data

Monitoring performance is crucial for providing users with a smooth, responsive experience. Slow websites lead to higher bounce rates and reduced conversions. By collecting performance metrics, you can identify bottlenecks, optimize critical rendering paths, and improve overall user satisfaction.

The Chrome developer team has proposed a series of metrics to monitor page performance, each measuring a different aspect of the user experience:

FP (First Paint) – Time from when the page starts loading until the first pixel is painted on the screen (essentially the white screen time)
FCP (First Contentful Paint) – Time from page load start until any part of page content is rendered
LCP (Largest Contentful Paint) – Time from page load start until the largest text block or image element completes rendering
CLS (Cumulative Layout Shift) – Cumulative score of all unexpected layout shifts occurring between page load start and when the page's lifecycle state becomes hidden

We can obtain these four performance metrics through PerformanceObserver (they can also be retrieved via performance.getEntriesByName(), but this method doesn't provide real-time notifications when events occur). PerformanceObserver is a performance monitoring interface used to observe performance measurement events.

Let's examine each of these metrics in detail and see how to implement them in our SDK.

FP (First Paint)

First Paint (FP) marks the point when the browser renders anything visually different from what was on the screen before navigation. This could be a background color change or any visual element that indicates to the user that the page is loading.

Implementation code:

const entryHandler = (list) => {        
    for (const entry of list.getEntries()) {
        if (entry.name === 'first-paint') {
            observer.disconnect()
        }
        console.log(entry)
    }
}

const observer = new PerformanceObserver(entryHandler)
// The buffered property indicates whether to observe cached data, 
// allowing observation even if the monitoring code is added after the event occurs
observer.observe({ type: 'paint', buffered: true })

This code creates a new PerformanceObserver that watches for 'paint' type events. When the first-paint event occurs, it logs the entry information and disconnects the observer since we only need to capture this event once per page load. The observer's observe() method is configured with buffered: true to ensure we can catch paint events that occurred before our code runs.

The FP measurement output:

{
    duration: 0,
    entryType: "paint",
    name: "first-paint",
    startTime: 359, // FP time
}

The startTime value represents the paint timing we need. This value (359ms in this example) tells us how long it took from the start of navigation until the first visual change appeared on screen. You can use this metric to optimize your critical rendering path and reduce the time users spend looking at a blank screen.

FCP (First Contentful Paint)

FCP (First Contentful Paint) refers to the time from page load start until any part of page content is rendered. The "content" in this metric refers to text, images (including background images), elements, and non-white elements.

To provide a good user experience, the FCP score should be kept under 1.8 seconds.

The measurement code:

const entryHandler = (list) => {        
    for (const entry of list.getEntries()) {
        if (entry.name === 'first-contentful-paint') {
            observer.disconnect()
        }

        console.log(entry)
    }
}

const observer = new PerformanceObserver(entryHandler)
observer.observe({ type: 'paint', buffered: true })

We can get the value of FCP via the above code:

{
    duration: 0,
    entryType: "paint",
    name: "first-contentful-paint",
    startTime: 459, // fcp 时间
}

The startTime value is the painting time we need.

LCP (Largest Contentful Paint)

LCP (Largest Contentful Paint) refers to the time from page load start until the largest text block or image element completes rendering. The LCP metric reports the relative render time of the largest visible image or text block in the viewport, measured from when the page first begins loading.

A good LCP score should be kept under 2.5 seconds.

The measurement code:

const entryHandler = (list) => {
    if (observer) {
        observer.disconnect()
    }

    for (const entry of list.getEntries()) {
        console.log(entry)
    }
}

const observer = new PerformanceObserver(entryHandler)
observer.observe({ type: 'largest-contentful-paint', buffered: true })

We can get the value of LCP via the above code:

{
    duration: 0,
    element: p,
    entryType: "largest-contentful-paint",
    id: "",
    loadTime: 0,
    name: "",
    renderTime: 1021.299,
    size: 37932,
    startTime: 1021.299,
    url: "",
}

The startTime value is the painting time we need. And element refers to the element being painted during LCP.

The difference between FCP and LCP is: FCP event occurs when any content is painted, while LCP event occurs when the largest content finishes rendering.

LCP considers these elements:

elements
elements inside
elements (using poster images)
Elements with background images loaded via the url() function (not using CSS gradients)
Block-level elements containing text nodes or other inline-level text elements

CLS (Cumulative Layout Shift)

CLS (Cumulative Layout Shift) refers to the cumulative score of all unexpected layout shifts occurring between page load start and when the page's lifecycle state becomes hidden.

An "unexpected layout shift" occurs when elements on a page move around without user interaction. Common examples include:

A banner or ad suddenly appearing at the top of the page, pushing content down
A font loading and changing the size of text
An image loading without predefined dimensions, expanding and pushing other content out of the way
A button appearing below where a user is about to click, causing them to click the wrong element

These shifts are frustrating for users and lead to accidental clicks, lost reading position, and overall poor user experience. CLS helps quantify this problem so you can identify and fix problematic elements.

The layout shift score is calculated as follows:

layout shift score = impact score × distance score

The impact score measures how unstable elements affect the visible area between two frames. The distance score is calculated by taking the greatest distance any unstable element has moved (either horizontally or vertically) and dividing it by the viewport's largest dimension (width or height, whichever is greater).

CLS is the sum of all layout shift scores.

A layout shift occurs when a DOM element changes position between two rendered frames, as shown below:

In the above diagram, the rectangle moves from the top-left to the right side, counting as one layout shift. In CLS terminology, there's a concept called "session window": one or more individual layout shifts occurring in rapid succession, with less than 1 second between each shift and a maximum window duration of 5 seconds.

For example, in the second session window shown above, there are four layout shifts. Each shift must occur less than 1 second after the previous one, and the time between the first and last shifts must not exceed 5 seconds to qualify as a session window. If these conditions aren't met, it's considered a new session window. This specification comes from extensive experimentation and research by the Chrome team, as detailed in Evolving the CLS metric.

CLS has three calculation methods:

Cumulative
Average of all session windows
Maximum of all session windows

Cumulative

This method adds up all layout shift scores from page load start. However, this approach disadvantages long-lived pages - the longer a page is open, the higher the CLS score becomes.

Average of All Session Windows

This method calculates based on session windows rather than individual layout shifts, taking the average of all session window scores. However, this approach has limitations.

As shown above, if the first session window has a high CLS score and the second has a low score, averaging them masks the actual page behavior. The average doesn't reflect that the page had more shifts early on and fewer later.

Maximum of All Session Windows

This is currently the optimal calculation method, using the highest session window score to reflect the worst-case scenario for layout shifts. For more details, see Evolving the CLS metric.

Below is the implementation code for the third calculation method:

let sessionValue = 0
let sessionEntries = []
const cls = {
    subType: 'layout-shift',
    name: 'layout-shift',
    type: 'performance',
    pageURL: getPageURL(),
    value: 0,
}

const entryHandler = (list) => {
    for (const entry of list.getEntries()) {
        // Only count layout shifts without recent user input.
        if (!entry.hadRecentInput) {
            const firstSessionEntry = sessionEntries[0]
            const lastSessionEntry = sessionEntries[sessionEntries.length - 1]

            // If the entry occurred less than 1 second after the previous entry and
            // less than 5 seconds after the first entry in the session, include the
            // entry in the current session. Otherwise, start a new session.
            if (
                sessionValue
                && entry.startTime - lastSessionEntry.startTime < 1000
                && entry.startTime - firstSessionEntry.startTime < 5000
            ) {
                sessionValue += entry.value
                sessionEntries.push(formatCLSEntry(entry))
            } else {
                sessionValue = entry.value
                sessionEntries = [formatCLSEntry(entry)]
            }

            // If the current session value is larger than the current CLS value,
            // update CLS and the entries contributing to it.
            if (sessionValue > cls.value) {
                cls.value = sessionValue
                cls.entries = sessionEntries
                cls.startTime = performance.now()
                lazyReportCache(deepCopy(cls))
            }
        }
    }
}

const observer = new PerformanceObserver(entryHandler)
observer.observe({ type: 'layout-shift', buffered: true })

A single layout shift measurement contains the following data:

{
  duration: 0,
  entryType: "layout-shift",
  hadRecentInput: false,
  lastInputTime: 0,
  name: "",
  sources: (2) [LayoutShiftAttribution, LayoutShiftAttribution],
  startTime: 1176.199999999255,
  value: 0.000005752046026677329,
}

The value field represents the layout shift score.

DOMContentLoaded and Load Events

The DOMContentLoaded event is triggered when the HTML is fully loaded and parsed, without waiting for CSS, images, and iframes to load.

The load event is triggered when the entire page and all dependent resources such as stylesheets and images have finished loading.

Although these performance metrics are older, they still provide valuable insights into page behavior. Monitoring them remains necessary.

import { lazyReportCache } from '../utils/report'

['load', 'DOMContentLoaded'].forEach(type => onEvent(type))

function onEvent(type) {
    function callback() {
        lazyReportCache({
            type: 'performance',
            subType: type.toLocaleLowerCase(),
            startTime: performance.now(),
        })

        window.removeEventListener(type, callback, true)
    }

    window.addEventListener(type, callback, true)
}

First Screen Rendering Time

In most cases, the first screen rendering time can be obtained through the load event. However, there are exceptions, such as asynchronously loaded images and DOM elements.

In such cases, we cannot obtain the first screen rendering time through the load event. Instead, we need to use MutationObserver to get the first screen rendering time. MutationObserver triggers events when the properties of the DOM elements it's monitoring change.

The process of calculating first screen rendering time:

Use MutationObserver to monitor the document object, triggering events whenever DOM element properties change.
Check if the DOM element is in the first screen. If it is, call performance.now() in the requestAnimationFrame() callback function to get the current time as its rendering time.
Compare the rendering time of the last DOM element with the loading time of all images in the first screen, and use the maximum value as the first screen rendering time.

Monitoring DOM

const next = window.requestAnimationFrame ? requestAnimationFrame : setTimeout
const ignoreDOMList = ['STYLE', 'SCRIPT', 'LINK']

observer = new MutationObserver(mutationList => {
    const entry = {
        children: [],
    }

    for (const mutation of mutationList) {
        if (mutation.addedNodes.length && isInScreen(mutation.target)) {
             // ...
        }
    }

    if (entry.children.length) {
        entries.push(entry)
        next(() => {
            entry.startTime = performance.now()
        })
    }
})

observer.observe(document, {
    childList: true,
    subtree: true,
})

The code above monitors DOM changes while filtering out style, script, and link tags.

Checking if Element is in First Screen

A page may have a lot of content, but users can only see one screen at a time. Therefore, when calculating first screen rendering time, we need to limit the scope to content visible in the current screen.

const viewportWidth = window.innerWidth
const viewportHeight = window.innerHeight

// Check if DOM element is in screen
function isInScreen(dom) {
    const rectInfo = dom.getBoundingClientRect()
    if (
        rectInfo.left >= 0 
        && rectInfo.left < viewportWidth
        && rectInfo.top >= 0
        && rectInfo.top < viewportHeight
    ) {
        return true
    }
}

Using `requestAnimationFrame()` to Get DOM Rendering Time

When DOM changes trigger the MutationObserver event, it only means the DOM content can be read, not that it has been painted to the screen.

As shown in the image above, when the MutationObserver event is triggered, we can read that document.body already has content, but the left side of the screen hasn't painted anything yet. Therefore, we need to call requestAnimationFrame() to get the current time as the DOM rendering time after the browser has successfully painted.

Comparing with All Image Loading Times in First Screen

function getRenderTime() {
    let startTime = 0
    entries.forEach(entry => {
        if (entry.startTime > startTime) {
            startTime = entry.startTime
        }
    })

    // Need to compare with all image loading times in current page, take the maximum
    // Image request time must be less than startTime, response end time must be greater than startTime
    performance.getEntriesByType('resource').forEach(item => {
        if (
            item.initiatorType === 'img'
            && item.fetchStart < startTime 
            && item.responseEnd > startTime
        ) {
            startTime = item.responseEnd
        }
    })

    return startTime
}

Optimization

The current code still needs optimization, with two main points to consider:

When should we report the rendering time?
How to handle asynchronously added DOM elements?

For the first point, we must report the rendering time after DOM changes stop, which typically happens after the load event triggers. Therefore, we can report at this point.

For the second point, we can report after the LCP event triggers. Whether DOM elements are loaded synchronously or asynchronously, they need to be painted, so we can monitor the LCP event and only allow reporting after it triggers.

Combining these two approaches, we get the following code:

let isOnLoaded = false
executeAfterLoad(() => {
    isOnLoaded = true
})

let timer
let observer
function checkDOMChange() {
    clearTimeout(timer)
    timer = setTimeout(() => {
        // Calculate first screen rendering time after load and LCP events trigger and DOM tree stops changing
        if (isOnLoaded && isLCPDone()) {
            observer && observer.disconnect()
            lazyReportCache({
                type: 'performance',
                subType: 'first-screen-paint',
                startTime: getRenderTime(),
                pageURL: getPageURL(),
            })

            entries = null
        } else {
            checkDOMChange()
        }
    }, 500)
}

The checkDOMChange() function is called each time the MutationObserver event triggers and needs to be debounced.

API Request Timing

To monitor API request timing, we need to intercept both XMLHttpRequest and fetch requests.

Monitoring XMLHttpRequest

originalProto.open = function newOpen(...args) {
    this.url = args[1]
    this.method = args[0]
    originalOpen.apply(this, args)
}

originalProto.send = function newSend(...args) {
    this.startTime = Date.now()

    const onLoadend = () => {
        this.endTime = Date.now()
        this.duration = this.endTime - this.startTime

        const { status, duration, startTime, endTime, url, method } = this
        const reportData = {
            status,
            duration,
            startTime,
            endTime,
            url,
            method: (method || 'GET').toUpperCase(),
            success: status >= 200 && status < 300,
            subType: 'xhr',
            type: 'performance',
        }

        lazyReportCache(reportData)

        this.removeEventListener('loadend', onLoadend, true)
    }

    this.addEventListener('loadend', onLoadend, true)
    originalSend.apply(this, args)
}

To determine if an XML request is successful, we can check if its status code is between 200 and 299. If it is, the request was successful; otherwise, it failed.

Monitoring fetch

const originalFetch = window.fetch

function overwriteFetch() {
    window.fetch = function newFetch(url, config) {
        const startTime = Date.now()
        const reportData = {
            startTime,
            url,
            method: (config?.method || 'GET').toUpperCase(),
            subType: 'fetch',
            type: 'performance',
        }

        return originalFetch(url, config)
        .then(res => {
            reportData.endTime = Date.now()
            reportData.duration = reportData.endTime - reportData.startTime

            const data = res.clone()
            reportData.status = data.status
            reportData.success = data.ok

            lazyReportCache(reportData)

            return res
        })
        .catch(err => {
            reportData.endTime = Date.now()
            reportData.duration = reportData.endTime - reportData.startTime
            reportData.status = 0
            reportData.success = false

            lazyReportCache(reportData)

            throw err
        })
    }
}

For fetch requests, we can determine success by checking the ok field in the response data. If it's true, the request was successful; otherwise, it failed.

Note: The API request timing we monitor may differ from what's shown in Chrome DevTools. This is because Chrome DevTools shows the time for the entire HTTP request and interface process. But XHR and fetch are asynchronous requests – after the interface request succeeds, the callback function needs to be called. When the event triggers, the callback function is placed in the message queue, and then the browser processes it. There's also a waiting period in between.

Resource Loading Time and Cache Hit Rate

We can monitor resource and navigation events through PerformanceObserver. If the browser doesn't support PerformanceObserver, we can fall back to using performance.getEntriesByType(entryType).

When the resource event triggers, we can get the corresponding resource list. Each resource object contains the following fields:

From these fields, we can extract useful information:

{
    name: entry.name, // Resource name
    subType: entryType,
    type: 'performance',
    sourceType: entry.initiatorType, // Resource type
    duration: entry.duration, // Resource loading duration
    dns: entry.domainLookupEnd - entry.domainLookupStart, // DNS duration
    tcp: entry.connectEnd - entry.connectStart, // TCP connection duration
    redirect: entry.redirectEnd - entry.redirectStart, // Redirect duration
    ttfb: entry.responseStart, // Time to first byte
    protocol: entry.nextHopProtocol, // Request protocol
    responseBodySize: entry.encodedBodySize, // Response body size
    responseHeaderSize: entry.transferSize - entry.encodedBodySize, // Response header size
    resourceSize: entry.decodedBodySize, // Resource size after decompression
    isCache: isCache(entry), // Whether cache was hit
    startTime: performance.now(),
}

Determining if Resource Hit Cache

Among these resource objects, there's a transferSize field that represents the size of the resource being fetched, including response header fields and response data size. If this value is 0, it means the resource was read directly from cache (forced cache). If this value is not 0 but the encodedBodySize field is 0, it means it used negotiated cache (encodedBodySize represents the size of the response data body).

function isCache(entry) {
    // Read directly from cache or 304
    return entry.transferSize === 0 || (entry.transferSize !== 0 && entry.encodedBodySize === 0)
}

If it doesn't meet the above conditions, it means the cache was not hit. Then we can calculate the cache hit rate by dividing all cached data/total data.

Browser Back/Forward Cache (BFC)

BFC is a memory cache that saves the entire page in memory. When users navigate back, they can see the entire page immediately without refreshing. According to the article bfcache, Firefox and Safari have always supported BFC, while Chrome only supports it in high-version mobile browsers. But when I tested it, only Safari supported it – my Firefox version might have been different.

Still, BFC also has drawbacks. When users navigate back and restore the page from BFC, the original page's code won't execute again. For this reason, browsers provide a pageshow event where we can put code that needs to be executed again.

window.addEventListener('pageshow', function(event) {
  // If this property is true, it means the page was restored from BFC
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

For pages restored from BFC, we also need to collect their FP, FCP, LCP, and other timing metrics.

onBFCacheRestore(event => {
    requestAnimationFrame(() => {
        ['first-paint', 'first-contentful-paint'].forEach(type => {
            lazyReportCache({
                startTime: performance.now() - event.timeStamp,
                name: type,
                subType: type,
                type: 'performance',
                pageURL: getPageURL(),
                bfc: true,
            })
        })
    })
})

The code above is easy to understand. After the pageshow event triggers, we subtract the event timestamp from the current time – this time difference is the rendering time of the performance metrics.

Note: For pages restored from BFC, these performance metrics usually have very small values, around 10 ms. This means that we need to add an identifier field bfc: true so we can ignore them when doing performance statistics.

FPS

We can calculate the current page's FPS using requestAnimationFrame().

const next = window.requestAnimationFrame 
    ? requestAnimationFrame : (callback) => { setTimeout(callback, 1000 / 60) }

const frames = []

export default function fps() {
    let frame = 0
    let lastSecond = Date.now()

    function calculateFPS() {
        frame++
        const now = Date.now()
        if (lastSecond + 1000 <= now) {
            // Since now - lastSecond is in milliseconds, frame needs to be multiplied by 1000
            const fps = Math.round((frame * 1000) / (now - lastSecond))
            frames.push(fps)

            frame = 0
            lastSecond = now
        }

        // Avoid reporting too frequently, cache a certain amount before reporting
        if (frames.length >= 60) {
            report(deepCopy({
                frames,
                type: 'performace',
                subType: 'fps',
            }))

            frames.length = 0
        }

        next(calculateFPS)
    }

    calculateFPS()
}

The code logic is as follows:

First record an initial time, then each time requestAnimationFrame() triggers, increment the frame count by 1. After one second passes, we can get the current frame rate by dividing frame count/elapsed time.

When three consecutive FPS values below 20 appear, we can determine that the page has become unresponsive. This technique is based on the observation that smooth animations require at least 20 FPS to appear fluid to users.

export function isBlocking(fpsList, below = 20, last = 3) {
    let count = 0
    for (let i = 0; i < fpsList.length; i++) {
        if (fpsList[i] && fpsList[i] < below) {
            count++
        } else {
            count = 0
        }

        if (count >= last) {
            return true
        }
    }

    return false
}

Vue Router Change Rendering Time

We already know how to calculate first screen rendering time, but how do we calculate the page rendering time caused by route changes in SPA applications? This article uses Vue as an example to explain my approach.

export default function onVueRouter(Vue, router) {
    let isFirst = true
    let startTime
    router.beforeEach((to, from, next) => {
        // First page load already has other rendering time metrics available
        if (isFirst) {
            isFirst = false
            return next()
        }

        // Add a new field to router to indicate whether to calculate rendering time
        // Only needed for route changes
        router.needCalculateRenderTime = true
        startTime = performance.now()

        next()
    })

    let timer
    Vue.mixin({
        mounted() {
            if (!router.needCalculateRenderTime) return

            this.$nextTick(() => {
                // Code that only runs after the entire view has been rendered
                const now = performance.now()
                clearTimeout(timer)

                timer = setTimeout(() => {
                    router.needCalculateRenderTime = false
                    lazyReportCache({
                        type: 'performance',
                        subType: 'vue-router-change-paint',
                        duration: now - startTime,
                        startTime: now,
                        pageURL: getPageURL(),
                    })
                }, 1000)
            })
        },
    })
}

The code logic is as follows:

Monitor route hooks – when route changes occur, the router.beforeEach() hook triggers. In this hook's callback function, record the current time as the rendering start time.
Use Vue.mixin() to inject a function into all components' mounted() hooks. Each function executes a debounced function.
When the last component's mounted() triggers, it means all components under this route have been mounted. We can get the rendering time in the this.$nextTick() callback function.

Also, we need to consider another case. When not changing routes, there may also be component changes, in which case we shouldn't calculate rendering time in these components' mounted() hooks. Therefore, we need to add a needCalculateRenderTime field - set it to true when changing routes to indicate that rendering time can be calculated.

Error Data Collection

Error monitoring is a critical aspect of frontend monitoring that helps identify issues users encounter while interacting with your application. By tracking and analyzing these errors, you can proactively fix bugs before they affect more users, improving both user experience and application reliability.

In this section, we'll explore how to capture various types of errors including resource loading failures, JavaScript runtime errors, unhandled promises, and framework-specific errors.

Resource Loading Errors

Resource loading errors occur when the browser fails to load external resources like images, stylesheets, scripts, and fonts. These errors can significantly impact user experience by causing missing content, broken layouts, or even preventing core functionality from working.

Using addEventListener() to monitor the error event can capture resource loading failure errors.

// Capture resource loading failure errors js css img...
window.addEventListener('error', e => {
    const target = e.target
    if (!target) return

    if (target.src || target.href) {
        const url = target.src || target.href
        lazyReportCache({
            url,
            type: 'error',
            subType: 'resource',
            startTime: e.timeStamp,
            html: target.outerHTML,
            resourceType: target.tagName,
            paths: e.path.map(item => item.tagName).filter(Boolean),
            pageURL: getPageURL(),
        })
    }
}, true)

This code listens for the global error event with the capture option set to true, which allows it to catch errors from resource elements like , , and

// main.js (compiled into bundle.js)
import Vue from 'vue';
import App from './App.vue';

// Client-side rendering happens here - after JS loads and executes
new Vue({
  render: h => h(App)
}).$mount('#app');

// App.vue

Server-side rendering process

Visit a server-rendered website.
The server checks which resource files the current route component needs, then fills the content of these files into the HTML file. If there are AJAX requests, it will execute them for data pre-fetching and fill them into the HTML file, and finally return this HTML page.
When the client receives this HTML page, it can start rendering the page immediately. At the same time, the page also loads resources, and when the necessary resources are fully loaded, it begins to execute new Vue() to instantiate and take over the page.

Example of server-side rendered app (Vue):

// server.js
const express = require('express');
const server = express();
const { createBundleRenderer } = require('vue-server-renderer');

// Create a renderer based on the server bundle
const renderer = createBundleRenderer('./dist/vue-ssr-server-bundle.json', {
  template: require('fs').readFileSync('./index.template.html', 'utf-8'),
  clientManifest: require('./dist/vue-ssr-client-manifest.json')
});

// Handle all routes with the same renderer
server.get('*', (req, res) => {
  const context = { url: req.url };

  // Render our Vue app to a string
  renderer.renderToString(context, (err, html) => {
    if (err) {
      // Handle error
      res.status(500).end('Server Error');
      return;
    }
    // Send the rendered HTML to the client
    res.end(html);
  });
});

server.listen(8080);





  Server-side Rendering Example

// entry-server.js
import { createApp } from './app';

export default context => {
  return new Promise((resolve, reject) => {
    const { app, router } = createApp();

    // Set server-side router's location
    router.push(context.url);

    // Wait until router has resolved possible async components and hooks
    router.onReady(() => {
      const matchedComponents = router.getMatchedComponents();

      // No matched routes, reject with 404
      if (!matchedComponents.length) {
        return reject({ code: 404 });
      }

      // The Promise resolves to the app instance
      resolve(app);
    }, reject);
  });
}

From the two processes above, you can see that the difference lies in the second step. A client-rendered website will directly return the HTML file, while a server-rendered website will render the page completely before returning this HTML file.

What's the benefit of doing this? It's a faster time-to-content.

Suppose your website needs to load four files (a, b, c, d) to render completely. And each file is 1 MB in size.

Calculating this way: a client-rendered website needs to load 4 files and an HTML file to complete the home page rendering, totaling 4MB (ignoring the HTML file size). While a server-rendered website only needs to load a fully rendered HTML file to complete the home page rendering, totaling the size of the already rendered HTML file (which isn't usually too large, generally a few hundred KB; my personal blog website (SSR) loads an HTML file of 400KB). This is why server-side rendering is faster.

References:

4. Use a CDN for Static Resources

A Content Delivery Network (CDN) is a set of web servers distributed across multiple geographic locations. We all know that the further the server is from the user, the higher the latency. CDNs are designed to solve this problem by deploying servers in multiple locations, bringing users closer to servers, thereby shortening request times.

CDN Principles

When a user visits a website without a CDN, the process is as follows:

The browser needs to resolve the domain name into an IP address, so it makes a request to the local DNS.
The local DNS makes successive requests to the root server, top-level domain server, and authoritative server to get the IP address of the website's server.
The local DNS sends the IP address back to the browser, and the browser makes a request to the website server's IP address and receives the resources.

If the user is visiting a website that has deployed a CDN, the process is as follows:

The browser needs to resolve the domain name into an IP address, so it makes a request to the local DNS.
The local DNS makes successive requests to the root server, top-level domain server, and authoritative server to get the IP address of the Global Server Load Balancing (GSLB) system.
The local DNS then makes a request to the GSLB. The main function of the GSLB is to determine the user's location based on the local DNS's IP address, filter out the closest local Server Load Balancing (SLB) system to the user, and return the IP address of that SLB to the local DNS.
The local DNS sends the SLB's IP address back to the browser, and the browser makes a request to the SLB.
The SLB selects the optimal cache server based on the resource and address requested by the browser and sends it back to the browser.
The browser then redirects to the cache server based on the address returned by the SLB.
If the cache server has the resource the browser needs, it sends the resource back to the browser. If not, it requests the resource from the source server, sends it to the browser, and caches it locally.

References:

5. Place CSS in the Head and JavaScript Files at the Bottom

CSS execution blocks rendering and prevents JS execution
JS loading and execution block HTML parsing and prevent CSSOM construction

If these CSS and JS tags are placed in the HEAD tag, and they take a long time to load and parse, then the page will be blank. So you should place JS files at the bottom (not blocking DOM parsing but will block rendering) so that HTML parsing is completed before loading JS files. This presents the page content to the user as early as possible.

So then you might be wondering – why should CSS files still be placed in the head?

Because loading HTML first and then loading CSS will make users see an unstyled, "ugly" page at first glance. To avoid this situation, place CSS files in the head.

You can also place JS files in the head as long as the script tag has the defer attribute, which means asynchronous download and delayed execution.

Here's an example of optimal placement:




  "UTF-8">
  Optimized Resource Loading

  
  "stylesheet" href="styles.css">

  
  


  
    My Website
    
  

  
    Content that users need to see quickly...

Explanation of this approach:

CSS in the : Ensures the page is styled as soon as it renders, preventing the "flash of unstyled content" (FOUC). CSS is render-blocking, but that's actually what we want in this case.
Critical JS with defer: The defer attribute tells the browser to:
- Download the script in parallel while parsing HTML
- Only execute the script after HTML parsing is complete but before the DOMContentLoaded event
- Maintain the order of execution if there are multiple deferred scripts
Non-critical JS before closing : Scripts without special attributes will:
- Block HTML parsing while they download and execute
- By placing them at the bottom, we ensure that all the important content is parsed and displayed first
- This improves perceived performance even if the total load time is the same

You can also use async for scripts that don't depend on DOM or other scripts:

The async attribute will download the script in parallel and execute it as soon as it's available, which may interrupt HTML parsing. Use this only for scripts that don't modify the DOM or depend on other scripts.

Reference:

Adding Interactivity with JavaScript

6. Use Font Icons (iconfont) Instead of Image Icons

A font icon is an icon made into a font. When using it, it's just like a font, and you can set attributes such as font-size, color, and so on, which is very convenient. Font icons are also vector graphics and won't lose clarity. Another advantage is that the generated files are particularly small.

Compress Font Files

Use the fontmin-webpack plugin to compress font files (thanks to Frontend Xiaowei for providing this).

References:

7. Make Good Use of Caching, Avoid Reloading the Same Resources

To prevent users from having to request files every time they visit a website, we can control this behavior by adding Expires or max-age. Expires sets a time, and as long as it's before this time, the browser won't request the file but will directly use the cache. Max-age is a relative time, and it's recommended to use max-age instead of Expires.

But this creates a problem: what happens when the file is updated? How do we notify the browser to request the file again?

This can be done by updating the resource link addresses referenced in the page, making the browser actively abandon the cache and load new resources.

The specific approach is to associate the URL modification of the resource address with the file content, which means that only when the file content changes, the corresponding URL will change. This achieves file-level precise cache control.

So what is related to file content? We naturally think of using digest algorithms to derive digest information for the file. The digest information corresponds one-to-one with the file content, providing a basis for cache control that's precise to the granularity of individual files.

How to implement caching and cache-busting:

1. Server-side cache headers (using Express.js as an example):

// Set cache control headers for static resources
app.use('/static', express.static('public', {
  maxAge: '1y', // Cache for 1 year
  etag: true,   // Use ETag for validation
  lastModified: true // Use Last-Modified for validation
}));

// For HTML files that shouldn't be cached as long
app.get('/*.html', (req, res) => {
  res.set({
    'Cache-Control': 'public, max-age=300', // Cache for 5 minutes
    'Expires': new Date(Date.now() + 300000).toUTCString()
  });
  // Send HTML content
});

2. Using content hashes in filenames (Webpack configuration):

// webpack.config.js
module.exports = {
  output: {
    filename: '[name].[contenthash].js', // Uses content hash in filename
    path: path.resolve(__dirname, 'dist'),
  },
  plugins: [
    // Extract CSS into separate files with content hash
    new MiniCssExtractPlugin({
      filename: '[name].[contenthash].css'
    }),
    // Generate HTML with correct hashed filenames
    new HtmlWebpackPlugin({
      template: 'src/index.html'
    })
  ]
};

This will produce output files like:

main.8e0d62a10c151dad4f8e.js
styles.f4e3a77c616562b26ca1.css

When you change the content of a file, its hash will change, forcing the browser to download the new file instead of using the cached version.

3. Example of generated HTML with cache-busting:




  "UTF-8">
  Cache Busting Example
  
  "stylesheet" href="/static/styles.f4e3a77c616562b26ca1.css">


  "app">

4. Version query parameters (simpler but less effective approach):

"stylesheet" href="styles.css?v=1.2.3">

When updating files, manually change the version number to force a new download.

References:

webpack-caching

8. Compress Files

Compressing files can reduce file download time, providing a better user experience.

Thanks to the development of Webpack and Node, file compression is now very convenient.

In Webpack, you can use the following plugins for compression:

JavaScript: UglifyPlugin
CSS: MiniCssExtractPlugin
HTML: HtmlWebpackPlugin

In fact, we can do even better by using gzip compression. This can be enabled by adding the gzip identifier to the Accept-Encoding header in the HTTP request header. Of course, the server must also support this feature.

Gzip is currently the most popular and effective compression method. For example, the app.js file generated after building a project I developed with Vue has a size of 1.4MB, but after gzip compression, it's only 573KB, reducing the volume by nearly 60%.

Here are the methods for configuring gzip in webpack and node.

Download plugins

npm install compression-webpack-plugin --save-dev
npm install compression

Webpack configuration

const CompressionPlugin = require('compression-webpack-plugin');

module.exports = {
  plugins: [new CompressionPlugin()],
}

Node configuration

const compression = require('compression')
// Use before other middleware
app.use(compression())

9. Image Optimization

1. Lazy Loading Images

In a page, don't initially set the path for images – only load the actual image when it appears in the browser's viewport. This is lazy loading. For websites with many images, loading all images at once can have a significant impact on user experience, so image lazy loading is necessary.

First, set up the images like this, where images won't load when they're not visible in the page:

"https://avatars0.githubusercontent.com/u/22117876?s=460&u=7bd8f32788df6988833da6bd155c3cfbebc68006&v=4">

When the page becomes visible, use JS to load the image:

const img = document.querySelector('img')
img.src = img.dataset.src

This is how the image gets loaded. For the complete code, please refer to the reference materials.

Reference:

Lazy loading images for the web

2. Responsive Images

The advantage of responsive images is that browsers can automatically load appropriate images based on screen size.

Implementation through picture:


    "banner_w1000.jpg" media="(min-width: 801px)">
    "banner_w800.jpg" media="(max-width: 800px)">
    "banner_w800.jpg" alt="">

Implementation through @media:

@media (min-width: 769px) {
    .bg {
        background-image: url(bg1080.jpg);
    }
}
@media (max-width: 768px) {
    .bg {
        background-image: url(bg768.jpg);
    }
}

3. Adjust Image Size

For example, if you have a 1920 * 1080 size image, you show it to users as a thumbnail, and only display the full image when users hover over it. If users never actually hover over the thumbnail, the time spent downloading the image is wasted.

So we can optimize this with two images. Initially, only load the thumbnail, and when users hover over the image, then load the large image. Another approach is to lazy load the large image, manually changing the src of the large image to download it after all elements have loaded.

Example implementation of image size optimization:


class="image-container">
  class="thumbnail" src="thumbnail-small.jpg" alt="Small thumbnail">
  class="full-size" data-src="image-large.jpg" alt="Full-size image">

/* CSS for the container and images */
.image-container {
  position: relative;
  width: 200px;
  height: 150px;
  overflow: hidden;
}

.thumbnail {
  width: 100%;
  height: 100%;
  object-fit: cover;
  display: block;
}

.full-size {
  display: none;
  position: absolute;
  top: 0;
  left: 0;
  z-index: 2;
  max-width: 600px;
  max-height: 400px;
}

/* Show full size on hover */
.image-container:hover .full-size {
  display: block;
}

// JavaScript to lazy load the full-size image
document.addEventListener('DOMContentLoaded', () => {
  const containers = document.querySelectorAll('.image-container');

  containers.forEach(container => {
    const thumbnail = container.querySelector('.thumbnail');
    const fullSize = container.querySelector('.full-size');

    // Load the full-size image when the user hovers over the thumbnail
    container.addEventListener('mouseenter', () => {
      if (!fullSize.src && fullSize.dataset.src) {
        fullSize.src = fullSize.dataset.src;
      }
    });

    // Alternative: Load the full-size image after the page loads completely
    /*
    window.addEventListener('load', () => {
      setTimeout(() => {
        if (!fullSize.src && fullSize.dataset.src) {
          fullSize.src = fullSize.dataset.src;
        }
      }, 1000); // Delay loading by 1 second after window load
    });
    */
  });
});

This implementation:

Shows only the thumbnail initially
Loads the full-size image only when the user hovers over the thumbnail
Provides an alternative approach to load all full-size images with a delay after page load

4. Reduce Image Quality

For example, with JPG format images, there's usually no noticeable difference between 100% quality and 90% quality, especially when used as background images. When cutting background images in Adobe Photoshop, I often cut the image into JPG format and compress it to 60% quality, and basically can't see any difference.

There are two compression methods: one is through the Webpack plugin image-webpack-loader, and the other is through online compression websites.

Here's how to use the Webpack plugin image-webpack-loader:

npm i -D image-webpack-loader

Webpack configuration:

{
  test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
  use:[
    {
    loader: 'url-loader',
    options: {
      limit: 10000, /* Images smaller than 1000 bytes will be automatically converted to base64 code references */
      name: utils.assetsPath('img/[name].[hash:7].[ext]')
      }
    },
    /* Compress images */
    {
      loader: 'image-webpack-loader',
      options: {
        bypassOnDebug: true,
      }
    }
  ]
}

5. Use CSS3 Effects Instead of Images When Possible

Many images can be drawn with CSS effects (gradients, shadows, and so on). In these cases, CSS3 effects are better. This is because code size is usually a fraction or even a tenth of the image size.

Reference:

Asset Management

6. Use WebP to Format Images

WebP's advantage is reflected in its better image data compression algorithm, which brings smaller image volume while maintaining image quality that's indistinguishable to the naked eye. It also has lossless and lossy compression modes, Alpha transparency, and animation features. Its conversion effects on JPEG and PNG are quite excellent, stable, and uniform.

Example of implementing WebP with fallbacks:



  "image.webp" type="image/webp">
  "image.jpg" type="image/jpeg">
  "image.jpg" alt="Description of the image">

Server-side WebP detection and serving:

// Express.js example
app.get('/images/:imageName', (req, res) => {
  const supportsWebP = req.headers.accept && req.headers.accept.includes('image/webp');
  const imagePath = supportsWebP 
    ? `public/images/${req.params.imageName}.webp` 
    : `public/images/${req.params.imageName}.jpg`;

  res.sendFile(path.resolve(__dirname, imagePath));
});

Reference:

WebP

10. Load Code on Demand Through Webpack, Extract Third-Party Libraries, Reduce Redundant Code When Converting ES6 to ES5

The following quote from the official Webpack documentation explains the concept of lazy loading:

"Lazy loading or on-demand loading is a great way to optimize a website or application. This approach actually separates your code at some logical breakpoints, and then immediately references or is about to reference some new code blocks after completing certain operations in some code blocks. This speeds up the initial loading of the application and lightens its overall volume because some code blocks may never be loaded." Source: Lazy Loading

Note: While image lazy loading (discussed in section 9.1) delays the loading of image resources until they're visible in the viewport, code lazy loading splits JavaScript bundles and loads code fragments only when they're needed for specific functionality. They both improve initial load time, but they work at different levels of resource optimization.

Generate File Names Based on File Content, Combined with Import Dynamic Import of Components to Achieve On-Demand Loading

This requirement can be achieved by configuring the filename property of output. One of the value options in the filename property is [contenthash], which creates a unique hash based on file content. When the file content changes, [contenthash] also changes.

output: {
    filename: '[name].[contenthash].js',
    chunkFilename: '[name].[contenthash].js',
    path: path.resolve(__dirname, '../dist'),
},

Example of code lazy loading in a Vue application:

// Instead of importing synchronously like this:
// import UserProfile from './components/UserProfile.vue'

// Use dynamic import for route components:
const UserProfile = () => import('./components/UserProfile.vue')

// Then use it in your routes
const router = new VueRouter({
  routes: [
    { path: '/user/:id', component: UserProfile }
  ]
})

This ensures the UserProfile component is only loaded when a user navigates to that route, not on initial page load.

Extract Third-Party Libraries

Since imported third-party libraries are generally stable and don't change frequently, extracting them separately as long-term caches is a better choice. This requires using the cacheGroups option of Webpack4's splitChunk plugin.

optimization: {
    runtimeChunk: {
        name: 'manifest' // Split webpack's runtime code into a separate chunk.
    },
    splitChunks: {
        cacheGroups: {
            vendor: {
                name: 'chunk-vendors',
                test: /[\\/]node_modules[\\/]/,
                priority: -10,
                chunks: 'initial'
            },
            common: {
                name: 'chunk-common',
                minChunks: 2,
                priority: -20,
                chunks: 'initial',
                reuseExistingChunk: true
            }
        },
    }
},

test: Used to control which modules are matched by this cache group. If passed unchanged, it defaults to select all modules. Types of values that can be passed: RegExp, String, and Function.
priority: Indicates extraction weight, with higher numbers indicating higher priority. Since a module might meet the conditions of multiple cacheGroups, extraction is determined by the highest weight.
reuseExistingChunk: Indicates whether to use existing chunks. If true, it means that if the current chunk contains modules that have already been extracted, new ones won't be generated.
minChunks (default is 1): The minimum number of times this code block should be referenced before splitting (note: to ensure code block reusability, the default strategy doesn't require multiple references to be split).
chunks (default is async): initial, async, and all.
name (name of the packaged chunks): String or function (functions can customize names based on conditions).

Reduce Redundant Code When Converting ES6 to ES5

To achieve the same functionality as the original code after Babel conversion, some helper functions are needed. For example this:

class Person {}

will be converted to this:

"use strict";

function _classCallCheck(instance, Constructor) {
  if (!(instance instanceof Constructor)) {
    throw new TypeError("Cannot call a class as a function");
  }
}

var Person = function Person() {
  _classCallCheck(this, Person);
};

Here, _classCallCheck is a helper function. If classes are declared in many files, then many such helper functions will be generated.

The @babel/runtime package declares all the helper functions needed, and the role of @babel/plugin-transform-runtime is to import all files that need helper functions from the @babel/runtime package:

"use strict";

var _classCallCheck2 = require("@babel/runtime/helpers/classCallCheck");

var _classCallCheck3 = _interopRequireDefault(_classCallCheck2);

function _interopRequireDefault(obj) {
  return obj && obj.__esModule ? obj : { default: obj };
}

var Person = function Person() {
  (0, _classCallCheck3.default)(this, Person);
};

Here, the helper function classCallCheck is no longer compiled, but instead references helpers/classCallCheck from @babel/runtime.

Installation:

npm i -D @babel/plugin-transform-runtime @babel/runtime

Usage:
In the .babelrc file,

"plugins": [
        "@babel/plugin-transform-runtime"
]

References:

11. Reduce Reflows and Repaints

Browser Rendering Process

Parse HTML to generate DOM tree.
Parse CSS to generate CSSOM rules tree.
Combine DOM tree and CSSOM rules tree to generate rendering tree.
Traverse the rendering tree to begin layout, calculating the position and size information of each node.
Paint each node of the rendering tree to the screen.

Reflow

When the position or size of DOM elements is changed, the browser needs to regenerate the rendering tree, a process called reflow.

Repaint

After regenerating the rendering tree, each node of the rendering tree needs to be painted to the screen, a process called repaint. Not all actions will cause reflow – for example, changing font color will only cause repaint. Remember, reflow will cause repaint, but repaint will not cause reflow.

Both reflow and repaint operations are very expensive because the JavaScript engine thread and the GUI rendering thread are mutually exclusive, and only one can work at a time.

What operations will cause reflow?

Adding or removing visible DOM elements
Element position changes
Element size changes
Content changes
Browser window size changes

How to reduce reflows and repaints?

When modifying styles with JavaScript, it's best not to write styles directly, but to replace classes to change styles.
If you need to perform a series of operations on a DOM element, you can take the DOM element out of the document flow, make modifications, and then bring it back to the document. It's recommended to use hidden elements (display:none) or document fragments (DocumentFragement), both of which can implement this approach well.

Example of causing unnecessary reflows (inefficient):

// This causes multiple reflows as each style change triggers a reflow
const element = document.getElementById('myElement');
element.style.width = '100px';
element.style.height = '200px';
element.style.margin = '10px';
element.style.padding = '20px';
element.style.borderRadius = '5px';

Optimized version 1 – using CSS classes:

/* style.css */
.my-modified-element {
  width: 100px;
  height: 200px;
  margin: 10px;
  padding: 20px;
  border-radius: 5px;
}

// Only one reflow happens when the class is added
document.getElementById('myElement').classList.add('my-modified-element');

Optimized version 2 – batching style changes:

// Batching style changes using cssText
const element = document.getElementById('myElement');
element.style.cssText = 'width: 100px; height: 200px; margin: 10px; padding: 20px; border-radius: 5px;';

Optimized version 3 – using document fragments (for multiple elements):

// Instead of adding elements one by one
const list = document.getElementById('myList');
const fragment = document.createDocumentFragment();

for (let i = 0; i < 100; i++) {
  const item = document.createElement('li');
  item.textContent = `Item ${i}`;
  fragment.appendChild(item);
}

// Only one reflow happens when the fragment is appended
list.appendChild(fragment);

Optimized version 4 – take element out of flow, modify, then reinsert:

// Remove from DOM, make changes, then reinsert
const element = document.getElementById('myElement');
const parent = element.parentNode;
const nextSibling = element.nextSibling;

// Remove (causes one reflow)
parent.removeChild(element);

// Make multiple changes (no reflows while detached)
element.style.width = '100px';
element.style.height = '200px';
element.style.margin = '10px';
element.style.padding = '20px';
element.style.borderRadius = '5px';

// Reinsert (causes one more reflow)
if (nextSibling) {
  parent.insertBefore(element, nextSibling);
} else {
  parent.appendChild(element);
}

Optimized version 5 – using display:none temporarily:

const element = document.getElementById('myElement');

// Hide element (one reflow)
element.style.display = 'none';

// Make multiple changes (no reflows while hidden)
element.style.width = '100px';
element.style.height = '200px';
element.style.margin = '10px';
element.style.padding = '20px';
element.style.borderRadius = '5px';

// Show element again (one more reflow)
element.style.display = 'block';

By using these optimization techniques, you can significantly reduce the number of reflows and repaints, leading to smoother performance, especially for animations and dynamic content updates.

12. Use Event Delegation

Event delegation takes advantage of event bubbling, allowing you to specify a single event handler to manage all events of a particular type. All events that use buttons (most mouse events and keyboard events) are suitable for the event delegation technique. Using event delegation can save memory.


  Apple
  Banana
  Pineapple


// good
document.querySelector('ul').onclick = (event) => {
  const target = event.target
  if (target.nodeName === 'LI') {
    console.log(target.innerHTML)
  }
}

// bad
document.querySelectorAll('li').forEach((e) => {
  e.onclick = function() {
    console.log(this.innerHTML)
  }
})

13. Pay Attention to Program Locality

A well-written computer program often has good locality – it tends to reference data items near recently referenced data items or the recently referenced data items themselves. This tendency is known as the principle of locality. Programs with good locality run faster than those with poor locality.

Locality usually takes two different forms:

Temporal locality: In a program with good temporal locality, memory locations that have been referenced once are likely to be referenced multiple times in the near future.
Spatial locality: In a program with good spatial locality, if a memory location has been referenced once, the program is likely to reference a nearby memory location in the near future.

Temporal locality example:

function sum(arry) {
    let i, sum = 0
    let len = arry.length

    for (i = 0; i < len; i++) {
        sum += arry[i]
    }

    return sum
}

In this example, the variable sum is referenced once in each loop iteration, so it has good temporal locality.

Spatial locality example:

Program with good spatial locality:

// Two-dimensional array 
function sum1(arry, rows, cols) {
    let i, j, sum = 0

    for (i = 0; i < rows; i++) {
        for (j = 0; j < cols; j++) {
            sum += arry[i][j]
        }
    }
    return sum
}

Program with poor spatial locality:

// Two-dimensional array 
function sum2(arry, rows, cols) {
    let i, j, sum = 0

    for (j = 0; j < cols; j++) {
        for (i = 0; i < rows; i++) {
            sum += arry[i][j]
        }
    }
    return sum
}

Looking at the two spatial locality examples above, the method of accessing each element of the array sequentially starting from each row, as shown in the examples, is called a reference pattern with a stride of 1.

If in an array, every k elements are accessed, it's called a reference pattern with a stride of k. Generally, as the stride increases, spatial locality decreases.

What's the difference between these two examples? Well, the first example scans the array by row, scanning one row completely before moving on to the next row. The second example scans the array by column, scanning one element in a row and immediately going to scan the same column element in the next row.

Arrays are stored in memory in row order, resulting in the example of scanning the array row by row getting a stride-1 reference pattern with good spatial locality. The other example has a stride of rows, with extremely poor spatial locality.

Performance Testing

Running environment:

CPU: i5-7400
Browser: Chrome 70.0.3538.110

Testing spatial locality on a two-dimensional array with a length of 9000 (child array length also 9000) 10 times, taking the average time (milliseconds), the results are as follows:

The examples used are the two spatial locality examples mentioned above.

Stride 1	Stride 9000
124	2316

From the test results above, the array with a stride of 1 executes an order of magnitude faster than the array with a stride of 9000.

So to sum up:

Programs that repeatedly reference the same variables have good temporal locality
For programs with a reference pattern with a stride of k, the smaller the stride, the better the spatial locality; while programs that jump around in memory with large strides will have very poor spatial locality

Reference:

Computer Systems: A Programmer's Perspective

14. if-else vs switch

As the number of judgment conditions increases, it becomes more preferable to use switch instead of if-else.

if (color == 'blue') {

} else if (color == 'yellow') {

} else if (color == 'white') {

} else if (color == 'black') {

} else if (color == 'green') {

} else if (color == 'orange') {

} else if (color == 'pink') {

}

switch (color) {
    case 'blue':

        break
    case 'yellow':

        break
    case 'white':

        break
    case 'black':

        break
    case 'green':

        break
    case 'orange':

        break
    case 'pink':

        break
}

In situations like the one above, from a readability perspective, using switch is better (JavaScript's switch statement is not based on hash implementation but on loop judgment, so from a performance perspective, if-else and switch are the same).

Why switch is better for multiple conditions:

Improved readability: Switch statements present a clearer visual structure when dealing with multiple conditions against the same variable. The case statements create a more organized, tabular format that's easier to scan and understand.
Cleaner code maintenance: Adding or removing conditions in a switch statement is simpler and less error-prone. With if-else chains, it's easy to accidentally break the chain or forget an "else" keyword.
Less repetition: In the if-else example, we repeat checking the same variable (color) multiple times, while in switch we specify it once at the top.
Better for debugging: When debugging, it's easier to set breakpoints on specific cases in a switch statement than trying to identify which part of a long if-else chain you need to target.
Intent signaling: Using switch communicates to other developers that you're checking multiple possible values of the same variable, rather than potentially unrelated conditions.

For modern JavaScript, there's another alternative worth considering for simple value mapping – object literals:

const colorActions = {
  'blue': () => { /* blue action */ },
  'yellow': () => { /* yellow action */ },
  'white': () => { /* white action */ },
  'black': () => { /* black action */ },
  'green': () => { /* green action */ },
  'orange': () => { /* orange action */ },
  'pink': () => { /* pink action */ }
};

// Execute the action if it exists
if (colorActions[color]) {
  colorActions[color]();
}

This approach provides even better performance (O(1) lookup time) compared to both if-else and switch statement approaches.

15. Lookup Tables

When there are many conditional statements, using switch and if-else is not the best choice. In such cases, you might want to try lookup tables. Lookup tables can be constructed using arrays and objects.

switch (index) {
    case '0':
        return result0
    case '1':
        return result1
    case '2':
        return result2
    case '3':
        return result3
    case '4':
        return result4
    case '5':
        return result5
    case '6':
        return result6
    case '7':
        return result7
    case '8':
        return result8
    case '9':
        return result9
    case '10':
        return result10
    case '11':
        return result11
}

This switch statement can be converted to a lookup table:

const results = [result0,result1,result2,result3,result4,result5,result6,result7,result8,result9,result10,result11]

return results[index]

If the conditional statements are not numerical values but strings, you can use an object to build a lookup table:

const map = {
  red: result0,
  green: result1,
}

return map[color]

Why lookup tables are better for many conditions:

Constant time complexity (O(1)): Lookup tables provide direct access to the result based on the index/key, making the operation time constant regardless of how many options there are. In contrast, both if-else chains and switch statements have linear time complexity (O(n)) because in the worst case, they might need to check all conditions.
Performance gains with many conditions: As the number of conditions increases, the performance advantage of lookup tables becomes more significant. For a small number of cases (2-5), the difference is negligible, but with dozens or hundreds of cases, lookup tables are substantially faster.
Code brevity: As shown in the examples, lookup tables typically require less code, making your codebase more maintainable.
Dynamic configuration: Lookup tables can be easily populated dynamically:

   const actionMap = {};

   // Dynamically populate the map
   function registerAction(key, handler) {
     actionMap[key] = handler;
   }

   // Register different handlers
   registerAction('save', saveDocument);
   registerAction('delete', deleteDocument);

   // Use it
   if (actionMap[userAction]) {
     actionMap[userAction]();
   }

Reduced cognitive load: When there are many conditions, lookup tables eliminate the mental overhead of following long chains of logic.

When to use each approach:

If-else: Best for a few conditions (2-3) with complex logic or different variables being checked
Switch: Good for moderate number of conditions (4-10) checking against the same variable
Lookup tables: Ideal for many conditions (10+) or when you need O(1) access time

In real applications, lookup tables might be populated from external sources like databases or configuration files, making them flexible for scenarios where the mapping logic might change without requiring code modifications.

16. Avoid Page Stuttering

60fps and Device Refresh Rate

Currently, most devices have a screen refresh rate of 60 times/second. Therefore, if there's an animation or gradient effect on the page, or if the user is scrolling the page, the browser needs to render animations or pages at a rate that matches the device's screen refresh rate.

The budget time for each frame is just over 16 milliseconds (1 second / 60 = 16.66 milliseconds). But in reality, the browser has housekeeping work to do, so all your work needs to be completed within 10 milliseconds. If you can't meet this budget, the frame rate will drop, and content will jitter on the screen.

This phenomenon is commonly known as stuttering and has a negative impact on user experience. Source: Google Web Fundamentals - Rendering Performance

Suppose you use JavaScript to modify the DOM, trigger style changes, go through reflow and repaint, and finally paint to the screen. If any of these takes too long, it will cause the rendering time of this frame to be too long, and the average frame rate will drop. Suppose this frame took 50 ms, then the frame rate would be 1s / 50ms = 20fps, and the page would appear to stutter.

For some long-running JavaScript, we can use timers to split and delay execution.

for (let i = 0, len = arry.length; i < len; i++) {
    process(arry[i])
}

Suppose the loop structure above takes too long due to either the high complexity of process() or too many array elements, or both, you might want to try splitting.

const todo = arry.concat()
setTimeout(function() {
    process(todo.shift())
    if (todo.length) {
        setTimeout(arguments.callee, 25)
    } else {
        callback(arry)
    }
}, 25)

If you're interested in learning more, check out High Performance JavaScript Chapter 6.

Reference:

Rendering Performance

17. Use `requestAnimationFrame` to Implement Visual Changes

From point 16, we know that most devices have a screen refresh rate of 60 times/second, which means the average time per frame is 16.66 milliseconds. When using JavaScript to implement animation effects, the best case is that the code starts executing at the beginning of each frame. The only way to ensure JavaScript runs at the beginning of a frame is to use requestAnimationFrame.

/**
 * If run as a requestAnimationFrame callback, this
 * will be run at the start of the frame.
 */
function updateScreen(time) {
  // Make visual updates here.
}

requestAnimationFrame(updateScreen);

If you use setTimeout or setInterval to implement animations, the callback function will run at some point in the frame, possibly right at the end, which can often cause us to miss frames, leading to stuttering.

Reference:

18. Use Web Workers

Web Workers use other worker threads to operate independently of the main thread. They can perform tasks without interfering with the user interface. A worker can send messages to the JavaScript code that created it by sending messages to the event handler specified by that code (and vice versa).

Web Workers are suitable for processing pure data or long-running scripts unrelated to the browser UI.

Creating a new worker is simple – just specify a script URI to execute the worker thread (main.js):

var myWorker = new Worker('worker.js');
// You can send messages to the worker through the postMessage() method and onmessage event
first.onchange = function() {
  myWorker.postMessage([first.value, second.value]);
  console.log('Message posted to worker');
}

second.onchange = function() {
  myWorker.postMessage([first.value, second.value]);
  console.log('Message posted to worker');
}

In the worker, after receiving the message, you can write an event handler function code as a response (worker.js):

onmessage = function(e) {
  console.log('Message received from main script');
  var workerResult = 'Result: ' + (e.data[0] * e.data[1]);
  console.log('Posting message back to main script');
  postMessage(workerResult);
}

The onmessage handler function executes immediately after receiving the message, and the message itself is used as the data property of the event. Here we simply multiply the two numbers and use the postMessage() method again to send the result back to the main thread.

Back in the main thread, we use onmessage again to respond to the message sent back from the worker:

myWorker.onmessage = function(e) {
  result.textContent = e.data;
  console.log('Message received from worker');
}

Here we get the data from the message event and set it as the textContent of result, so the user can directly see the result of the calculation.

Note that inside the worker, you cannot directly manipulate DOM nodes, nor can you use the default methods and properties of the window object. But you can use many things under the window object, including data storage mechanisms such as WebSockets, IndexedDB, and Firefox OS-specific Data Store API.

Reference:

19. Use Bitwise Operations

Numbers in JavaScript are stored in 64-bit format using the IEEE-754 standard. But in bitwise operations, numbers are converted to 32-bit signed format. Even with the conversion, bitwise operations are much faster than other mathematical and boolean operations.

Modulo

Since the lowest bit of even numbers is 0 and odd numbers is 1, modulo operations can be replaced with bitwise operations.

if (value % 2) {
    // Odd number
} else {
    // Even number 
}
// Bitwise operation
if (value & 1) {
    // Odd number
} else {
    // Even number
}

How it works: The & (bitwise AND) operator compares each bit of the first operand to the corresponding bit of the second operand. If both bits are 1, the corresponding result bit is set to 1; otherwise, it's set to 0.

When we do value & 1, we're only checking the last bit of the number:

For even numbers (for example, 4 = 100 in binary), the last bit is 0: 100 & 001 = 000 (0)
For odd numbers (for example, 5 = 101 in binary), the last bit is 1: 101 & 001 = 001 (1)

Floor

~~10.12 // 10
~~10 // 10
~~'1.5' // 1
~~undefined // 0
~~null // 0

How it works: The ~ (bitwise NOT) operator inverts all bits in the operand. For a number n, ~n equals -(n+1). When applied twice (~~n), it effectively truncates the decimal part of a number, similar to Math.floor() for positive numbers and Math.ceil() for negative numbers.

The process:

First ~: Converts the number to a 32-bit integer and inverts all bits
Second ~: Inverts all bits again, resulting in the original number but with decimal part removed

For example:

~10.12 → ~10 → -(10+1) → -11
~(-11) → -(-11+1) → -(-10) → 10

Bitmask

const a = 1
const b = 2
const c = 4
const options = a | b | c

By defining these options, you can use the bitwise AND operation to determine if a/b/c is in the options.

// Is option b in the options?
if (b & options) {
    ...
}

How it works: In bitmasks, each bit represents a boolean flag. The values are typically powers of 2 so each has exactly one bit set.

a = 1: Binary 001
b = 2: Binary 010
c = 4: Binary 100
options = a | b | c: The | (bitwise OR) combines them: 001 | 010 | 100 = 111 (binary) = 7 (decimal)

When checking if a flag is set with if (b & options):

b & options = 010 & 111 = 010 = 2 (decimal)
Since this is non-zero, the condition evaluates to true

This technique is extremely efficient for storing and checking multiple boolean values in a single number, and is commonly used in systems programming, graphics programming, and permission systems.

20. Don't Override Native Methods

No matter how optimized your JavaScript code is, it can't match native methods. This is because native methods are written in low-level languages (C/C++) and compiled into machine code, becoming part of the browser. When native methods are available, try to use them, especially for mathematical operations and DOM manipulations.

Example: String Replacement (Native vs. Custom)

A common pitfall is rewriting native string methods like replaceAll(). Below is an inefficient custom implementation versus the native method, with performance benchmarks:

// Inefficient custom global replacement (manual loop)  
function customReplaceAll(str, oldSubstr, newSubstr) {  
  let result = '';  
  let index = 0;  
  while (index < str.length) {  
    if (str.slice(index, index + oldSubstr.length) === oldSubstr) {  
      result += newSubstr;  
      index += oldSubstr.length;  
    } else {  
      result += str[index];  
      index++;  
    }  
  }  
  return result;  
}  

// Efficient native method (browser-optimized)  
function nativeReplaceAll(str, oldSubstr, newSubstr) {  
  return str.replaceAll(oldSubstr, newSubstr);  
}  

// Test with a large string (100,000 repetitions of "abc ")  
const largeString = 'abc '.repeat(100000);  

// Benchmark: Custom implementation  
console.time('customReplaceAll');  
customReplaceAll(largeString, 'abc', 'xyz');  
console.timeEnd('customReplaceAll'); // Output: ~5ms (varies by browser)  

// Benchmark: Native method  
console.time('nativeReplaceAll');  
nativeReplaceAll(largeString, 'abc', 'xyz');  
console.timeEnd('nativeReplaceAll'); // Output: ~2ms (typically 2-3x faster)

Key takeaways:

Performance: Native methods like replaceAll() are optimized at the browser level, often outperforming handwritten code (as shown in the benchmark above).
Maintainability: Native methods are standardized, well-documented, and less error-prone than custom logic (for example, handling edge cases like overlapping substrings).
Ecosystem compatibility: Using native methods ensures consistency with libraries and tools that rely on JavaScript’s built-in behavior.

When to Use Custom Code

While native methods are usually superior, there are rare cases where you might need custom logic:

When the native method doesn’t exist (for example, polyfilling for older browsers).
For highly specialized edge cases not covered by native APIs.
When you need to avoid function call overhead in extremely performance-critical loops (for example, tight numerical computations).

Remember: Browser vendors spend millions of hours optimizing native methods. By leveraging them, you gain free performance boosts and reduce the risk of reinventing flawed solutions.

21. Reduce the Complexity of CSS Selectors

1. When browsers read selectors, they follow the principle of reading from right to left.

Let's look at an example:

#block .text p {
    color: red;
}

Find all P elements.
Check if the elements found in result 1 have parent elements with class name "text"
Check if the elements found in result 2 have parent elements with ID "block"

Why is this inefficient? This right-to-left evaluation process can be very expensive in complex documents. Take the selector #block .text p as an example:

The browser first finds all p elements in the document (potentially hundreds)
For each of those paragraph elements, it must check if any of their ancestors have the class text
For those that pass step 2, it must check if any of their ancestors have the ID block

This creates a significant performance bottleneck because:

The initial selection (p) is very broad
Each subsequent step requires checking multiple ancestors in the DOM tree
This process repeats for every paragraph element

A more efficient alternative would be:

#block p.specific-text {
    color: red;
}

This is more efficient because it directly targets only paragraphs with a specific class, avoiding checking all paragraphs

2. CSS selector priority

Inline > ID selector > Class selector > Tag selector

Based on the above two pieces of information, we can draw conclusions:

The shorter the selector, the better.
Try to use high-priority selectors, such as ID and class selectors.
Avoid using the universal selector *.

Practical advice for optimal CSS selectors:

/* ❌ Inefficient: Too deep, starts with a tag selector */
body div.container ul li a.link {
    color: blue;
}

/* ✅ Better: Shorter, starts with a class selector */
.container .link {
    color: blue;
}

/* ✅ Best: Direct, single class selector */
.nav-link {
    color: blue;
}

Finally, I should say that according to the materials I've found, there's no need to optimize CSS selectors because the performance difference between the slowest and fastest selectors is very small.

Reference:

Optimizing CSS: ID Selectors and Other Myths

22. Use Flexbox Instead of Earlier Layout Models

In early CSS layout methods, we could position elements absolutely, relatively, or using floats. Now, we have a new layout method called Flexbox, which has an advantage over earlier layout methods: better performance.

The screenshot below shows the layout cost of using floats on 1300 boxes:

Then we recreate this example using Flexbox:

Now, for the same number of elements and the same visual appearance, the layout time is much less (3.5 milliseconds versus 14 milliseconds in this example).

But Flexbox compatibility is still an issue, as not all browsers support it, so use it with caution.

Browser compatibility:

Chrome 29+
Firefox 28+
Internet Explorer 11
Opera 17+
Safari 6.1+ (prefixed with -webkit-)
Android 4.4+
iOS 7.1+ (prefixed with -webkit-)

Reference:

Use flexbox instead of earlier layout models

23. Use Transform and Opacity Properties to Implement Animations

In CSS, transforms and opacity property changes don't trigger reflow and repaint. They’re properties that can be processed by the compositor alone.

Example: Inefficient vs. Efficient Animation

❌ Inefficient animation using properties that trigger reflow and repaint:

/* CSS */
.box-inefficient {
  position: absolute;
  left: 0;
  top: 0;
  width: 100px;
  height: 100px;
  background-color: #3498db;
  animation: move-inefficient 2s infinite alternate;
}

@keyframes move-inefficient {
  to {
    left: 300px;
    top: 200px;
    width: 150px;
    height: 150px;
  }
}

This animation constantly triggers layout recalculations (reflow) because it animates position (left/top) and size (width/height) properties.

✅ Efficient animation using transform and opacity:

/* CSS */
.box-efficient {
  position: absolute;
  width: 100px;
  height: 100px;
  background-color: #3498db;
  animation: move-efficient 2s infinite alternate;
}

@keyframes move-efficient {
  to {
    transform: translate(300px, 200px) scale(1.5);
    opacity: 0.7;
  }
}

Why this is better:

transform: translate(300px, 200px) replaces left: 300px; top: 200px
transform: scale(1.5) replaces width: 150px; height: 150px
These transform operations and opacity changes can be handled directly by the GPU without triggering layout or paint operations

Performance comparison:

The inefficient version may drop frames on lower-end devices because each frame requires:
- JavaScript → Style calculations → Layout → Paint → Composite
The efficient version typically maintains 60fps because it only requires:
- JavaScript → Style calculations → Composite

HTML implementation:

class="box-inefficient">Inefficient
class="box-efficient">Efficient

For complex animations, you can use the Chrome DevTools Performance panel to visualize the difference. The inefficient animation will show many more layout and paint events compared to the efficient one.

Reference:

Use transform and opacity property changes to implement animations

24. Use Rules Reasonably, Avoid Over-Optimization

Performance optimization is mainly divided into two categories:

Load-time optimization
Runtime optimization

Of the 23 suggestions above, the first 10 belong to load-time optimization, and the last 13 belong to runtime optimization. Usually, there's no need to apply all 23 performance optimization rules. It's best to make targeted adjustments based on the website's user group, saving effort and time.

Before solving a problem, you need to identify the problem first, otherwise you won't know where to start. So before doing performance optimization, it's best to investigate the website's loading and running performance.

Check Loading Performance

A website's loading performance mainly depends on white screen time and first screen time.

White screen time: The time from entering the URL to when the page starts displaying content.
First screen time: The time from entering the URL to when the page is completely rendered.

You can get the white screen time by placing the following script before .

You can get the first screen time by executing new Date() - performance.timing.navigationStart in the window.onload event.

Check Runtime Performance

With Chrome's developer tools, we can check the website's performance during runtime.

Open the website, press F12 and select performance, click the gray dot in the upper left corner, it turns red to indicate it has started recording. At this point, you can simulate users using the website, and after you're done, click stop, then you'll see the website's performance report during the runtime.

If there are red blocks, it means there are frame drops. If it's green, it means the FPS is good. For detailed usage of performance, you can search using a search engine, as the scope is limited.

By checking the loading and runtime performance, I believe you already have a general understanding of the website's performance. So what you need to do now is to use the 23 suggestions above to optimize your website. Go for it!

References:

performance.timing.navigationStart

Conclusion

Performance optimization is a critical aspect of modern web development that directly impacts user experience, engagement, and ultimately, business outcomes. Throughout this article, we've explored 24 diverse techniques spanning various layers of web applications – from network optimization to rendering performance and JavaScript execution.

Key Takeaways

Start with measurement, not optimization. As discussed in point #24, always identify your specific performance bottlenecks before applying optimization techniques. Tools like Chrome DevTools Performance panel, Lighthouse, and WebPageTest can help pinpoint exactly where your application is struggling.
Focus on the critical rendering path. Many of our techniques (placing CSS in the head, JavaScript at the bottom, reducing HTTP requests, server-side rendering) are centered around speeding up the time to first meaningful paint – the moment when users see and can interact with your content.
Understand the browser rendering process. Knowledge of how browsers parse HTML, execute JavaScript, and render pixels to the screen is essential for making informed optimization decisions, especially when dealing with animations and dynamic content.
Balance implementation cost vs. performance gain. Not all optimization techniques are worth implementing for every project. For instance, server-side rendering adds complexity that might not be justified for simple applications, and bitwise operations provide performance gains only in specific heavy computation scenarios.
Consider the device and network conditions of your users. If you're building for users in regions with slower internet connections or less powerful devices, techniques like image optimization, code splitting, and reducing JavaScript payloads become even more important.

Practical Implementation Strategy

Instead of trying to implement all 24 techniques at once, consider taking a phased approach:

First pass: Implement the easy wins with high impact
- Proper image optimization
- HTTP/2
- Basic caching
- CSS/JS placement
Second pass: Address specific measured bottlenecks
- Use performance profiling to identify problem areas
- Apply targeted optimizations based on findings
Ongoing maintenance: Make performance part of your development workflow
- Set performance budgets
- Implement automated performance testing
- Review new feature additions for performance impact

By treating performance as an essential feature rather than an afterthought, you'll create web applications that not only look good and function well but also provide the speed and responsiveness that modern users expect.

Remember that web performance is a continuous journey, not a destination. Browsers evolve, best practices change, and user expectations increase. The techniques in this article provide a strong foundation, but staying current with web performance trends will ensure your applications remain fast and effective for years to come.

Other References

How to Use Zod for React API Validation

Emore Ogheneyoma Lawrence — Fri, 28 Feb 2025 17:59:48 +0000

In React applications, handling API (Application Programming Interface) responses can be challenging. You might encounter data that’s missing crucial fields, that’s formatted unexpectedly, or that simply doesn’t match what you anticipated.

This inconsistency can lead to errors in your code and make it difficult to work with the data effectively. Imagine wrestling with unpredictable API responses as your application grows – it can quickly become a development nightmare!

This is where Zod comes in, offering a solution to effectively manage API data validation within React.

By the end of this tutorial, you’ll learn how to:

Set up and use Zod for API response validation in React.
Define schemas to validate and transform incoming data.
integrate Zod into API calls to improve data handling and prevent UI crashes.

What is Zod, and Why Use it for React API Calls?
How to Generate a New TypeScript React Project
Core Zod Concepts: Basic Usage, Types, and Validation
How to Build Zod Schemas for API Responses
How to Integrate Zod with React API Calls
How to Render the User Interface (UI) and Handle Errors in React
Conclusion

What is Zod, and Why Use it for React API Calls?

Zod is a powerful TypeScript-first library that simplifies data validation. It lets you define clear rules (schemas) for your expected data format.

Zod can then validate incoming data (often from API responses) to ensure it conforms to these rules. This validation process guarantees that the data adheres to your defined format, enhancing the reliability and integrity of your application.

Here's why Zod shines for React API validation:

Clear schemas: Zod helps you define concise blueprints for API responses, enhancing readability and maintainability.
Data validation: It offers powerful validation methods for various data types, enforcing rules like required fields and specific formats.
Early error detection: It helps you detect data inconsistencies during API calls, preventing unexpected errors later in the application.
Improved developer experience: It promotes type-safe coding, streamlining development time by eliminating manual data type checks.
Single source of truth: And finally, Zod serves as a central point for data model definitions, ensuring consistency across the React application and reducing errors.

Using Zod, you can transform unpredictable API responses into clean, structured data, setting the stage for a smoother and more efficient development experience in your React applications.

How to Generate a New TypeScript React Project

Creating a new React project with TypeScript is straightforward. Here's how to get started. Execute the following command in your terminal:

npm create vite@latest my-react-app -- --template react-ts

Once the project is generated, navigate to the projects directory:

cd my-react-app
npm install
npm run dev

That’s it! Your React Project with TypeScript is now up and ready to use. Run the command below to install the Zod package:

npm install zod

Core Zod Concepts: Basic Usage, Types, and Validation

Zod helps you define clear expectations for your API responses using schemas. These schemas act like blueprints, specifying the types of data you expect to receive.

How to Build Schemas

Zod provides builder functions like z.string(), z.number(), and z.object() to create schemas. These functions define the data type you want for a specific field in your response.

import { z } from 'zod';
// Define basic data types
const userName = z.string().min(5).max(10); // String with min 5 and max 10 characters
const userAge = z.number().positive().int();  // Positive integer
const userEmail = z.string().email();        // Ensures a valid email format

console.log(userName.parse('John Doe'));       // Output: John Doe (valid)
console.log(userAge.parse(30));              // Output: 30 (valid)
console.log(userEmail.parse("johnDoe@gmail.com")); // Output: johnDoe@gmail.com (valid)

The code above defines three basic data types:

userName: Represents a string with a minimum length of 5 characters and a maximum length of 10 characters.
userAge: Represents a positive integer.
userEmail: Ensures a valid email format.

Here’s the result of the code above:

How to Add Validation Rules

Zod allows you to chain methods like min, max, positive, int, and email to enforce specific rules on these data types. Here’s an example of an invalid string exceeding the maximum length:

console.log(userName.parse("Hello there, My Name is John Doe")); // Throws ZodError

The code throws a ZodError due to exceeding the maximum length of 10 strings, disrupting our application flow and eventually causing our application to break.

Here’s the image of the resulting code error:

Validating and Parsing

Zod offers two ways to check data against your schema:

schema.parse(data): This method attempts to parse the data according to your schema. But if there's a validation error, it throws a ZodError. This can disrupt your application's flow, as illustrated in the previous example.
schema.safeParse(data): This is the recommended approach. it parses the data and returns a ZodResult object. This object contains some key properties:
- success: A boolean indicating whether the parsing was successful.
- data: The parsed data itself (if the success property is true)
- error: An error message if validation fails (if success property is false)

Here are two examples showcasing the usage of safeParse with both valid and invalid data so you can see the resulting outcomes.

First, lets see an example using safeParse with valid data:

const userSchema = z.object({
  name: userName,
  age: userAge,
  email: userEmail,
});

const userData = {
  name: "John Doe",
  age: 24,
  email: "johndoe@gmail.com"
};

const result = userSchema.safeParse(userData);

console.log(result); // ZodObject containing data and success status

This code defines a schema for user data using Zod, including properties for name, age, and email. It then attempts to parse a sample userData object using this schema via safeParse(). If successful, it prints the parsed data – otherwise, it logs an error message indicating the use of invalid data.

Here’s the image of the resulting code above:

Let’s now see how safeParse() handles invalid data using the same example as above. We’ll pass invalid data to the userSchema.safeParse() function to observe its behaviour.

const userSchema = z.object({
  name: userName,
  age: userAge,
  email: userEmail,
});

const userData = {
  name: "John Doe",
  age: 24,
  email: "johndoe.com" // invalid email
};

const result = userSchema.safeParse(userData);

console.log(result); // ZodObject containing error and success status

In this code example, we defined the userSchema. Next, we attempted to parse the userData object. But the parsing failed because the email property was not correctly formatted. Here’s a visual representation of the resulting output:

Unlike using parse, which completely halts your application upon encountering validation errors and throws a ZodError, utilizing safeParse allows you to gracefully handle these errors, ensuring uninterrupted operation.

How to Build Zod Schemas for API Responses

Building on our understanding of Zod’s core concepts, let’s create Zod schemas specifically for data received from API calls. We’ll leverage data from JSONPlaceholder, which offers information about posts.

Here’s a sample JSON response representing a post from JSONPlaceholder:

{
  "userId": 1,
  "id": 3,
  "title": "ea molestias quasi exercitationem repellat qui ipsa sit aut",
  "body": "et iusto sed quo iure\nvoluptatem occaecati omnis eligendi aut"
}

Create a React component (give it a name that fits your project structure) to demonstrate building and utilizing Zod schemas for API validation. In this article, for illustrative purposes, we’ll call it the ZodApi component.

 import { z } from 'zod';

  const postSchema = z.object({
  userId: z.number().positive().int(),
  id: z.number().positive().int(),
  title: z.string(),
  body: z.string()
});

const postSchemaArray = z.array(postSchema); // Schema for array of posts

This code defines the expected structure of a single post object (postSchema) and an array of posts (postSchemaArray).

The following sections will explore integrating Zod with React components for API call handling and error management.

How to Integrate Zod with React API Calls

Let's bridge the gap between your defined Zod schemas and real API interactions.

We’ll need to update the code we wrote in the previous section to achieve our desired result in this section.

import { z } from 'zod';
import { useEffect } from 'react';

const postSchema = z.object({
  userId: z.number().positive().int(),
  id: z.number().positive().int(),
  title: z.string(),
  body: z.string()
});

const postSchemaArray = z.array(postSchema); // schema for an array of posts

type Posts = z.infer<typeof postSchemaArray>; // type of the posts

const ZodApi = () => {
  useEffect(() => {
    fetch("https://jsonplaceholder.typicode.com/posts")
      .then((response) => response.json())
      .then((posts: Posts) => {
        const validatedPosts = postSchemaArray.safeParse(posts); // remember to use safeParse instead of parse

        if (validatedPosts.success === false) {
          console.log("Validation Error:"validatedPosts.error);
          return;
        }

        // we can now safely use the posts
        console.log(validatedPosts.data);
      });
  }, []);
  return ZodApi;
};

export default ZodApi;

The ZodApi component demonstrates:

Fetching data: Uses useEffect and fetch to get data from the API.
Type safety: type Posts = z.infer; ensures type safety by defining the Posts type inferred from the schema postSchemaArray.
Parsing with Zod: Validates the fetched data against the postSchemaArray using safeParse.
Handling success: If validation succeeds, it provides access to clean data in validatedPosts.data for use in your component (UI, state, and so on).

Error handling: The if statement showcases a simple approach to Zod error handling. In a case where the validation is not successful (validatedPosts.success === false), a ZodError message is logged to the console.

Here’s a snapshot showing the resulting output in the console.

How to Render the User Interface (UI) and Handle Errors in React

In this section, you’ll learn how to render the UI based on our validated data and implement the error-handling mechanism using React states.

import { z } from "zod";
import { useEffect, useState } from "react";

const postSchema = z.object({
  userId: z.number().positive().int(),
  id: z.number().positive().int(),
  title: z.string(),
  body: z.string(),
});

const postSchemaArray = z.array(postSchema); // schema for an array of posts

type Posts = z.infer<typeof postSchemaArray>; // type of the posts

const ZodApi = () => {
  const [posts, setPosts] = useState([]); // State to store validated posts
  const [error, setError] = useState(""); // State to store any errors
  useEffect(() => {
    fetch("https://jsonplaceholder.typicode.com/posts")
      .then((response) => response.json())
      .then((posts: Posts) => {
        const validatedPosts = postSchemaArray.safeParse(posts); // remember to use safeParse instead of parse

        if (validatedPosts.success === false) {
          console.log(validatedPosts.error.name);
          setError(validatedPosts.error.message); // set error state
          return;
        }

        // we can now safely use the validatedPosts 
        console.log(validatedPosts.data);
        setPosts(validatedPosts.data)
      });
  }, []);

  // Handle loading state (optional)
  if (!posts.length && !error) {
    return Loading posts...;
  }

  // Handle error state
  if (error) {
    return Error fetching Data</div>; // Display user-friendly error message
  }

  return (
    
      Postsh1>
      
        {posts.map((post) => (
          
            {post.title}
          
        ))}
      
    
  );
};

export default ZodApi;

In the code above, we’ve updated the ZodApi component to perform the following tasks:

State declaration: The posts and error states hold the data and error (if any) gotten from the fetch request.
Error handling: We use the posts and error state to show a “Loading posts…” message when the posts are being fetched and no error occurs, and display an error message when an error occurs.
Rendering posts: It maps through the fetched posts and renders them on the UI.

Output:

After fetching the results, you should see the 100 posts displayed on your screen. If you followed the steps correctly, you'll find all 100 posts visible. If you encounter any issues, make sure the fetching process was successful.

Conclusion

By incorporating Zod into your React development workflow, you can build more robust and reliable applications.

Zod empowers you to catch mismatched data early on, preventing errors and saving valuable debugging time. Also, the user-friendly error messages given by Zod validation enhance your application’s overall user experience.

How to Use CSS to Improve Web Accessibility

Elizabeth Lola — Wed, 18 Sep 2024 17:13:12 +0000

Did you know that CSS can play a significant role in web accessibility? While CSS primarily handles the visual presentation of a webpage, when you use it properly it can enhance the user’s experience and improve accessibility.

In this article, I'll share some ways CSS can support accessibility so you can start using these techniques in your own projects.

Prerequisites

To follow along with this tutorial, you should have a basic understanding of HTML, CSS, and a little bit of Javascript.

Update Focus Styles

The browser provides default focus styles for interactive elements like buttons or input fields. But sometimes these default focus styles might not be ideal for your design system – especially if the colors used in your design are too close to the default colors. This might make it difficult to notice.

Also, different browsers have different default focus styles and you might want to standardize the focus styles to ensure uniformity.

You can change the default focus style of an element in CSS using the :focus pseudo-class. For example, the default focus style for an input element is a blue outline in Chrome and a blue outline with outline offset in Firefox, to update the default focus styles of an input element you can do this:

input:focus {
  outline: 2px solid #007BFF;
  outline-offset: 2px;
  border-radius: 1rem;
}

Avoid Content Shifts

Content shifts can happen when you’re lazy loading images, where images load progressively as the user scrolls down the page. Sometimes the image pushes the content around it downwards, shifting the text you're reading out of place.

Content shifts can also happen during dynamic content fetching, especially when new content like text, images, or ads is added to the page without reserving space for it in advance.

Content shifts can be frustrating, especially for users:

With cognitive disabilities who may lose track of where they are in the content.
Using screen magnifiers, where the shift can cause them to lose their zoomed-in focus.
Navigating with a keyboard, as it can mess up the natural tab order and make navigation confusing.

You can pre-allocate space for content to prevent shifts by using the min-height or aspect-ratio properties. Here's how you can allocate space for an image to prevent content shift before the image has fully loaded.

img {
    width: 100%;
    height: auto;
    aspect-ratio: 16/9;
    object-fit: cover; /* Ensures the image fits well within the allocated space */
}

You can also use animations or transitions when dynamically loading content to add smooth transitions for new content. So, instead of a sudden shift, the content slides in gracefully, reducing the perception of disruption.

.new-content {
    transition: margin 0.3s ease-in-out, opacity 0.3s ease-in-out;
}

Reduce Motion

Rapid animations or really complex transitions can be disorienting for users with motion sensitivity, which could lead to discomfort like headaches, dizziness, or vertigo (for users with vestibular disorders).

You can use CSS’s prefers-reduced-motion media query to reduce or disable animations for users.

Personally, instead of disabling animations completely, I replace complex, distracting animations with more subtle ones to maintain functionality while respecting user preferences.

Here's how to use prefers-reduced-motion to create a simpler animation:

/* Default animation */
@keyframes complexAnimation {
    0% { transform: translateX(0); opacity: 0; }
    50% { transform: translateX(100px); opacity: 0.5; }
    100% { transform: translateX(0); opacity: 1; }
}

.element {
    animation: complexAnimation 2s ease-in-out;
}

/* Simpler animation for reduced motion preference */
@media (prefers-reduced-motion: reduce) {
    @keyframes simpleAnimation {
        0% { opacity: 0; }
        100% { opacity: 1; }
    }

    .element {
        animation: simpleAnimation 1s ease-in-out;
    }
}

Here’s an example from the code above. If you have reduced motion enabled you’ll see a fading ball instead of a moving ball:

Note: If you want to see the reduced motion in action, you can enable it in the rendering tab on Google Chrome.

Focus Within for Nested Elements

You can highlight or style a parent element when any of its child elements receive focus to make it clear which group (like form inputs or dropdown menus) is currently being interacted with.

To do this, you can use CSS’s :focus-within pseudo-class which is used to style an element when any of its descendants receive focus either through keyboard navigation or user interaction.

For example, to highlight a fieldset when any item in the group is focused in a grouped control, you can do this:

<style>
 fieldset {
   padding: 10px;
   border: 1px solid #ccc;
 }

 fieldset:focus-within {
   border-color: #007BFF; /* highlight the fieldset when a user focuses on any input */
 }
style>

<fieldset>
  <legend>Choose a color:legend>
  <label><input type="radio" name="color" value="red"> Redlabel>
  <label><input type="radio" name="color" value="green"> Greenlabel>
  <label><input type="radio" name="color" value="blue"> Bluelabel>
fieldset>

Customize Contrast Options

Sometimes you may be working on a design that uses lots of colors and might not maintain high contrast between text and background to fit an aesthetic. Or perhaps you're working on a design with lots of bright colors. In these cases, you should consider how your application renders for different users.

Some users with low vision or certain types of color blindness might need high contrast mode to differentiate text from the background more clearly. Other users sensitive to bright colors might prefer a softer, less jarring visual experience.

Some of these users might have their systems set to high or low contrast to help improve their experience. To customize their experience, you can use the CSS prefers-contrast media query.

The prefers-contrast media query allows you to tailor the contrast of your website or application based on the user's system settings.

Here's an example of using prefers-contrast:

/* default styling preference */
body {
    background-color: white;
    color: black;
}

/* high contrast preference */
@media (prefers-contrast: more) {
    body {
        background-color: black;
        color: white;
    }
    a {
        color: yellow;
    }
}
/* low contrast preference */

@media (prefers-contrast: less) {
    body {
        background-color: #f0f0f0;
        color: #333;
    }
    a {
        color: #555;
    }
}

In the example above, the prefers-contrast: more option ensures that when a user prefers high contrast, the background is black and the text is white, with yellow links for better visibility.

The prefers-contrast: less adjusts the color scheme to a softer color for users who prefer less contrast. The default style is used if the user has no specific contrast preference or if their preference is not detected.

Note: If your design uses minimal colors and maintains high contrast between text and background or you're working with a design where text is minimal and the focus is on visual content (like image galleries or video players), you might not need prefers-contrast as much. But it's still good practice to consider contrasts.

Enable Dark Mode

You can use CSS to accommodate users’ preferences for dark or light modes. You can achieve this through the CSS prefers-color-scheme media query. The browser can detect the user's color preference and apply the style if provided in CSS.

Here's an example of how you can add a dark mode style to your site using CSS variables:

:root {
  --background-color: #ffffff;
  --text-color: #000000;
}

@media (prefers-color-scheme: dark) {
  :root {
    --background-color: #000000;
    --text-color: #ffffff;
  }
}

body {
  background-color: var(--background-color);
  color: var(--text-color);
}

In the example above, the variables get updated if the browser detects a dark color scheme preference.

If you want to allow users to toggle between modes manually, you can use JavaScript for this:

<style>
 /* Default light mode styles */
  body {
   background-color: #ffffff;
   color: #000000;
  }
 /* Dark mode styles */
  body.dark-mode {
   background-color: #000000;
   color: #ffffff;
  }
style>

<button id="toggle-theme">Toggle Themebutton>

<script>
  const toggleButton = document.getElementById('toggle-theme');
  toggleButton.addEventListener('click', () => {
   document.body.classList.toggle('dark-mode');
  });
script>

Use `rem` Units for Responsive Typography

Using rem units for responsive typography can help enhance accessibility to adapt more dynamically to a user's preference. Since rem is relative to the root font size (typically set by the browser or user), it scales with changes in the base font size. This helps ensure that text remains readable without breaking layouts.

Users can set a preferred font size in their browser or operating system for better readability. When you use rem, the website content scales according to this setting which ensures that the text is not too small or too large for the users (which can happen when using fixed units like px).

When users zoom in using browser settings or increase their preferred text size, the rem-based text will scale appropriately.

The default root font size (usually 16px) is typically inherited from the browser, but you can set it explicitly if needed:

html {
  font-size: 100%; /* Default 16px */
}

After setting the root font size, you can use rem unit for the rest of your content. For example:

h1 {
  font-size: 2.5rem; /* Equivalent to 40px if root is 16px */
}

p {
  font-size: 1rem; /* Equivalent to 16px */
}

Use Animations to Enhance UX

CSS animations can enhance accessibility when used thoughtfully. They can help create an engaging and understandable experience for users.

Here are some ways that animations can help improve accessibility:

You can use animations to indicate loading state to visually communicate to users that the system is working on a task.
Using animated text effects, like fades or scaling on headlines or important sections, can help guide users' eyes to important content. This can be useful for people with cognitive disabilities who benefit from clear visual hierarchies.
Subtle transitions for state change instead of having abrupt changes (like a modal popping up instantly) can create smoother transitions between different interface states.
Using animated highlights or shaking effects on form fields can provide visual feedback to users about input errors. You should pair these animations with labels or ARIA attributes to make it clear what the user needs to correct.
Animations can help users track focus, especially keyboard users or those with visual impairments. CSS transitions that highlight focused elements (for example by enlarging buttons or changing the border) assist users in understanding where they are within the page.

Best Practices:

Ensure animations are used purposefully, not just for aesthetic reasons.
Avoid overly long or continuous animations that can distract or annoy users.
Combine animations with other accessible features, such as screen reader announcements, to ensure all users understand content changes.

Conclusion

When considering accessibility, well-structured HTML forms the foundation of an accessible page – but CSS also plays a vital role in enhancing that structure.

CSS alone cannot fix poorly structured HTML. But when it’s applied thoughtfully to a solid foundation, it ensures a more inclusive and engaging experience by improving visual hierarchy, readability, and interaction for users of all abilities.

Combining accessible HTML with CSS not only improves the user interface but also provides support for assistive technologies.

Thank you so much for reading this article. If you found it helpful, consider sharing. Happy coding!

You can connect with me on LinkedIn.

How to Build an Accessible Modal – with Example Code

Elizabeth Lola — Tue, 27 Aug 2024 15:10:54 +0000

We often use modals or popups to display important information or prompt users to take action. Unlike regular pop-ups that can be opened in new windows or tabs, these dialogues keep the user on the same page by overlaying the existing content. This ensures that users remain focused on the task at hand.

Modals are common and sometimes required. And if they're not implemented correctly, they can be a significant barrier. Ensuring that modals are accessible means they are usable by everyone, including people who rely on assistive technologies.

In this article, we'll build a modal and follow the guidelines to make it accessible.

Prerequisites

To follow along with this tutorial, you should have:

Basic HTML knowledge: Understand how HTML elements and attributes work.
Basic JavaScript knowledge: Familiarity with basic JavaScript concepts like functions, event handling, and DOM manipulation is helpful.
Understanding of ARIA: While the tutorial explains ARIA roles and attributes, having a basic understanding of accessibility concepts can be beneficial.

Using modals effectively requires careful consideration of the user experience. Here are some guidelines to help you decide if you should use a modal or not:

You should use modals when the user needs to make a critical decision, such as confirming a potentially destructive action (for example, deleting an item) or agreeing to terms and conditions
You can use a modal when a task requires the user’s complete focus and does not rely on information from the rest of the page (for example, filling out a form or completing a payment process).
You can use a modal for displaying temporary or transient information that doesn’t need to be permanently visible on the page (for example, alerts, notifications, or brief messages).
You should avoid using modals for tasks that require extensive interaction or input, such as lengthy forms or complex workflows. These can be frustrating in a modal because of limited space and navigation constraints.
You should avoid using modals for actions a user will need to perform frequently, as this can become repetitive and annoying. Inline options or tooltips might be better for repetitive actions.
You should not use modals if they interrupt the user’s natural flow on the site, especially if the content or action in the modal is not urgent or important.

Here are some tips to help you build useful and accessible modals:

Provide a descriptive aria-labelledby attribute that points to the modal's title or heading. If there is no title, use aria-label to provide a short, descriptive label.

Always include a visible and easily accessible close button within the modal, usually in the top-right corner. Label this button clearly, for example, with the text "Close" or an icon with aria-label="Close".
When the modal opens, move the keyboard focus to the first interactive element within the modal (usually a close button). When the modal closes, return the focus to the element that triggered the modal.
Keep the keyboard focus within the modal while it is open.
Allow users to close the modal by pressing the Escape key.

Following these guidelines, let's build a modal.

I prefer using the right HTML tags to build components, and in this case I'll be doing exactly that using the dialog tag.

How to Build a Modal Using the `dialog` Tag

In case you're not familiar with the dialog tag, it was introduced in HTML5. You use it to create dialog boxes like popups, alerts, and modals. It offers built-in methods and attributes that make it easier to manage dialog behavior without needing extensive JavaScript. The javascript built-in methods are show(), showModal(), and close().

`show()` and `showModal()`

The show() method is useful for a non-blocking dialog. This means that the dialog appears on top of the current content, but users can still interact with other parts of the webpage (clicking buttons, links, and so on) while the dialog is open.

This is useful in situations where the dialog is providing information that doesn’t require the user’s immediate attention. Here's an example:


<dialog id="dialog-box">

dialog>

<script>
    const dialog = document.getElementById('dialog-box');
    dialog.show();
script>

Result:

The showModal() method opens the dialog in a modal mode. This means that the dialog takes focus, and interaction with the rest of the webpage is blocked until the dialog is closed. The user cannot click on or interact with any other part of the page.

Depending on the browser, a semi-transparent backdrop appears behind the dialog, visually indicating that the rest of the page is not interactable.

When a dialog is opened with showModal(), focus is automatically trapped within the dialog. The user can only tab through elements inside the dialog, and the focus will loop within the dialog’s content until it is closed. Here's an example:

<dialog id="dialog-box">

dialog>

<script>
    const dialog = document.getElementById('dialog-box');
    dialog.showModal();
script>

Result:

The

element has default styles but can be customized using CSS to match your design. You can style the dialog box, add animations, or modify the backdrop. The backdrop can be styled using the ::backdrop selector. For example:

dialog::backdrop {
    background: rgba(0, 0, 0, 0.7);
}

The dialog also comes with some built-in accessibility features like focus management, backdrop, automatic announcement on open, and pressing the ESC key will close the dialog.

You can add the autofocus attribute to the first interactive element in the modal, such as the first input in a form or the close button. Alternatively, you can rely on the

element's native focus management.

Avoid using tabindex on the

element, as it is not an interactive element like a button or link. The serves as a container for interactive content, and it is not intended to receive direct user focus.

The

element provides a native way to create modals. If you're building a custom modal, make sure its accessibility features match those of the native element.

Bringing it all together:

<style>
    dialog::backdrop {
        background: rgba(0, 0, 0, 0.7);
    }
style>
<body>
    <button id="open-dialog">Open Dialogbutton>
    <dialog id="dialog-box">
        <h2>Modal titleh2>
        <div>
          
          <button id="close-dialog" autofocus>Closebutton>
        div>
    dialog>

<script>
    const dialog = document.getElementById("dialog-box");
    const openButton = document.getElementById("open-dialog");
    const closeButton = document.getElementById("close-dialog");

    openButton.addEventListener("click", () => {
      dialog.showModal();
    });
    closeButton.addEventListener("click", () => {
      dialog.close();
    });
script>
body>

You'll notice that I didn't use the aria-label attribute on the dialog as I listed in the guidelines. Well, that's because the dialog element, if well-structured, doesn't necessarily need one. In this case, there's a visible label in the dialog element (the h2 element).

If there are no visible labels present then you need to add one. Like in this example:

<dialog id="confimation-dialog" aria-label="Confirmation Dialog">
    <p>Are you sure you want to proceed?p>
    <button id="close-dialog" autofocus>Closebutton>
dialog>

What is the `inert` Attribute?

When a modal is open, a screen reader might still navigate to and around content outside the modal. You would generally want the user's focus to be restricted to the modal itself, or stop the user from accidentally clicking on elements outside the modal to prevent confusion and errors. In these cases, you'll need the inert attribute.

The inert attribute makes an element and all of its descendants non-interactive and inaccessible to assistive technologies. When a modal is open, using the inert attribute on the rest of the page content will ensure that only the modal content can be accessed, making the dialog experience clearer.

How to Use the `inert` Attribute

When a modal is opened, you can apply the inert attribute to the rest of the page content (typically the

element). When the modal is closed, you remove the inert attribute.

Here's an example showing how to use inert with a modal dialog:

<body>
    <header>Site Headerheader>
    <main id="main-content">
        <button id="open-dialog">Open modalbutton>
        <p>This is the main content of the page.p>
        

    main>
    
    <dialog id="dialog">
        <h2>Modal Titleh2>
        <p>This is the content inside the modal.p>
        <button id="close-dialog" autofocus>Closebutton>
    dialog>

    <script>
        const dialog = document.getElementById('dialog');
        const mainContent = document.getElementById('main-content');
        const openButton = document.getElementById('open-dialog');
        const closeButton = document.getElementById('close-dialog');

        openButton.addEventListener("click", () => {
           mainContent.setAttribute('inert', '');
          dialog.showModal();
        });

        closeButton.addEventListener("click", () => {
           dialog.close();
        });

        // the dialog elemnt has a close event, which is called when a user calls the close() method or presses the esc key
        dialog.addEventListener("close", (event) => {
           mainContent.removeAttribute("inert");
        });
    script>
body>

How to Animate the Open and Close States

When a modal appears (open state) or disappears (close state), it can be jarring for users if this transition happens abruptly. Animating these states can create a smoother user experience by gradually introducing or removing the modal, making it feel more natural.

Why Animate the Open and Close States?

Animating the open and close states of a modal can:

Enhance User Experience: A smooth animation can make the transition less abrupt and more engaging.
Draw Attention: Subtle animations can help guide the user's focus to the modal content when it appears.
Maintain Consistency: Consistent animations across your UI can create a cohesive and professional feel.

By default, the dialog is set to display:none when closed and display:block when open. You cannot transition from none to block in CSS, but you can combine the display properties with transform or opacity. The transform property can be used to scale or move the modal, while opacity controls its transparency.

Here’s an example of how you might animate a modal:

dialog {
  animation: zoom-out 0.5s ease-out;
}

/* an open attribute is added to the dialog when it is open  */
dialog[open] {
    animation: zoom-in 0.5s ease-out;
}

/* The display property in the keyframes is critical 
because it toggles the modal’s visibility on and off.  */
@keyframes zoom-in {
    0% {
      opacity: 0;
      transform: scale(0.1);
      display:  none;
    }
    100% {
      opacity: 1;
      transform: scale(1);
      display: block;
    }
}

@keyframes zoom-out {
    0% {
      opacity: 1;
      transform: scale(1);
      display: block;
    }
    100% {
      opacity: 0;
      transform: scale(0);
      display: none;
    }
}

Final result:

Conclusion

The

Frontend Web Development: In-Depth Project Tutorial

Beau Carnes — Tue, 04 Apr 2023 18:29:33 +0000

Are you looking to improve your frontend web development skills with HTML, CSS, JavaScript, TypeScript, and React? If so, we have the perfect video course for you!

We just published a 10-hour project-based, frontend web development course on the freeCodeCamp.org YouTube channel.

Zach Gollwitzer published this course. Zach is a full stack developer and his Frontend Developer Bootcamp course we published a few months ago has over 1,000,000 views. This new course is a sequel to that previous course. However, you can jump straight to this course if you already have a basic understanding of HTML, CSS, and JavaScript.

This video course is divided into four sections, with each section building on the previous one. In Section 1, you will learn how to build a Tic Tac Toe game with Vanilla HTML/CSS/JS. This will be the foundation for the rest of the course.

In this first section, you will learn how to set up your project and the necessary VSCode extensions. Then, you will build the UI with HTML and CSS and add JavaScript interactivity to the project.

In Section 2, you will refactor the Tic Tac Toe game to use the Model-View-Controller (MVC) pattern. You will explore why this pattern is helpful and how it can improve the structure of your code.

Section 3 will introduce you to TypeScript and teach you how to set it up from scratch. You will learn the benefits of using TypeScript and how it can improve the reliability and maintainability of your code.

Finally, in Section 4, you will refactor the Tic Tac Toe game to use React and TypeScript. You will learn how to set up a React app from scratch and explore why React is useful and what problems it solves over a Vanilla approach. You will also learn how to initialize TypeScript in a React app from scratch and refactor your Vanilla app to a React app.

This video course is perfect for anyone looking to improve their frontend web development skills, from beginners to intermediate developers.

Watch the full course on the freeCodeCamp.org YouTube channel (10-hour watch).

How to Add Search Functionality to a Frontend Application

freeCodeCamp — Tue, 04 Jan 2022 16:28:58 +0000

By Njoku Samson Ebere

As a software developer, part of your job is to deliver the best user experience possible to those using your site or product.

And building a helpful and efficient search function is one way you can do this. So if you are looking for the right way to build out search functionality on the front end of your site, you're in the right place.

Some time ago, I thought that search functionality had to be built in the back end and called from the front end.

But as I continued building applications, I learned that sometimes, you might just have to search among the data retrieved from a public endpoint where there is no search endpoint. Other times, frontend search might be necessary to improve a website’s speed and user experience in general.

This tutorial will first go through the "wrong way" of setting up search which many of us have adopted. And then we'll learn a much better way of doing it. So stick with me and let me take you on this ride.

Prerequisites

It will be easy to follow this tutorial if you have basic knowledge of:

Starter Project

I have cooked up a little application to give you a head-start if you want to code along with me. Just clone this repository. The branch of interest is the starter-code branch.

Follow the instructions in the ReadMe file to setup the project and you should have the following screen:

Starter Project Screen

In the project you now have, we are fetching COVID-19 updates for every country in the src/context/hatchways.js file courtesy of coronatracker.

In our src/App.js file, we display the results we have gotten. A search input box is situated above the list of results. For each of these result, the src/components/Country.js file is rendered.

As a user types into the input box, the filterCountryByName function is called to search through the countries we collected earlier. This function is being built in the src/Helpers/HatchHelper.js file.

All styles are in the src/styles/App.scss file.

You should now be able to navigate around the project and find your way. Let's begin with how you shouldn't build out your search functionality.

How NOT to Build Search Functionality

We will focus on the src/Helpers/HatchHelper.js file to build out the search function.

Already we have the following code:

// search countries by name
const filterCountryByName = (name, countries, setResults) => {
  // clear search result if the search field is empty
  if (name === "") {
    setResults([]);
  }

  // discontinue if there is no search yet
  if (name === null || name === "" || countries === []) return;
};

Next, we need to empty the previous search array so that we don't add the new search result to it. This is just in case we already made a search and want to do another.

    // empty the previous search array if any
    const searchResult = [];

Convert the search string to lower case for consistency's sake. This will make the search case insensitive.

const data = name.toLowerCase();

Now, loop through the countries like so:

  // loop through all countries
  for (const country of countries) {

  }

Next, collect each country name and make it lower case to ensure that the search will be case insensitive like so:

    const countryName = country.countryName.toLowerCase();

Below that, check if the search string matches one character in the country name ([...countryName].includes(data)), one word in the country name (countryName.split(" ").includes(data)) or the full country name (countryName === data) and collect the country details like so:

    // check if the search word or character matches
    if (
      [...countryName].includes(data) ||
      countryName === data ||
      countryName.split(" ").includes(data)
    ) {
      searchResult.push(country);
    }

When the loop is done, update the search Result with the following line of code:

setResults(searchResult);

The filterCountryByName function now looks like this:

// search countries by name
const filterCountryByName = (name, countries, setResults) => {
  // clear search result if the search field is empty
  if (name === "") {
    setResults([]);
  }

  // discontinue if there is no search yet
  if (name === null || name === "" || countries === []) return;

  // empty the previous search array if any
  const searchResult = [];
  const data = name.toLowerCase();

  // loop through all countries
  for (const country of countries) {
    const countryName = country.countryName.toLowerCase();

    // check if the search word or character matches
    if (
      [...countryName].includes(data) ||
      countryName === data ||
      countryName.split(" ").includes(data)
    ) {
      searchResult.push(country);
    }
  }

  setResults(searchResult);
};

Replace the main element in the src/App.js file with the following code to ensure proper feedback during search:

<main>
    {filterByNameResults && filterByNameResults.length
    ? filterByNameResults.map((country) => (
    <Country country={country} />
    ))
    : filterByName && !filterByNameResults.length
    ? "No Result Found!"
    : hatchLoading === "processing"
    ? "Fetching Data..."
    : hatchLoading === "found" && hatches && hatches.length
    ? hatches.map((country) => <Country country={country} />)
    : "No country Found! Check your Internet Connection!"}
main>

How to Test Your Search Function

Let's now make a search and see what we get:

Testing How to Make Frontend Search the Wrong Way

Here's the code for the wrong way to code a search function.

What is the problem with the search method above?

You will notice that the search string must satisfy at least one of the 3 conditions that we specified for a result to be returned.

So how about a user who isn't sure of the spelling but knows a couple of characters contained in the country name?

Do you notice that the user will take more time to search certain words because the words must me typed completely to get a match?

Think about this: ITA- should be able to return ITALY, NIG- should be able to return NIGER and NIGERIA, and so on.

So while our search works, these issues make it difficult to use and negatively impact the user experience. This now takes us to the right way to make this search functionality.

How to Build a Search Feature the Right Way

We need to create another search just below the current one.

Start by setting 2 initial states to hold the search string and the search results for this new search like so:

  const [searchString, setSearchString] = useState("");
  const [searchResult, setSearchResult] = useState([]);

Next, make another input box just below the first one like so:

          {/* search by name the right way*/}
          "searchString"
            value={searchString}
            placeholder="Search by name (Right Way)"
            onChange={(e) => setSearchString(e.target.value)}
            onKeyUp={(e) =>
              searchCountryByName(
                e.target.value,
                hatches,
                setSearchResult
              )
            }
          />

Go to the src/Helpers/HatchHelper.js file and create the searchCountryByName function below the filterCountryByName function:

// search countries by name the right way
const searchCountryByName = (
  searchString,
  countries,
  setSearchResult
) => {

};

Include it in the export like this:

export { filterCountryByName, searchCountryByName };

You can now import it in the src/App.js file like so:

import { filterCountryByName, searchCountryByName } from "./Helpers/HatchHelper";

You should now have a second input box that doesn’t do anything just yet:

Screen showing a second input box that doesn’t do anything just yet

Fleshing out the function

We will now build out the function to work as we desire.

Begin by adding the following lines of code:

    // clear search result if the search field is empty
    if (searchString === "") {
      setSearchResult([]);
    }

    // discontinue if there is no search yet
    if (searchString === null || searchString === "" || countries === []) return;

Next, empty the previous search array if any like this:

// empty the previous search array if any
  setSearchResult([]);

Then create a variable that will hold our search results while searching:

let results = [];

Create a regular expression pattern for the search string like so:

  // create a regular expression pattern for the search string
  const pattern = new RegExp(searchString, "gi");

In the code above, we are saying that we want to use this searchString for something. While using it, we want it to be case-insensitive and we want all possible results. You can learn more about regular expressions here.

Now loop through countries and collect each country name like so:

  // loop through all countries
  for (const country of countries) {
    const countryName = country.countryName;

  }

Still in the loop, test if the regular expression pattern matches the countryName that we just collected. If it is true, then add the country details to the results array like so:

// check if the search word or character matches
if (pattern.test(countryName)) {
    results.push(country);
}

Finish by updating the search result using the following code:

setSearchResult(results)

The searchCountryByName function now looks like this:

// search countries by name the right way
const searchCountryByName = (
  searchString,
  countries,
  setSearchResult
) => {
  // clear search result if the search field is empty
  if (searchString === "") {
    setSearchResult([]);
  }

  // discontinue if there is no search yet
  if (searchString === null || searchString === "" || countries === []) return;

  // empty the previous search array if any
  setSearchResult([]);
  let results = [];

  // create a regular expression pattern for the search string
  const pattern = new RegExp(searchString, "gi");

  // loop through all countries
  for (const country of countries) {
    const countryName = country.countryName;

    // check if the search word or character matches
    if (pattern.test(countryName)) {
      results.push(country);
    }
  }

  setSearchResult(results)
};

Return to the src/App.js file and replace the main element with the following code:

        <main>
          {filterByNameResults && filterByNameResults.length
            ? filterByNameResults.map((country) => (
                <Country country={country} />
              ))
            : filterByName && !filterByNameResults.length
            ? "No Result Found!"
            : searchResult && searchResult.length
            ? searchResult.map((country) => <Country country={country} />)
            : searchString && !searchResult.length
            ? "No Result Found!"
            : hatchLoading === "processing"
            ? "Fetching Data..."
            : hatchLoading === "found" && hatches && hatches.length
            ? hatches.map((country) => <Country country={country} />)
            : "No country Found! Check your Internet Connection!"}
        main>

Now, the results for the second search box are included above.

Testing your search function (the right way)

Testing How to Make Frontend Search the Right Way

Walah! You just learned the right way to create a search on the front end. 😊

Here's the code for the right way to build a search function.

How to Optimize Your Search Functionality

We are actually done. So you can skip this if you are busy, but it will just take a moment if you want to improve your search function.

You will notice that when you make a search the wrong way and do not refresh the page, you will be stuck with the results of the wrong way. It would be better to get fresh results when the second search box is used for the right way.

To achieve that, we will need to clear all search results for every search being made – whether it is the Wrong or Right Way. Let's do the following:

In the src/App.js, replace the onkey event of the first search box with the following:

            onKeyUp={(e) =>
              filterCountryByName(
                e.target.value,
                hatches,
                setFilterByNameResults,
                setSearchString,
                setSearchResult
              )
            }

Replace the onkey event of the second search box with the following:

            onKeyUp={(e) =>
              searchCountryByName(
                e.target.value,
                hatches,
                setSearchResult,
                setFilterByName,
                setFilterByNameResults
              )
            }

In the src/Helpers/HatchHelper.js file, add the 2 parameters we just passed into the filterCountryByName like so:

// search countries by name
const filterCountryByName = (
  name,
  countries,
  setResults,
  setSearchString,
  setSearchResult
) => {...}

Next, just before clearing the initial search results, clear the other search field and results like so:

  // clear the other search field and results if any
  setSearchString("");
  setSearchResult([]);

Now do the same for the searchCountryByName function.

When you are done, you should have the following result:

Our application after we have optimised the functionality

Awesome! 👍🏾👍🏾👍🏾

Here's the optimisation code.

Conclusion

It has been an awesome ride with you as we saw the mistakes many of us have made and how to correct them by creating a search function that offers the best experience to the user.

I believe the code can be improved even more. So I encourage to take a look at the code again and see how you can make it even better.

All the code is here. Thanks for reading!

Giphy API Tutorial – How to Generate Animated Text GIFs with ReactJS

freeCodeCamp — Wed, 26 May 2021 21:44:01 +0000

By Charles M.

In this tutorial you will create an app that generates dynamic animated text using Giphy's API with ReactJS.

After that I'll go over some of the other API features Giphy provides that you can use to make other interesting projects.

You can find the code for the tutorial here.

Video Tutorial

To see a preview of the finished product in action, you can watch the start of this video. If you prefer to follow a video tutorial instead of reading (or in addition to reading), you can also follow along for the rest of the video.

Getting Started

To get started you'll need a basic development environment for ReactJS. I'll be using create-react-app as the starting project template.

Next you'll need to visit Giphy's developers page and create an account so you can get your API key. Once you've created your account you'll see a dashboard like this:

You need to click "create an App" and choose the SDK option for your app. Your dashboard will then present you with an API key you will use to make calls to the Giphy API.

How to Setup the App File and Folder

The structure for this tutorial will be standard for ReactJS projects. Inside the src directory, create a components directory and create two files, Error.js and TextList.js

You also need to create a .env file in the root of the project that you'll use to store your API key. Whatever you name your variable, you need to append REACT_APP in front of it, like this:

REACT_APP_GIPHY_KEY=apikeyhere

Install Giphy JS-fetch

The final thing you need to do is install Giphy's API helper library which you can do using the following command:

npm install @giphy/js-fetch-api

Giphy API Call

The first task in making this app is creating an input form to accept the text you want to generate from the Giphy API. You will then use that text input and send it as an API request.

Before displaying this response data, let's test it out by simply making the API request and then logging the response. Write the following code in your App.js file:

import { GiphyFetch } from '@giphy/js-fetch-api'
import {useState} from 'react'
import TextList from './components/TextList'
import Error from './components/Error'
import './App.css';

const giphy = new GiphyFetch(process.env.REACT_APP_GIPHY_KEY)

function App() {
  const [text, setText] = useState('')
  const [results, setResults] = useState([])
  const [err, setErr] = useState(false)

  const handleInput = (e) => {
    setText(e.target.value)
  }

  const handleSubmit = (e) => {
    if(text.length === 0) {

      //set error state to true
      setErr(true)
      return
    }

    console.log(text)

    const apiCall = async () => {
      const res = await giphy.animate(text, {limit: 20})
      console.log(res.data)
      setResults(res.data)
    }

    apiCall()
    setText('')
    setErr(false)

  }

  return (
    <div className="App">
      <h1>Animated Text Generatorh1>
      <h3>Type text into the form and hit submith3>
      <input className='input-field' value={text} onChange={handleInput} />
      <button className='submit-btn' onClick={handleSubmit}>Submitbutton>
    div>
  );
}
export default App;

Let's take a look at what's happening in this code:

const giphy = new GiphyFetch(process.env.REACT_APP_GIPHY_KEY) is where you use the Giphy helper library to create the object you'll use for interacting with the Giphy API.

process.env.REACT_APP_GIPHY_KEY is how your API key is passed as an argument from the .env file. You can also pass your API key as a string, but you won't want to do this in production because somebody could steal and use your key.

Inside the main App component, you create three pieces of state using hooks. The 1st is text which will be what stores the user input. This is what will be passed to the API as an argument to generate text.

err will be used to conditionally render an error later if the user attempts to submit an empty string.

And results is an empty array that will be used to store the results from the API response.

If you run the code and check your developer console, you should see that the Giphy API returned an array with 20 objects.

How to Display the Data with React

Now that the data is being properly stored in state, all you need to do is display that data with JSX. To handle that, we'll finish those two components we created earlier.

First we'll make a simple error component that can display a custom message. Place the following code into Error.js inside your components folder:

const Error = (props) => {
    if(!props.isError) {
        return null
    }

    return (
        <p className='error'>{props.text}p>
    )
}

export default Error

The Error component is very simple. It takes the err state and a text string as props, and if the value is true it will render the text. If err is false, it returns null.

Next is the TextList component which will take the results state as props and then display the data in your app:

const TextList = (props) => {
  const items = props.gifs.map((itemData) => {
    return <Item url={itemData.url} />;
  });
  return <div className="text-container">{items}div>;
};
const Item = (props) => {
  return (
    <div className="gif-item">
      <img src={props.url} />
    div>
  );
};
export default TextList;

This component is a little more complicated, so here's what is happening:

The Item component accepts the URL value which is inside each value returned from the API. It uses this URL as the source for the image element.

The results state array from the App component is passed to the TextList component as gifs. The array is mapped over to generate all the Item components for all the results and assigned to the items variable and then returned inside a container div. We'll style this container later to create a grid layout.

How to Import the Components into the Main App

Now you just need to use those finished components in your JSX. The final code of your App.js file should look like this:

import TextList from './components/TextList'
import Error from './components/Error'
import { GiphyFetch } from '@giphy/js-fetch-api'
import {useState} from 'react'
import './App.css';

const giphy = new GiphyFetch(process.env.REACT_APP_GIPHY_KEY)

function App() {
  const [text, setText] = useState('')
  const [results, setResults] = useState([])
  const [err, setErr] = useState(false)

  const handleInput = (e) => {
    setText(e.target.value)
  }

  const handleSubmit = (e) => {
    if(text.length === 0) {

      //set error state to true
      setErr(true)
      return
    }

    console.log(text)

    const apiCall = async () => {
      const res = await giphy.animate(text, {limit: 20})

      setResults(res.data)
    }

    apiCall()
    //change error state back to false
    setText('')
    setErr(false)

  }

  return (
    <div className="App">
      <h1>Animated Text Generatorh1>
      <h3>Type text into the form and hit submith3>
      <input className='input-field' value={text} onChange={handleInput} />
      <button className='submit-btn' onClick={handleSubmit}>Submitbutton>
      <Error isError={err} text='need length longer than 0 for input'/>
      {results && <TextList gifs={results}  />}
    div>
  );
}
export default App;

The only changes here are the bottom two lines added in the return statement:

The Error component is passed the err state and a text prop which will only be rendered if an error occurs.

In this app there is only one error condition in case the input is empty, but you could add additional checks with custom error messages as well.

Then we use conditional rendering with the && logical operator. This causes the TextList component to render only if the results array is not empty, which means the API response returned successfully with our gifs.

If you run your code at this point, you should see an ugly but functional app. If you use the input field and click the submit button, the gifs should be returned and displayed in your app.

How to Add Styling with CSS

The last thing to do is make the app look a little bit prettier. Feel free to customize any of these styles if you want to adjust how things look. Place this code into your App.css file:

.App {
  text-align: center;
}

.error {
  color: #b50000;
  font-size: 20px;
  font-weight: 500;
}


.input-field {
  font-size: 20px;
  vertical-align: middle;
  transition: .5s;
  border-width: 2px;
  margin: 5px;
}

.input-field:focus {
  box-shadow: 0 14px 28px rgba(0,0,0,0.25), 0 10px 10px rgba(0,0,0,0.22);
  outline: none;
}

.input-field:hover {
  box-shadow: 0 14px 28px rgba(0,0,0,0.25), 0 10px 10px rgba(0,0,0,0.22);

}

.submit-btn {
  background-color: rgb(19, 209, 235);
  color: #fff;
  padding: 6px 30px;
  vertical-align: middle;
  outline: none;
  border: none;
  font-size: 16px;
  transition: .3s;
  cursor: pointer;
}

.submit-btn:hover {
  background-color: rgb(10, 130, 146);
}

.text-container {
  display: flex;
  flex-wrap: wrap;
  justify-content: center;
}

.gif-item {
  flex-basis: 19%;
}

img {
  max-width: 100%;
}

@media screen and (max-width: 992px) {
  .gif-item {
    flex-basis: 31%;
  }
}

@media screen and (max-width: 600px) {
  .gif-item {
    flex-basis: 48%;
  }
}

Nothing crazy going on here with the CSS. Just some styling for the submit button and some box shadow for the input field.

There are also a few media queries for some responsive design that changes the column count depending on the screen size.

Other Giphy API features

The animated text API is just one feature available in the Giphy API. I'll go over a few other features that could be useful as part of a project or as a solo project.

Animated Emoji

The Emoji endpoint is very straightforward in terms of use. It returns a bunch of animated emoji just like the animated text API you used above, except you don't need to pass any arguments to it. An example API call:

const data = await gf.emoji()

This endpoint could be useful if you are building a chat application and want to make it easy for users to use Emoji in their messages.

Pre-Built UI components

If you don't feel like messing around with a ton of custom code like we did in this tutorial, Giphy actually provides components for both ReactJS and regular JavaScript.

You can make a grid very similar to what we created in this tutorial with just a few lines of code:

import { Grid } from '@giphy/react-components'
import { GiphyFetch } from '@giphy/js-fetch-api'

// use @giphy/js-fetch-api to fetch gifs
// apply for a new Web SDK key. Use a separate key for every platform (Android, iOS, Web)
const gf = new GiphyFetch('your Web SDK key')

// fetch 10 gifs at a time as the user scrolls (offset is handled by the grid)
const fetchGifs = (offset: number) => gf.trending({ offset, limit: 10 })

// React Component
ReactDOM.render(<Grid width={800} columns={3} gutter={6} fetchGifs={fetchGifs} />, target)

You get some additional bonus features like automatic dynamic updates to fetch more content when users scroll to the bottom of the Grid.

You can choose between templates which handle almost everything or just a Grid component which gives you a little more control.

Here's an interactive demo provided by Giphy.

This endpoint returns a list of constantly updated content based on user engagement and what is currently popular on Giphy.

Search API

This endpoint is similar to the animated text endpoint, you just need to pass a search query as a parameter and you'll get an array of gifs that match.

There are many more API endpoints available. You can see the rest in Giphy's API documentation.

Conclusion

That's it for this tutorial! I hope you found it interesting and you make some cool projects using the Giphy API.

If you are interested in a bunch of other cool APIs that you can use for making portfolio projects, you can check out this video as well which goes over 8 more APIs that I think are really cool.

How to Add Search to a React App with Fuse.js

Colby Fayock — Tue, 26 May 2020 14:45:00 +0000

Search is a powerful way help people visiting your site find the content that's most important to them. But often it's really challenging to figure out the rules and logic to make that happen. In this article, we'll see how can we can use fuse.js to add search to our apps.

What is fuse.js?
Why is search important?
What are we going to build?
Step 0: Bootstrapping our app
Step 1: Installing Fuse.js
Step 2: Creating a new Fuse search instance
Step 3: Setting up dynamic search based on user input

What is fuse.js?

Fuse.js is a JavaScript library that provides fuzzy search capabilities for applications and websites. It's nice and easy to use out of the box, but also includes configuration options that allow you to tweak and create powerful solutions.

Why is search important?

Whether you're a content creator or are trying to sell a product with your website, it's important to help your visitors actually find what they're looking for.

If you're building an ecommerce website, you want someone to be able to easily find your Bender vinyl figures rather than having to dig through the entire catalog first.

What are we going to build?

We're going to start off with a basic Create React App example. It's going to include some character info as structured data for one of my favorite shows Futurama that's simply dumped out into an HTML list.

With that list, we're going to use fuse.js to provide client-side search capabilities, allowing us to demonstrate searching for the character we're looking for by their name and other details.

Step 0: Bootstrapping our app

To get started, we're going to need content to work with. I got started by building a list of characters from Futurama as structured json data that I put in a list with a fresh Create React App.

Futurama character search demo

You'll also notice I've already added an input for our search. It's not yet functional but we'll use that to get started.

If you'd like to start off at the same place, I created a branch with my demo repo that you can clone locally to walk through the project with me!

git clone --single-branch --branch start git@github.com:colbyfayock/my-futurama-characters.git

Git branch "start"

Or follow along with the commit.

Step 1: Installing Fuse.js

First thing we'll want to do is actually add Fuse.js to our app. In your project, run:

yarn add fuse.js
# or
npm install --save fuse.js

This will save the dependency to our project so that we'll be able to use it in our project.

Next we'll want to import the dependency to our app so that we can start building with it. At the top of your file, in our case src/App.js if you're following along with me in a new Create React App project, add:

import Fuse from 'fuse.js';

If you want to test that it's working, you can console.log(Fuse) and see our Fuse class we'll use to create our search capabilities.

Imported fuse.js class

And with that, we're ready to get started!

Follow along with the commit

Step 2: Creating a new Fuse search instance

To use Fuse.js, we'll want to first create a new instance of it.

At the top of your component, add:

const fuse = new Fuse(characters, {
  keys: [
    'name',
    'company',
    'species'
  ]
});

With this does:

Creates a new instance of Fuse
Passes in our characters array of objects
Specifies the 3 keys in our data that we want to search on

Next, to perform the search, we can add:

const results = fuse.search('bender');

And if we console log out the results, we can see:

Basic fuse.js search results

You'll notice that we have more results than our friend Bender though. Fuse.js provides a "fuzzy search" meaning it tries to help you in case you're not sure what you're looking for or if you're misspelling your query.

To get an idea of how this works, let's add the includeScore option to our search:

const fuse = new Fuse(characters, {
  keys: [
    'name',
    'company',
    'species'
  ],
  includeScore: true
});

Now we can see the score attribute in our results object.

Fuse.js search results with score

You'll notice that our first result has a really low score. With fuse.js, a lower score means it's closer to an exact match.

A score of 0 indicates a perfect match, while a score of 1 indicates a complete mismatch.

It's saying that is incredibly likely that the first result is what we're looking for, but it's not confident in the others.

So with our results, we want to actually connect that to our UI. If you notice our array output is different than what we are mapping through for the HTML list, so let's create a new variable that we can change it to:

const results = fuse.search('bender');
const characterResults = results.map(character => character.item);

What this is doing is creating a new array using the map method that will only include the item property from each array object.

Then if we replace our characters map inside of our list with characterResults.map:

"characters">
  {characterResults.map(character => {
    const { name, company, species, thumb } = character;

We can now see that our page only shows the results for "bender"!

Demo with filtered results

Follow along with the commit!

Step 3: Setting up dynamic search based on user input

Now that we have a hard-coded search working, we want someone to actually be able to use the search input to search!

To achieve this, we're going to use the useState hook and listen for changes to the input field, which will dynamically create a search for our data.

First, import the useState hook from React:

import React, { useState } from 'react';

Next, let's use that hook to create a state instance:

const [query, updateQuery] = useState('');

Here, we're creating a new state of query that we can update with updateQuery that defaults to an empty string ('').

With that, let's tell our search input to use that query value as it's value:

"text" value={query} />

At this point, nothing should be different, as we are using a blank query.

Demo with filtered results - nothing changed

Now let's add an event handler to our input that we can use to update our state:

"text" value={query} onChange={onSearch} />

And we'll want to create that function so we can use it:

function onSearch({ currentTarget }) {
  updateQuery(currentTarget.value);
}

This will update our query with the input's value any time it changes.

Now that our query will have what we want to search for, we can update our search instance:

const results = fuse.search(query);

And now if you reload the page, it's blank! ?

Demo with no results

That's because by default, Fuse sees our empty query and doesn't match it to anything. If we now search for something like slurms, we can see our search dynamically update with results!

Demo with results for "slurms"

If we wanted to fix this though so that all of our results show when there's no query, we can do so with an if statement or in my example, a ternary, that will show all of the characters if there is no query:

const characterResults = query ? results.map(character => character.item) : characters;

Demo with all results

And with that, we have our basic search!

Demo with filtered results for "zoidberg"

Follow along with the commit!

What can I do next?

Tuning your search

Fuse.js comes with a lot of options that you can use to tune your search to however you'd like. Want to only show confident results? Use the threshold option! Want case sensitive queries? Use the isCaseSensitive option!

https://fusejs.io/api/options.html

Setting the default query with URL parameters

Sometimes you want someone to be able to link to a particular set of results. To do this, we might want to be able to add a new URL parameter like ?q=bender.

To make this work, you can grab that URL parameter with javascript and use that value to set our query state.

Join the conversation!

What is Tailwind CSS and How Can I Add it to my Website or React App?

Colby Fayock — Tue, 19 May 2020 14:45:00 +0000

CSS is a technology that can be your best or worst friend. While it's incredibly flexible and can produce what seems like magic, without the proper care and attention, it can become hard to manage like any other code.

How can Tailwind CSS help us to take control of our styles?

What is Tailwind?
So what makes Tailwind great?
Part 1: Adding Tailwind CSS to a static HTML page
Part 2: Adding Tailwind CSS to a React app

What is Tailwind?

Tailwind CSS is a "utility-first" CSS framework that provides a deep catalog of CSS classes and tools that lets you easily get started styling your website or application.

The underlying goal is that as you're building your project, you don't need to deal with cascading styles and worrying about how to override that 10-selector pileup that's been haunting your app for the last 2 years.

So what makes Tailwind great?

Taildwind's solution is to provide a wide variety of CSS classes that each have their own focused use. Instead of a class called .btn that is created with a bunch of CSS attributes directly, in Tailwind, you would either apply a bunch of classes like bg-blue-500 py-2 px-4 rounded to the button element or build a .btn class by applying those utility class to that selector.

While Tailwind has a lot more going for it, we're going to focus on these basics for this tutorial, so let's dig in!

Part 1: Adding Tailwind CSS to a static HTML page

We're going to start off by applying Tailwind CSS straight to a static HTML page. The hope is that by focusing on Tailwind and not the app, we can get a better understanding of what's actually happening with the framework.

Step 1: Creating a new page

You can get started by simply creating a new HTML file. For the content, you can use whatever you want, but I'm going to use fillerama.io so the filler content is a bit more fun.

New HTML page with content

If you want to simplify this step, you can just copy the file I created to get started.

Follow along with the commit!

Step 2: Adding Tailwind CSS via CDN

Tailwind typically recommends that you install through npm to get the full functionality, but again, we're just trying to understand how this works first.

So let's add a link to the CDN file in the of our document:

<link href="https://unpkg.com/tailwindcss@^1.0/dist/tailwind.min.css" rel="stylesheet">

Once you save and reload the page, the first thing you'll notice is that all of the styles were stripped!

HTML page with the Tailwind CSS base

This is expected. Tailwind includes a set of preflight styles to fix cross-browser inconsistencies. For one, they include the popular normalize.css which they build upon with their own styles.

But we're going to learn how to use Tailwind to add back our styles and set things up how we want!

Follow along with the commit!

Step 3: Using Tailwind CSS to add styles to your page

Now that we have Tailwind installed, we've added the ability to make use of their huge library of utility classes that we'll now use to add styles back to our page.

Let's start off by adding some margin to all of our paragraphs (

) and our list elements (

.my-5

<p class="my-5">
  Bender, quit destroying the universe! Yeah, I do that with my stupidness. I never loved you. Moving along…
  Belligerent and numerous.
p>

The class name follows a pattern that you'll notice with the rest of the utility classes – .my-5 stands for margin (m) applied to the y-axis (y) with a value of 5 which in Tailwind's case, it uses rem, so the value is 5rem.

HTML page with basic paragraph styles

Next, let's make our headers look like actual headers. Starting with our h1 tag, let's add:

<h1 class="text-2xl font-bold mt-8 mb-5">

Here's what's happening:

text-2xl: set the text size (font-size) to 2xl. In Tailwind, that 2xl will equate to 1.5rem
font-bold: set the weight of the text (font-weight) to bold
mt-8: Similar to my-5, this will set the margin top (t) to 8rem
mb-5: And this will set the margin bottom (b) to 5rem

HTML page with styled H1

With those classes added to the h1, let's apply those same exact classes to the rest of our header elements, but as we go down the list, reduce the size of the font size, so it will look like:

h2: text-xl
h3: text-lg

HTML page with all headers styled

Now let's make our list elements look like lists. Starting with our unordered list (

<ul class="list-disc list-inside my-5 pl-2">

Here's what we're adding:

list-disc: set the list-style-stype to disc (the markers on each line item)
list-inside: sets the position of the list markers using relative to the list items and the list itself with list-style-position to inside
my-5: set the margin of the y axis to 5rem
pl-2: set the left padding to 2rem

Then we can apply the exact same classes to our ordered list (

list-disc

list-decimal

<ol class="list-decimal list-inside my-5 pl-2">

And we have our lists!

HTML page with styled lists

Finally, let's make our content a little easier to read by setting a max width and centering the content. On the tag, add the following:

<body class="max-w-4xl mx-auto">

/Note: Typically you wouldn't want to apply these classes to the itself, rather, you can wrap all of your content with a

tag, but since we're just trying to get an idea of how this works, we'll roll with this. Feel free to add the

tag with those classes instead if you prefer!/

And with that, we have our page!

HTML page with centered content

Follow along with the commit!

Step 4: Adding a button and other components

For the last part of our static example, let's add a button.

The trick with Tailwind, is they intentionally don't provide pre-baked component classes with the idea being that likely people would need to override these components anyways to make them look how they wanted.

So that means, we're going to have to create our own using the utility classes!

First, let's add a new button. Somewhere on the page, add the following snippet. I'm going to add it right below the first paragraph (

) tag:

<button>Party with Slurm!button>

HTML page with unstyled button

You'll notice just like all of the other elements, that it's unstyled, however, if you try clicking it, you'll notice it still has the click actions. So let's make it look like a button.

Let's add the following classes:

<button class="text-white font-bold bg-purple-700 hover:bg-purple-800 py-2 px-4 rounded">
  Party with Slurm!
button>

Here's a breakdown of what's happening:

text-white: we're setting our text color to white
font-bold: set the weight of the text to bold (font-weight)
bg-purple-700: set the background color of the button to purple with a shade of 700. The 700 is relative to the other colors defined as purple, you can find these values on their palette documentation page
hover:bg-purple-800: when someone hovers over the button, set the background color to purple shade 800. Tailwind provides these helper classes that allow us to easily define interactive stiles with things like hover, focus, and active modifiers
py-2: set the padding of the y-axis to 2rem
px-4: set the padding of the x-axis to 4rem
rounded: round the corners of the element by setting the border radius. With tailwind, it sets the border-radius value to .25rem

And with all of that, we have our button!

HTML page with a styled button

You can apply this methodology to any other component that you'd like to build. Though it's a manual process, we'll find out how we can make this process easier when building in more dynamic projects like those based on React.

Follow along with the commit!

Part 2: Adding Tailwind CSS to a React app

For more of a real-world use case, we're going to add Tailwind CSS to an app created with Create React App.

First, we'll walk through the steps you need to take to add tailwind to your project using a fresh install of Create React App, then we'll use our content from our last example to recreate it in React.

Step 1: Spinning up a new React app

I'm not going to detail this step out too much. The gist is we'll bootstrap a new React app using Create React App.

To get started, you can follow along with the directions from the official React documentation:

https://reactjs.org/docs/create-a-new-react-app.html

And once you start your development server, you should now see an app!

Create React App starting page

Finally, let's migrate all of our old content to our app. To do this, copy everything inside of the tag of our static example and paste it inside of the wrapper

in the new React project.

Migrating code to React app

Next, change all class=" attributes from the content we pasted in to className=" so that it's using proper React attributes:

Fixing class attribute in content

And lastly, replace the className App on our wrapper

to the classes we used on our static .

Adding wrapper styles to the app

Once you save your changes and spin back up your server, it will look deceivingly okay.

React app with basic content

React includes some basic styles itself, so while it looks okay, we're not actually using Tailwind yet. So let's get started by installing it!

Follow along with the commit!

Step 2: Installing Tailwind in your React app

There are a few steps we'll need to go through in order to get Tailwind up and running on our app. Make sure you follow these steps carefully to ensure it's properly configured.

First, let's add our dependencies:

yarn add tailwindcss postcss-cli autoprefixer
# or
npm install tailwindcss postcss-cli autoprefixer

Per Tailwind's documentation, we need to be able to process our styles so that they can be properly added to our pipeline. So in the above, we're adding:

tailwindcss: the core Tailwind package
postcss-cli: Create React App already uses postcss, but we need to configure Tailwind to be part of that build process and run it's own processing
autoprefixer: Tailwind doesn't include vendor prefixes, so we want to add autoprefixer to handle this for us. This runs as part of our postcss configuration

We're also going to add two dev dependencies that make it easier to work with our code:

yarn add concurrently chokidar-cli -D
# or
npm install concurrently chokidar-cli --save-dev

concurrently: a package that lets us set up the ability to run multiple commands at once. This is helpful since we'll need to watch both the styles and React app itself.
chokidar-cli: let's us watch files and run a command when changed. We'll use this to watch our CSS file and run the build process of the CSS on cahnge

Next, let's configure postcss, so create a new file in the root of your project called postcss.config.js and include the following:

// Inside postcss.config.js
module.exports = {
    plugins: [
        require('tailwindcss'),
        require('autoprefixer')
    ],
};

This will add the Tailwindcss and Autoprefixer plugins to our postcss config.

With our configuration, we need to include it as part of the build and watch processes. Inside package.json, add the following to definitions to your scripts property:

"build:css": "tailwind build src/App.css -o src/index.css",
"watch:css": "chokidar 'src/App.css' -c 'npm run build:css'",

Additionally, modify the start and build scripts to now include those commands:

"start": "concurrently -n Tailwind,React 'npm run watch:css' 'react-scripts start'",
"build": "npm run build:css && react-scripts build",

With our configuration ready to go, let's try our styles back to where they were when we left off from the static example.

Inside the App.css file, replace the entire content with:

@tailwind base;
@tailwind components;
@tailwind utilities;

This is going to import Tailwind's base styles, components, and utility classes that allow Tailwind to work as you would expect it to.

We can also remove the App.css import from our App.js file because it's now getting injected directly into our index.css file. So remove this line:

import './App.css';

Once you're done, you can start back up your development server! If it was already started, make sure to restart it so all of the configuration changes take effect.

And now the page should look exactly like it did in our static example!

React app with content styled

Follow along with the commit!

Step 3: Creating a new button component class with Tailwind

Tailwind doesn't ship with prebaked component classes, but it does make it easy to create them!

We're going to use our button that we already created as an example of creating a new component. We'll create a new class btn as well as a color modifier btn-purple to accomplish this.

The first thing we'll want to do is open up our App.css file where we'll create our new class. Inside that file, let's add:

.btn {
  @apply font-bold py-2 px-4 rounded;
}

If you remember from our HTML, we're already including those same classes to our

How to Use Pure CSS to Create a Beautiful Loading Animation for your App

Colby Fayock — Tue, 05 May 2020 14:45:00 +0000

If you've been around the internet lately, you've most likely seen a nice subtle loading animation that fills page content before gracefully loading in.

Some of the social giants like Facebook even use this approach to give page loading a better experience. How can we do that with just some simple CSS?

What are we going to build?
Just want the snippet?
Part 1: Creating our loading animation
Part 2: Using our loading animation in a dynamic app

What are we going to build?

We're going to create a loading animation using a CSS class that you can apply to pretty much any element you want (within reason).

Loading animation preview

This gives you great flexibility to use it and makes the solution nice and simple with only CSS.

While the snippet is pretty small and you could just copy and paste it, I'll walk you through what's happening and an example of using it dynamically when loading data.

Just want the snippet?

You can grab it here!

Do I need to know how to animate before this tutorial?

No! We'll walk through in detail exactly what you need to do. In fact, the animation in this tutorial is relatively simple, so let's dig in!

Part 1: Creating our loading animation

This first part is going to focus on getting the loading animation together and seeing it on a static HTML website. The goal is to walk through actually creating the snippet. We'll only use HTML and CSS for this part.

Step 1: Creating some sample content

To get started, we'll want a little sample content. There's really no restrictions here, you can create this with basic HTML and CSS or you can add this to your Create React App!

For the walk through, I'm going to use HTML and CSS with a few examples of content that will allow us to see this in effect.

To get started, create a new HTML file. Inside that HTML file, fill it with some content that will give us the ability to play with our animation. I'm going to use fillerama which uses lines from my favorite TV show Futurama!

Static HTML & CSS webpage with content from fillerama.io

If you're going to follow along with me, here's what my project looks like:

my-css-loading-animation-static
- index.html
- main.css

Follow along with the commit!

Step 2: Starting with a foundation loading class

For our foundation, let's create a new CSS class. Inside our CSS file, let's add:

.loading {
  background: #eceff1;
}

With that class, let's add it to a few or all of our elements. I added it to a few paragraphs, headings, and lists.

<p class="loading">For example...

Static HTML & CSS webpage with a gray background for the content

That gives us a basic background, but we'd probably want to hide that text. When it's loading, we won't have that text yet, so most likely we would want to use filler text or a fixed height. Either way, we can set the color to transparent:

.loading {
  color: transparent;
  background: #eceff1;
}

Static HTML & CSS webpage with a gray background and transparent color for the content

If you notice with list elements, whether you apply the class to the top level list element (

), it looks like one big block. If we add a little margin to the bottom of all list elements, we can see a different in how they display:
```
li {
  margin-bottom: .5em;
}
```
Style difference between applying to the top level list or the list items

And now it's starting to come together, but it kind of just looks like placeholders. So let's animate this to look like it's actually loading.

Follow along with the commit!

Step 3: Styling and animating our loading class

Before actually animating our class, we need something to animate, so let's add a gradient to our .loading class:
```
.loading {
  color: transparent;
  background: linear-gradient(100deg, #eceff1 30%, #f6f7f8 50%, #eceff1 70%);
}
```
This is saying that we want a linear gradient that's tilted at 100 degrees, where we start with #eceff1 and fade to #f6f7f8 at 30% and back to #eceff1 at 70%;

Subtle gradient background that might look like a glare

It's hard to see initially when it's still, it might just look like a glare on your computer! If you'd like to see it before moving on, feel free to play with the colors above to see the gradient.

Now that we have something to animate, we'll first need to create a keyframes rule:
```
@keyframes loading {
  0% {
    background-position: 100% 50%;
  }
  100% {
    background-position: 0 50%;
  }
}
```
This rule when applied will change the background position from starting at 100% of the x-axis to 0% of the x-axis.

With the rule, we can add our animation property to our .loading class:
```
.loading {
  color: transparent;
  background: linear-gradient(100deg, #eceff1 30%, #f6f7f8 50%, #eceff1 70%);
  animation: loading 1.2s ease-in-out infinite;
}
```
Our animation line is setting the keyframe to loading, telling it to last for 1.2 seconds, setting the timing function to ease-in-out to make it smooth, and tell it to loop forever with infinite.

No change – it's not animating

If you notice though after saving that, it's still not doing anything. The reason for this is we're setting our gradient from one end of the DOM element to the other, so there's nowhere to move!

So let's try also setting a background-size on our .loading class.
```
.loading {
  color: transparent;
  background: linear-gradient(100deg, #eceff1 30%, #f6f7f8 50%, #eceff1 70%);
  background-size: 400%;
  animation: loading 1.2s ease-in-out infinite;
}
```
Now, since our background expands beyond our DOM element (you can't see that part), it has some space to animate with and we get our animation!

Our loading animation!

Follow along with the commit!

Part 2: Using our loading animation in a dynamic app

Now that we have our loading animation, let's put it into action with a basic example where we fake a loading state.

The trick with actually using this is typically we don't have the actual content available, so in most cases, we have to fake it.

To show you how we can do this, we're going to build a simple React app with Next.js.

Step 1: Creating an example React app with Next.js

Navigate to the directory you want to create your new project in and run:
```
yarn create next-app
# or
npm init next-app
```
It will prompt you with some options, particularly a name which will determine the directory the project is created in and the type of project. I'm using my-css-loading-animation-dynamic and the "Default Starter App".

Creating a new project with Next.js

Once installed, navigate into your new directory and start up your development server:
```
cd [directory]
yarn dev
# or 
npm run dev
```
Starting development server with Next.js

Next, let's replace the content in our pages/index.js file. I'm going to derive the content from the previous example, but we'll create it similar to how we might expect it to come from an API. First, let's add our content as an object above our return statement:
```
const content = {
  header: `So, how 'bout them Knicks?`,
  intro: `What are their names? I'm Santa Claus! This opera's as lousy as it is brilliant! Your lyrics lack subtlety. You can't just have your characters announce how they feel. That makes me feel angry! Good news, everyone! I've taught the toaster to feel love!`,
  list: [
    `Yes! In your face, Gandhi!`,
    `So I really am important? How I feel when I'm drunk is correct?`,
    `Who are those horrible orange men?`
  ]
}
```
To display that content, inside
, let's replace the content with:
```
  <h1>{ content.header }h1>
  <p>{ content.intro }p>
  <ul>
    { content.list.map((item, i) => {
      return (
        <li key={i}>{ item }li>
      )
    })}
  ul>
```
And for the styles, you can copy and paste everything from our Part 1 main.css file into the

frontend - freeCodeCamp.org

The Front-End Monitoring Handbook: Track Performance, Errors, and User Behavior

Prerequisites

Table of Contents

Collect Performance Data

FP (First Paint)

FCP (First Contentful Paint)

LCP (Largest Contentful Paint)

CLS (Cumulative Layout Shift)

Cumulative

Average of All Session Windows

Maximum of All Session Windows

DOMContentLoaded and Load Events

First Screen Rendering Time

Monitoring DOM

Checking if Element is in First Screen

Using requestAnimationFrame() to Get DOM Rendering Time

Comparing with All Image Loading Times in First Screen

Optimization

API Request Timing

Resource Loading Time and Cache Hit Rate

Determining if Resource Hit Cache

Browser Back/Forward Cache (BFC)

FPS

Vue Router Change Rendering Time

Error Data Collection

Resource Loading Errors

{{ title }}

Server-side rendering process

What's the benefit of doing this? It's a faster time-to-content.

4. Use a CDN for Static Resources

CDN Principles

5. Place CSS in the Head and JavaScript Files at the Bottom

6. Use Font Icons (iconfont) Instead of Image Icons

Compress Font Files

7. Make Good Use of Caching, Avoid Reloading the Same Resources

How to implement caching and cache-busting:

8. Compress Files

9. Image Optimization

1. Lazy Loading Images

2. Responsive Images

3. Adjust Image Size

4. Reduce Image Quality

5. Use CSS3 Effects Instead of Images When Possible

6. Use WebP to Format Images

10. Load Code on Demand Through Webpack, Extract Third-Party Libraries, Reduce Redundant Code When Converting ES6 to ES5

Generate File Names Based on File Content, Combined with Import Dynamic Import of Components to Achieve On-Demand Loading

Extract Third-Party Libraries

Reduce Redundant Code When Converting ES6 to ES5

11. Reduce Reflows and Repaints

Browser Rendering Process

Reflow

Repaint

12. Use Event Delegation

13. Pay Attention to Program Locality

Locality usually takes two different forms:

Temporal locality example:

Spatial locality example:

Performance Testing

14. if-else vs switch

Why switch is better for multiple conditions:

15. Lookup Tables

Why lookup tables are better for many conditions:

When to use each approach:

16. Avoid Page Stuttering

60fps and Device Refresh Rate

17. Use requestAnimationFrame to Implement Visual Changes

18. Use Web Workers

19. Use Bitwise Operations

Modulo

Floor

Bitmask

20. Don't Override Native Methods

Example: String Replacement (Native vs. Custom)

When to Use Custom Code

21. Reduce the Complexity of CSS Selectors

1. When browsers read selectors, they follow the principle of reading from right to left.

2. CSS selector priority

22. Use Flexbox Instead of Earlier Layout Models

23. Use Transform and Opacity Properties to Implement Animations

Using `requestAnimationFrame()` to Get DOM Rendering Time

17. Use `requestAnimationFrame` to Implement Visual Changes

Postsh1>
{posts.map((post) => (
{post.title}
))}

Use `rem` Units for Responsive Typography

How to Build a Modal Using the `dialog` Tag

`show()` and `showModal()`