DEV Community: Suni

SEO Summary

Suni — Fri, 07 Mar 2025 15:30:01 +0000

When developing a website, SEO considerations for dealing with Google, Twitter, Discord, and Telegram.

In Google SEO design, it is necessary to set the correct Favicon, Title, Description, Keywords, and Image alt attributes. In addition to these elements, it is also important to ensure that the website displays correct card information when shared on platforms like Twitter, Discord, and Telegram.

Development is often a hurried process, and details can easily be overlooked. Only by documenting these aspects can we avoid forgetting them.

The first point to mention is that SEO rankings are always tied to user traffic. What developers can do is to provide search engines with more accurate and clear content and data.

Updating information takes time to be processed and indexed. However, there are some tricks to accelerate this process. For example, you can update the sitemap in Google Search Console to prompt search engines to crawl your site more frequently.

1. The Important Favicon, Title, and Description

1.1 Favicon

<link rel="shortcut icon" href="path/to/favicon.ico" type="image/x-icon" />

In the Favicon settings, the shortcut and type fields can both be omitted in modern browsers.

<link rel="icon" href="/favicon.ico" />

The recommended priority for Favicon file types is as follows: ico > png > svg > gif. ICO files have good compatibility, but PNG files are smaller and more universal. SVG is convenient to use but may fail to parse in some cases. GIF is untested and rarely seen in use on websites.

Favicons can be set in multiple sizes to accommodate various devices, including the 180×180 pixel apple-touch-icon and the 512×512 pixel size for Android launch screens. The latest summary on this topic can be found in the article 《How to Favicon in 2025: Three files that fit most needs》.

57×57 pixels: For older iPhones and iPod Touch.

72×72 pixels: For iPad.

114×114 pixels: For retina display iPhones and iPod Touch.

144×144 pixels: For iPad 3.

Sometimes we don't need so many file sizes in HTML, but these files can also be used in PWA settings within the manifest.json. In this case, the larger sizes become necessary. For example, icons for mobile devices should be at least 64x64, and for iPads, they should be at least 128x128. Therefore, including an image larger than 180x180 is still important.

Note: When multiple icons are specified, the browser will directly use the first <link rel="icon" />. Therefore, the specific file you want to use should be placed in the first line.

1.2 Title, Description

Currently, the importance of Keywords has diminished significantly. In practice, there is no observed correlation between the use of keywords and search engine rankings. There are no articles proving their effectiveness, while there are plenty of discussions suggesting that they are essentially useless.

On the other hand, Title and Description are the most critical pieces of information. They can be directly set in the head section of the HTML. However, each page requires unique content, which means static generation of different text for each page is necessary. To achieve this efficiently, you can leverage Next.js's Metadata feature to automatically set metadata for each page. This allows you to define a metadata object statically for each page.

export const metadata: Metadata = {
    title: 'xxx',
    description: 'xxx',
    keywords: 'xxx'
}

2. Adapting to Twitter/Discord/Telegram

Among these platforms, Twitter is the most complicated to set up. Let's start with the other two first.

2.1 Discord/Telegram

For Discord, when a link is sent in a message, it will immediately parse and display the link preview. However, Discord prioritizes Open Graph (OG) tags for the title and description. If you set og:title but do not set og:description, the description will show up as empty, even if you have set the <meta name="description"> tag. This is an area where Telegram performs better, as it has fallback handling for such cases.

Therefore, when setting the title and description, it is essential to update both parts simultaneously:

const title = 'xxx',
    description = 'xxx',
    keywords = 'xxx'

export const metadata: Metadata = {
    title,
    description,
    keywords,
    openGraph: {
        title,
        description
    }
}

Using Next.js to set openGraph has the added benefit that you don't need to worry about whether to use name or property when setting <meta /> tags.

Discord, TG, and Twitter all have caching issues. Since Discord and Telegram immediately parse the link in the message, it's easier to debug.

2.2 Debug

You can test links that have not been sent before to directly check if the added text has been updated.

If you need to view the same webpage, you can add a suffix ?v=1 to the page link, which will make it load as a new link.

Caching issues can also cause updates to different og:image files to fail, because the image is the same link. In this case, you can also add a suffix ?_=xxx to the link without changing the filename, and xxx can be continuously replaced with a new marker.

2.3 Twitter

Twitter does not use HTML + OG data; it requires its own specific meta tags in the format <meta name="twitter:xxx" content="xxx">. Additionally, you must specify twitter:card to determine the display size and style.

Note: For Twitter image settings, you cannot use relative paths like /cover.png; you must use an absolute path.

When loading Twitter-related meta information, it is prone to failure; if any information is incorrect, it may not load any of the meta data. Therefore, Twitter settings must be carefully and completely configured.

Twitter's twitter:title and twitter:description updates are relatively fast; you can see the new text within 30 seconds after setting them. Similarly, you can use the suffix update ?v=1 to debug whether the new settings have taken effect.

const title = 'xxx',
    description = 'xxx',
    keywords = 'xxx'

export const metadata: Metadata = {
    title,
    description,
    keywords,
    openGraph: {
        title,
        description
    },
    twitter: {
        title,
        description
    }
}

The image update on Twitter is relatively slow; it may take half a day or even several days to see the new image. Therefore, when setting images, it's important to optimize their size to avoid any issues with Twitter's image parsing.

If you set the type to summary, the actual display size will be around 120x120. Setting an image to 240x240 can meet the requirements for Discord, TG, and Twitter. By compressing the image size, you can reduce it to around 10KB.

Attention:
If there is an issue with the website data collection, you must visit https://cards-dev.x.com/validator to clear the cache (it does work). Otherwise, the new data for the same URL may not be updated for an extended period (perhaps indefinitely).

3. Unclear Things

What is <script type="application/ld+json">? I'm not entirely clear on its specific function yet, but I often see it mentioned in various articles. It seems to be used to explicitly indicate certain aspects of website content. The specific uses it can have still need further research.

Blog

Path Motion Methods

Suni — Fri, 07 Mar 2025 15:21:40 +0000

I collect several implementations of Path Motion and summarizing my own evaluations of them.

You can click on my blog to check the specific effect.

1. CSS

First, the first method is the CSS way.

Using offset-path, and employing animation to make offset-distance go from 0% to 100%.

offset-path: path('M179.43,103.86 ...');
animation: move 3000ms infinite ease-in-out;

2. SVG

The second, SVG

<path
    fill='none'
    stroke='lightgrey'
    d='M179.43,103.86 ...'
/>

<rect width="16" height="16" fill='rgb(75, 85, 99)'>
    <animateMotion
        dur='3s'
        rotate='auto'
        repeatCount='indefinite'
        path='M179.43,103.86 ...'
        calcMode='spline'
        keyTimes='0; 1'
        keySplines='0.5 0 0.5 1'
    />
</rect>

3. JS

The last is control through JavaScript code.

import { animate } from 'motion'
import { useEffect, useRef } from 'react'
import { getPointAtLength, getTotalLength } from 'svg-path-commander'

const d = 'M179.43,103.86 ... '
const pathLength = getTotalLength(d)

export default function JSMotion() {
    const ref = useRef<HTMLDivElement>(null)

    useEffect(() => {
        if (ref.current) {
            animate(0, 100, {
                repeat: Infinity,
                ease: 'easeInOut',
                onUpdate: latest => {
                    const currentLength = (latest / 100) * pathLength
                    const { x: currentX, y: currentY } = getPointAtLength(d, currentLength)
                    ref.current!.style.left = currentX + 'px'
                    ref.current!.style.top = currentY + 'px'

                    const { x: nextX, y: nextY } = getPointAtLength(d, currentLength + 1)
                    const dx = nextX - currentX
                    const dy = nextY - currentY
                    const angle = Math.atan2(dy, dx) * (180 / Math.PI) + 90

                    ref.current!.style.rotate = angle + 'deg'
                },
                duration: 3
            })
        }
    }, [ref.current])

    return (
        <div className=' relative w-full h-[400px] bg-gray-50 rounded border'>
            <div ref={ref} className='w-4 h-4 bg-gray-600 absolute'></div>
        </div>
    )
}

Experience

CSS is relatively simple and can be directly applied in a normal HTML environment. The SVG approach, however, relies on a stable SVG environment, where the size is scaled according to the SVG dimensions. Fine-tuning the easing effect requires using keySplines, which demands some careful adjustment.

The movement in CSS is similar to a relative offset effect. In contrast, SVG involves setting x and y values within the SVG environment.

For JavaScript, the implementation depends on an animate library, a path utility library (svg-path-commander), and some calculations.

For simple loop animations or single-play animations, CSS is more convenient and efficient. SVG can quickly scale according to the page size.

JavaScript, on the other hand, can orchestrate multiple playback logics and is suitable for complex animations.

Excellent JSON View component. Everyone should give it a try.

Suni — Wed, 23 Aug 2023 13:54:20 +0000

https://github.com/YYsuni/react18-json-view

Fresh and good-looking, this simple structure supports all types.

It allows for editing, adding, deleting, copying, and corresponding events. Bug reports are welcome.

Canary Version Management

Suni — Thu, 13 Jul 2023 17:15:05 +0000

Canary Versions of Next.js

While looking at the next.js repository, I noticed that it doesn't have a main/master branch, however, it has a canary branch instead. There are many canary versions between tags. This caught my interest.

By observation, PRs in Next.js will use Squash and Merge and delete the merged branch. The new version will start from xxx-canary.0, and after some testing fixes, it will be released as an official version number. I am unsure of the change period and what the criteria are for next.js to publish an official version.

In the versions I used to manage, adding new features would result in an updated patch version. However, when issues were discovered and fixed, another patch version would need to be released immediately. This version was intended only to fix issues in the previous version. Unfortunately, this casual practice has resulted in some unusable versions.

MAJOR.MINOR.PATCH

The canary stage can significantly improve the problem. It also serves as a reminder not to casually release a new version number. Sufficient time and testing are required before doing so.

How to publish a canary version:

npm publish --tag canary

Origin of the Canary

The practice of using canaries as an early detection system for toxic gases originated from coal miners.

In 1911, British miners introduced canaries into mines. These birds are highly sensitive to carbon monoxide, and even a small amount of leakage can cause them to become restless, chirp, or die. When the canaries display these symptoms, miners know that there is dangerous gas in the mine and they must evacuate.

Over time, the term "canary" has come to represent the early detection and feedback of software.

Practice

In the new version of my react18-json-view, I have adopted the new approach. A version now starts as a canary version and, after a certain number of canary versions, it is replaced by an official version.

Versioning Specification

Semantic Versioning 2.0.0

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes

MINOR version when you add functionality in a backward compatible manner

PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

In my opinion, a minor version should be an accumulation of certain features from previous patches. Usually, the patch version number is still added even if some features are included. For example, consider the minor version change of next.js:

String + or Literals Template

Suni — Tue, 11 Jul 2023 16:03:22 +0000

Today, I saw a PR for Next.js that changed the path joined operation to string concatenation. I usually use template literals when concatenating strings, but this operation makes me feel that its effect may be better. Let's test it out.

import { join } from 'path'
const absolutePath = join(dir, part.name)
// =>
import { sep } from 'path'
const absolutePath = dir + sep + part.name

Test

Device Information:

AMD Ryzen 5 5600X 6-Core Processor 3.70 GHz.

16.0 GB

node v18.12.1

const loopTimes = 10 ** 3

console.log('loop times:', loopTimes)
for (let j = 0; j < 10; j++) {
    {
        console.time('Template Literals')

        for (let i = 0; i < loopTimes; i++) {
            const string = `2920581597${'9755748451'}6731841261${'4148087606'}`
        }

        console.timeEnd('Template Literals')
    }

    {
        console.time('String Operation')

        for (let i = 0; i < loopTimes; i++) {
            const string = '7470435977' + '5509065748' + '8216834146' + '2266350600'
        }

        console.timeEnd('String Operation')
    }
}

Loop 10 ** 3 times

$ node literals.js
loop times: 1000
Template Literals: 0.108ms
String Operation: 0.059ms
Template Literals: 0.048ms
String Operation: 0.057ms
Template Literals: 0.05ms
String Operation: 0.395ms
Template Literals: 0.184ms
String Operation: 0.052ms
Template Literals: 0.048ms
String Operation: 0.052ms
Template Literals: 0.044ms
String Operation: 0.048ms
Template Literals: 0.048ms
String Operation: 0.266ms
Template Literals: 0.018ms
String Operation: 0.024ms
Template Literals: 0.002ms
String Operation: 0.001ms
Template Literals: 0.002ms
String Operation: 0.002ms

Loop 10 ** 6 times

loop times: 1000000
Template Literals: 2.425ms
String Operation: 1.251ms
Template Literals: 2.349ms
String Operation: 0.325ms
Template Literals: 0.324ms
String Operation: 0.324ms
Template Literals: 0.324ms
String Operation: 0.432ms
Template Literals: 0.324ms
String Operation: 0.347ms
Template Literals: 0.324ms
String Operation: 0.325ms
Template Literals: 0.324ms
String Operation: 0.324ms
Template Literals: 0.324ms
String Operation: 0.327ms
Template Literals: 0.351ms
String Operation: 0.467ms
Template Literals: 0.467ms
String Operation: 0.353ms

Loop 10 ** 9 times

$ node literals.js
loop times: 1000000000
Template Literals: 327.606ms
String Operation: 326.944ms
Template Literals: 328.332ms
String Operation: 324.067ms
Template Literals: 324.459ms
String Operation: 326.348ms
Template Literals: 325.024ms
String Operation: 326.959ms
Template Literals: 325.483ms
String Operation: 325.172ms
Template Literals: 324.812ms
String Operation: 339.251ms
Template Literals: 325.533ms
String Operation: 325.951ms
Template Literals: 326.778ms
String Operation: 326.225ms
Template Literals: 325.101ms
String Operation: 327.872ms
Template Literals: 325.912ms
String Operation: 324.887ms

Loop 10 ** 9 times (chrome)

import debugBrowserImage from './debug-browser.png'
import Image from 'next/image'

Conclusion

There is no significant difference between the two.

Join vs. String Operation

const loopTimes = 10 ** 3
import { sep, join } from 'path'

console.log('loop times:', loopTimes)
for (let j = 0; j < 10; j++) {
    {
        console.time('Path Join')

        for (let i = 0; i < loopTimes; i++) {
            const absolutePath = join('2920581597', '6731841261', '4148087606')
        }

        console.timeEnd('Path Join')
    }

    {
        console.time('String Operation')

        for (let i = 0; i < loopTimes; i++) {
            const absolutePath = '7470435977' + sep + '5509065748' + sep + '8216834146' + sep + '2266350600'
        }

        console.timeEnd('String Operation')
    }
}

Loop 10 ** 3 times

$ node literals-join.js
loop times: 1000
Path Join: 2.878ms
String Operation: 0.115ms
Path Join: 0.757ms
String Operation: 0.309ms
Path Join: 0.902ms
String Operation: 0.108ms
Path Join: 0.474ms
String Operation: 0.063ms
Path Join: 0.761ms
String Operation: 0.072ms
Path Join: 0.747ms
String Operation: 0.066ms
Path Join: 0.242ms
String Operation: 0.003ms
Path Join: 0.445ms
String Operation: 0.006ms
Path Join: 0.444ms
String Operation: 0.002ms
Path Join: 0.583ms
String Operation: 0.002ms

Loop 10 ** 6 times

$ node literals-join.js
loop times: 1000000
Path Join: 257.74ms
String Operation: 1.718ms
Path Join: 264.481ms
String Operation: 0.328ms
Path Join: 268.848ms
String Operation: 0.329ms
Path Join: 281.358ms
String Operation: 0.329ms
Path Join: 263.217ms
String Operation: 0.347ms
Path Join: 263.732ms
String Operation: 0.329ms
Path Join: 263.908ms
String Operation: 0.327ms
Path Join: 263.112ms
String Operation: 0.455ms
Path Join: 261.133ms
String Operation: 0.348ms
Path Join: 264.144ms
String Operation: 0.328ms

Loop 10 ** 7 times

$ node literals-join.js
loop times: 10000000
Path Join: 2.417s
String Operation: 4.615ms
Path Join: 2.560s
String Operation: 3.26ms
Path Join: 2.530s
String Operation: 3.253ms
Path Join: 2.521s
String Operation: 3.261ms
Path Join: 2.472s
String Operation: 3.304ms
Path Join: 2.461s
String Operation: 3.229ms
Path Join: 2.447s
String Operation: 3.255ms
Path Join: 2.440s
String Operation: 3.249ms
Path Join: 2.449s
String Operation: 3.228ms
Path Join: 2.472s
String Operation: 3.383ms

Conclusion

path.join does indeed take more time.

Resolve vs. String Operation

const loopTimes = 10 ** 7
import { sep, join, resolve } from 'path'

console.log('loop times:', loopTimes)
for (let j = 0; j < 10; j++) {
    {
        console.time('Path Resolve')

        for (let i = 0; i < loopTimes; i++) {
            const absolutePath = resolve('2920581597', '6731841261', '4148087606')
        }

        console.timeEnd('Path Resolve')
    }

    {
        console.time('String Operation')

        for (let i = 0; i < loopTimes; i++) {
            const absolutePath = '7470435977' + sep + '5509065748' + sep + '8216834146' + sep + '2266350600'
        }

        console.timeEnd('String Operation')
    }
}

Loop 10 ** 3 times

$ node literals-join.js
loop times: 1000
Path Resolve: 3.662ms
String Operation: 0.315ms
Path Resolve: 1.307ms
String Operation: 0.105ms
Path Resolve: 1.101ms
String Operation: 0.046ms
Path Resolve: 1.615ms
String Operation: 0.037ms
Path Resolve: 0.717ms
String Operation: 0.047ms
Path Resolve: 0.564ms
String Operation: 0.039ms
Path Resolve: 0.557ms
String Operation: 0.002ms
Path Resolve: 0.539ms
String Operation: 0.004ms
Path Resolve: 0.548ms
String Operation: 0.002ms
Path Resolve: 0.698ms
String Operation: 0.002ms

Loop 10 ** 6 times

$ node literals-join.js
loop times: 1000000
Path Resolve: 535.521ms
String Operation: 1.66ms
Path Resolve: 529.712ms
String Operation: 0.329ms
Path Resolve: 514.061ms
String Operation: 0.328ms
Path Resolve: 520.766ms
String Operation: 0.408ms
Path Resolve: 519.928ms
String Operation: 0.339ms
Path Resolve: 508.505ms
String Operation: 0.329ms
Path Resolve: 514.875ms
String Operation: 0.327ms
Path Resolve: 519.519ms
String Operation: 0.33ms
Path Resolve: 532.188ms
String Operation: 0.329ms
Path Resolve: 519.32ms
String Operation: 0.409ms

Loop 10 ** 7 times

$ node literals-join.js
loop times: 10000000
Path Resolve: 5.361s
String Operation: 4.812ms
Path Resolve: 5.148s
String Operation: 3.381ms
Path Resolve: 5.129s
String Operation: 3.279ms
Path Resolve: 5.053s
String Operation: 3.272ms
Path Resolve: 5.055s
String Operation: 3.259ms
Path Resolve: 4.994s
String Operation: 3.288ms
Path Resolve: 5.466s
String Operation: 3.28ms
Path Resolve: 5.010s
String Operation: 3.338ms
Path Resolve: 5.048s
String Operation: 3.279ms
Path Resolve: 5.086s
String Operation: 3.36ms

Conclusion

resolve takes twice as long as join.

Is startsWith Faster Than RegExp?

Suni — Tue, 04 Jul 2023 15:17:21 +0000

Today when writing conditional statements, I used String startsWith because I believed it would be the fastest way. Let me prove it!

Test

Device Information:

AMD Ryzen 5 5600X 6-Core Processor 3.70 GHz

16.0 GB

node v18.12.1

const loopTimes = 10 ** 2

console.log('loop times:', loopTimes)
for (let j = 0; j < 10; j++) {
    {
        console.time('startsWith')

        for (let i = 0; i < loopTimes; i++) {
            'Performance-Comparison-Regular-Expression-vs-StartsWith'.startsWith('Performance-Compa')
        }

        console.timeEnd('startsWith')
    }

    {
        console.time('reg')

        for (let i = 0; i < loopTimes; i++) {
            ;/^Performance-Compa/.test('Performance-Comparison-Regular-Expression-vs-StartsWith')
        }

        console.timeEnd('reg')
    }
}

Loop 10 ** 2 times

output:

$ node startsWith.js
loop times: 100
startsWith: 0.062ms
reg: 0.074ms
startsWith: 0.006ms
reg: 0.01ms
startsWith: 0.005ms
reg: 0.012ms
startsWith: 0.005ms
reg: 0.008ms
startsWith: 0.005ms
reg: 0.016ms
startsWith: 0.004ms
reg: 0.008ms
startsWith: 0.004ms
reg: 0.009ms
startsWith: 0.004ms
reg: 0.009ms
startsWith: 0.004ms
reg: 0.006ms
startsWith: 0.004ms
reg: 0.006ms

Loop 10 ** 3 times

$ node startsWith.js
loop times: 1000
startsWith: 0.086ms
reg: 0.148ms
startsWith: 0.033ms
reg: 0.08ms
startsWith: 0.113ms
reg: 0.077ms
startsWith: 0.048ms
reg: 0.063ms
startsWith: 0.032ms
reg: 0.072ms
startsWith: 0.027ms
reg: 0.065ms
startsWith: 0.03ms
reg: 0.065ms
startsWith: 0.026ms
reg: 0.065ms
startsWith: 0.03ms
reg: 0.062ms
startsWith: 0.036ms
reg: 0.459ms

Loop 10 ** 4 times

$ node startsWith.js
loop times: 10000
startsWith: 0.393ms
reg: 1.562ms
startsWith: 0.241ms
reg: 5.237ms
startsWith: 0.343ms
reg: 0.564ms
startsWith: 0.342ms
reg: 0.153ms
startsWith: 0.342ms
reg: 0.262ms
startsWith: 0.347ms
reg: 0.223ms
startsWith: 0.352ms
reg: 0.152ms
startsWith: 0.341ms
reg: 0.229ms
startsWith: 0.341ms
reg: 0.191ms
startsWith: 0.341ms
reg: 0.227ms

Loop 10 ** 5 times

$ node startsWith.js
loop times: 100000
startsWith: 5.24ms
reg: 4.092ms
startsWith: 6.891ms
reg: 1.875ms
startsWith: 3.795ms
reg: 1.794ms
startsWith: 3.414ms
reg: 1.943ms
startsWith: 3.408ms
reg: 2.265ms
startsWith: 3.472ms
reg: 1.938ms
startsWith: 4.231ms
reg: 1.762ms
startsWith: 3.602ms
reg: 1.791ms
startsWith: 3.639ms
reg: 2.002ms
startsWith: 3.435ms
reg: 1.768ms

Loop 10 ** 6 times

$ node startsWith.js
loop times: 1000000
startsWith: 36.477ms
reg: 20.72ms
startsWith: 39.39ms
reg: 17.669ms
startsWith: 34.748ms
reg: 17.519ms
startsWith: 35.174ms
reg: 17.366ms
startsWith: 35.09ms
reg: 17.527ms
startsWith: 34.822ms
reg: 17.597ms
startsWith: 34.615ms
reg: 17.87ms
startsWith: 35.453ms
reg: 17.855ms
startsWith: 35.786ms
reg: 17.613ms
startsWith: 34.706ms
reg: 17.6ms

Loop 10 ** 7 times

$ node startsWith.js
loop times: 10000000
startsWith: 355.577ms
reg: 180.706ms
startsWith: 354.726ms
reg: 180.558ms
startsWith: 347.955ms
reg: 175.675ms
startsWith: 348.327ms
reg: 174.522ms
startsWith: 346.228ms
reg: 175.619ms
startsWith: 347.943ms
reg: 175.331ms
startsWith: 346.146ms
reg: 177.439ms
startsWith: 349.308ms
reg: 175.06ms
startsWith: 347.434ms
reg: 175.234ms
startsWith: 348.574ms
reg: 175.179ms

Research

Things don't seem to have developed as expected. When the loop is increased to 10*4 times, the situation starts to reverse, and the consumption time of reg becomes shorter instead. By the time it reaches 10*7, there is a significant difference.

Shorter String

Change the code as follows:

'Suni123'.startsWith('Suni')
;/^Suni/.test('Suni123')

10 ** 7 loops, output

$ node startsWith.js
loop times: 10000000
startsWith: 94.856ms
reg: 164.667ms
startsWith: 92.53ms
reg: 159.685ms
startsWith: 86.074ms
reg: 158.927ms
startsWith: 84.894ms
reg: 159.14ms
startsWith: 91.335ms
reg: 166.805ms
startsWith: 85.942ms
reg: 159.383ms
startsWith: 84.433ms
reg: 159.253ms
startsWith: 85.166ms
reg: 161.083ms
startsWith: 85.391ms
reg: 158.424ms
startsWith: 85.856ms
reg: 161.31ms

At this point, startsWith is obviously faster.

Longer String

'Performance Comparison: Regular Expression vs. StartsWith; Performance Comparison: Regular Expression vs. StartsWith'.startsWith(
    'Performance Comparison: Regular Expression '
)
;/^Performance Comparison: Regular Expression /.test(
    'Performance Comparison: Regular Expression vs. StartsWith; Performance Comparison: Regular Expression vs. StartsWith'
)

output

$ node startsWith.js
loop times: 10000000
startsWith: 892.246ms
reg: 206.517ms
startsWith: 901.182ms
reg: 203.149ms
startsWith: 902.196ms
reg: 202.142ms
startsWith: 897.693ms
reg: 203.393ms
startsWith: 890.596ms
reg: 223.431ms
startsWith: 894.55ms
reg: 204.961ms
startsWith: 896.698ms
reg: 203.099ms
startsWith: 901.242ms
reg: 202.968ms
startsWith: 902.59ms
reg: 202.787ms
startsWith: 909.052ms
reg: 214.305ms

Long String, Short Condition

'Performance Comparison: Regular Expression vs. StartsWith; Performance Comparison: Regular Expression vs. StartsWith'.startsWith(
    'Performance'
)
;/^Performance/.test(
    'Performance Comparison: Regular Expression vs. StartsWith; Performance Comparison: Regular Expression vs. StartsWith'
)

$ node startsWith.js
loop times: 10000000
startsWith: 228.98ms
reg: 173.04ms
startsWith: 234.776ms
reg: 167.778ms
startsWith: 228.642ms
reg: 168.327ms
startsWith: 228.746ms
reg: 174.96ms
startsWith: 228.663ms
reg: 168.228ms
startsWith: 229.287ms
reg: 167.576ms
startsWith: 227.067ms
reg: 168.668ms
startsWith: 228.117ms
reg: 168.955ms
startsWith: 227.062ms
reg: 169.838ms
startsWith: 228.28ms
reg: 168.242ms

Long String, Long Condition

'Performance Comparison: Regular Expression vs. StartsWith; Performance Comparison: Regular Expression vs. StartsWith'.startsWith(
    'Performance Comparison: Regular Expression vs. StartsWith; Performance'
)
;/^Performance Comparison: Regular Expression vs. StartsWith; Performance/.test(
    'Performance Comparison: Regular Expression vs. StartsWith; Performance Comparison: Regular Expression vs. StartsWith'
)

$ node startsWith.js
loop times: 10000000
startsWith: 1.439s
reg: 237.275ms
startsWith: 1.432s
reg: 242.409ms
startsWith: 1.437s
reg: 238.463ms
startsWith: 1.425s
reg: 232.626ms
startsWith: 1.423s
reg: 234.199ms
startsWith: 1.426s
reg: 234.651ms
startsWith: 1.440s
reg: 235.122ms
startsWith: 1.429s
reg: 234.676ms
startsWith: 1.444s
reg: 234.071ms
startsWith: 1.439s
reg: 235.936ms

Reduce the Number of Loops

'Performance Comparison: Regular Expression vs. StartsWith; Performance Comparison: Regular Expression vs. StartsWith'.startsWith(
    'Performance Comparison: Regular Expression vs. StartsWith; Performance'
)
;/^Performance Comparison: Regular Expression vs. StartsWith; Performance/.test(
    'Performance Comparison: Regular Expression vs. StartsWith; Performance Comparison: Regular Expression vs. StartsWith'
)

output

$ node startsWith.js
loop times: 1000
startsWith: 0.114ms
reg: 0.159ms
startsWith: 0.061ms
reg: 0.08ms
startsWith: 0.138ms
reg: 0.064ms
startsWith: 0.056ms
reg: 0.059ms
startsWith: 0.059ms
reg: 0.071ms
startsWith: 0.059ms
reg: 0.064ms
startsWith: 0.058ms
reg: 0.062ms
startsWith: 0.056ms
reg: 0.069ms
startsWith: 0.058ms
reg: 0.062ms
startsWith: 0.143ms
reg: 0.431ms

10**4

$ node startsWith.js
loop times: 10000
startsWith: 0.735ms
reg: 1.016ms
startsWith: 0.674ms
reg: 3.743ms
startsWith: 1.498ms
reg: 0.575ms
startsWith: 1.404ms
reg: 0.211ms
startsWith: 1.408ms
reg: 0.313ms
startsWith: 1.425ms
reg: 0.28ms
startsWith: 1.727ms
reg: 0.337ms
startsWith: 1.724ms
reg: 0.303ms
startsWith: 1.404ms
reg: 0.21ms
startsWith: 1.408ms
reg: 0.282ms

Conclusion

When dealing with short string, it is better to use startsWith. For longer string, it is better to use regular expression. When handling a long string with a short condition, startsWith is still a good choice.

In daily development, when the number of operations is less than 10^3, it is better to use startsWith. This also improves readability. However, when the number of operations exceeds this magnitude and the condition string is long, using regular expression will have better performance.

How will the browser behave?

chrome v114.0.5735.199

Essentially the same as Node, it could lead to the same conclusions.

Other

During this test, I discovered that console.time can be used for timing, which is more convenient than using Date.now because it doesn't require recording the difference. It's a new discovery, haha ^o^.

console.clear can manually clear logs, console.assert can assert in the browser, console.trace can directly view the call stack, and console.count can be used to print the number of updates in a React FC. These are all quite useful.