Deploy a Static Page in Under a Second

Deploy a plain HTML page with Vercel and compare artifact and build timings.

Introduction

30 Second Summary

Waiting for a simple page to go online can feel wasteful when the page is already finished. A tiny change should be live as quickly as you can refresh it.

In this project, you will deploy a static HTML page with the Vercel CLI. You will compare its sub-second artifact path with a normal build to discover exactly where the shortcut stops applying.

What You'll Build

You will open a live page from the URL printed in your terminal after watching the first deployment land in under a second.

By the end of this project, you'll have:

A live static page you can open from its public URL.
A recorded sub-second deployment measured from the timing printed by the CLI.
A side-by-side comparison of the fast deployment timing and the normal build timing. The Vercel dashboard confirms which deployment has no build log.
Secret Mission: A bonus challenge where you apply the same deployment ideas independently.

Before We Start

A deployment cannot start if your computer cannot reach the service. A missing runtime stops the command line before it can upload anything.

Node.js provides the runtime for the deployment tool. npm provides its package installer.

Your browser connects you to Vercel. Your account gives each deployment a home.

In this step, get ready to:

Open your terminal.
Verify Node.js from your terminal.
Prepare your Vercel account in your browser.

Open your terminal

Your terminal is where you run the deployment commands later. Opening it now gives you a place to check the tools already available on your computer.

Press Cmd+Space on macOS or the Windows key on Windows to open your search bar.
Type terminal into the search field.
Select the terminal application from the results.

You'll see a window with a command prompt. That prompt is ready to accept the checks in the next substep.

Verify Node.js and npm

The deployment tool depends on Node.js. Its installer also uses npm to add packages to your computer.

Before you run the check, picture whether your terminal prints two version numbers or reports a missing command.

Check both tools by running these commands:

node --version
npm --version

What do these commands check?

The node --version command asks the installed Node.js executable to print its version.
The npm --version command confirms that the package manager is available.

✔️ I see two version numbers

You're set. Your terminal can reach Node.js and npm successfully.

ⓧ A command is not found

Install the LTS release of Node.js from its official download page. The installer includes the runtime required for this project.

Visit the official Node.js download page.
Download the LTS installer for your operating system.

The installer may ask for permission to make changes. It also presents a short setup wizard.

Run the downloaded installer.
Keep the default option for each setup screen.
Approve the operating system permission request if one appears.

The installation can take a few minutes while it copies the runtime. A short pause during this process is expected.

Close every terminal window after the installation finishes.
Reopen your terminal through your computer's search bar.
Repeat both version checks shown above.

You'll see one Node.js version number followed by one npm version number.

Still missing a version number?

A terminal opened before the installation may still use the old system path. Close every terminal window before trying the checks again.

If the problem continues, help me restore access to Node.js and npm after installation.

Prepare your Vercel account

Vercel handles account verification on its own pages. Your credentials stay outside this project.

✔️ I already have an account

Visit the Vercel website in your browser.
Use your existing sign-in option.
Complete the account verification prompt if one appears.

You'll see your Vercel dashboard. This confirms that your browser has internet access and your account is available.

ⓧ I need an account

Vercel supports account creation with an email address or a supported provider. Choose the route that matches an account you can access now.

Email address

Visit the Vercel sign-up page.
Select Continue with Email.
Enter an email address you can access.
Open the verification message from Vercel.
Enter the six-digit one-time password from that message.

You'll see your Vercel dashboard after the code is accepted.

Git provider

Your provider displays an authorization page before returning you to Vercel. This gives Vercel permission to use that provider as your login method.

Visit the Vercel sign-up page.
Choose the provider option for an account you already use.
Sign in to that provider if prompted.
Authorize Vercel on the provider's permission page.

You'll return to Vercel after authorization. Your dashboard confirms that the account is ready.

Why stop before the CLI?

This step prepares your account only. The Vercel CLI remains uninstalled.

It also remains unauthenticated until the next step. This keeps the setup sequence clear.

Before you refresh the page, picture whether Vercel keeps you inside the dashboard or returns you to account setup.

Refresh your Vercel browser tab.

You'll see the Vercel dashboard again. That's your setup complete: your account is ready to receive the deployments you create later.

Your setup is ready for the deployment work. Next, you'll install or update Vercel CLI to version 59.16.0 or later.

Install and Verify the Vercel CLI

An older Vercel CLI silently takes the normal build path. That would ruin the timing comparison at the heart of this project.

This step installs or updates the CLI to version 59.16.0 or later. You will also complete authentication with your available Vercel account.

In this step, get ready to:

Check your installed Vercel CLI version.
Install or update the CLI when needed.
Authenticate the CLI with your Vercel account.

Check the Vercel CLI version

The fast deployment path requires Vercel CLI version 59.16.0 or later. Checking first tells you whether the command is ready or needs attention.

Check for an installed Vercel CLI by running this command:

vercel --version

What does this command check?

The --version option asks the installed vercel command to print its release number. That number determines whether this project can reach the fast artifact path.

✔️ I see version 59.16.0 or higher

You're set. Your installed CLI includes the fast artifact deployment behavior used in this project.

ⓧ I see an older version

Your existing command works. It needs an update before the deployment comparison can produce the intended result.

Update the Vercel CLI globally through npm by running this command:

npm install --global vercel@latest

What does this command do?

The --global option makes the CLI available as the vercel command across your terminal. The vercel@latest package updates that command to the latest published release.

Having trouble updating the CLI?

If npm reports a permissions problem, use the same Node.js installation method that provided your existing global packages. Avoid changing system folder permissions to force the installation.

If the download stops, confirm your internet connection before running the installation command again.

Help me fix my Vercel CLI update.

ⓧ Command not found

The CLI is missing from your computer. A global npm installation makes the vercel command available for this project.

Install the latest Vercel CLI globally through npm by running this command:

npm install --global vercel@latest

What does this command do?

npm downloads the latest Vercel CLI package. The global installation exposes its vercel command throughout your terminal.

Installation not completing?

If npm reports a permissions problem, use the same Node.js installation method that provided npm. Avoid changing system folder permissions to force the installation.

If the download stops, confirm your internet connection before running the installation command again.

Help me install the Vercel CLI.

Before you check again, do you expect your CLI to meet the minimum version for the fast path?

Print the installed version again by running this command:

vercel --version

Why check the version again?

This second check reads the command that your terminal can now access. It proves that the installation or update produced the required CLI version.

You should see version 59.16.0 or later. That confirms your deploys can use the fast artifact path when the folder meets its limits.

Still seeing the wrong version?

Close your current terminal session before starting a new one. Run the version check again so the new session can find the updated command.

If the old version remains, rerun the npm installation command and review its output for a permissions or network problem.

Help me find why my Vercel CLI version did not update.

Authenticate the Vercel CLI

The CLI needs permission to deploy into your Vercel account. The login flow connects this terminal to the account you already have.

This step moves from the terminal to your browser for authentication. Return to the terminal when the browser confirms that sign-in is complete.

Start the Vercel sign-in flow by running this command:

vercel login

What does this command do?

The vercel login command starts the account authentication flow. The terminal provides the next step for completing sign-in with your Vercel account.

Follow the authentication instruction shown in your terminal.
Complete the browser sign-in with your available Vercel account.
Return to your terminal after the browser confirms the connection.

Before you confirm the account, which Vercel identity do you expect the CLI to report?

Confirm the authenticated account by running this command:

vercel whoami

What does this command prove?

The vercel whoami command asks the CLI to identify its authenticated user. A reported account confirms that future deployment commands can reach Vercel.

You should see the identity associated with your Vercel account. Your current CLI is now installed and connected to the account that will receive your deployments.

Account not confirmed?

Rerun the login command if the browser flow expired before you completed it. Finish the new browser flow before returning to the terminal.

Confirm that the browser uses the Vercel account available for this project.

Help me complete Vercel CLI authentication.

✔️ Awesome, I've got everything!

Your Vercel CLI meets the minimum version. Your terminal is authenticated with your Vercel account.

ⓧ I'd like to double check the full code

This setup is complete when the Vercel CLI is installed and authenticated with your Vercel account. The vercel --version command must report version 59.16.0 or later.

The vercel whoami command must print the identity connected to your available Vercel account.

Your deployment tool is current and connected. Next, you will create a small static page that can qualify for the fast artifact path.

Create a Small Static Site

The next Vercel deployment only proves the fast path when its source folder fits the static limits. A large folder would hide the behavior you are trying to measure.

In this step, you will create three plain HTML pages inside static-page. You will open index.html directly from disk to prove the site works before deployment.

In this step, get ready to:

Create the static-page folder with three page files.
Write a valid plain HTML document in each file.
Prove the folder meets the size limit through local rendering.

Create the site files

A static site can live entirely in browser-readable files. Keeping those files together gives the next deployment one clear source folder.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type the name of your plain-text editor into the search bar.
Press Enter to open the editor.

Your text editor opens with an empty workspace where you can create the site files.

Start a blank document using the new-file control in your editor's top menu.
Open the save dialog using your editor's top menu.

The save dialog lets you choose the exact location for your site folder.

Create a folder named static-page on your Desktop using the folder control in the save dialog.
Save the current blank document as index.html inside static-page.

Your editor now shows index.html as the current file. The Desktop now contains the static-page folder.

Start another blank document using the new-file control.
Save the new document as about.html inside static-page.

The folder now contains index.html plus about.html.

Start one more blank document using the new-file control.
Save the new document as contact.html inside static-page.

The site folder now holds all three required page files.

Seeing the wrong file type?

Switch the document format to plain text in your editor.
Save each file with its exact .html filename.

Ask for help if your editor keeps adding another extension: help me save plain HTML files without an extra file extension

Write the three pages

A browser reads plain HTML directly from each file. Every page needs a document title plus visible body content.

Switch back to the index.html tab in your editor.
Write a complete plain HTML document that uses Static Page for its browser title plus its visible heading.
Save index.html.

Before you open the file, do you expect the browser to need a web server?

macOS

Press Cmd+Space to open Spotlight.
Type Finder into Spotlight.
Press Enter to open Finder.
Select Desktop in the Finder sidebar.
Double-click the static-page folder.
Double-click index.html to open it in your browser.

Windows

Press the Windows key to open search.
Type File Explorer into search.
Press Enter to open File Explorer.
Select Desktop in the File Explorer sidebar.
Double-click the static-page folder.
Double-click index.html to open it in your browser.

That first page is working: your browser renders the Static Page heading straight from disk. The address bar points to a file on your computer.

Why does this work without a server?

The browser reads plain HTML itself. A local file therefore needs no running server.

This local check isolates the page from deployment. You now know any later difference comes from the deployment path.

Page showing the wrong content?

Check that the filename ends with .html instead of an extra text-file extension.
Check that index.html contains a complete HTML document.

Ask for help if the browser cannot render the page: help me troubleshoot why index.html does not render from disk

Switch back to your text editor.
Select the about.html tab.
Write a complete plain HTML document that uses About for its browser title plus its visible heading.
Save about.html.
Return to the static-page folder in the file browser from earlier.
Double-click about.html to open it in your browser.

You will see the About heading. This confirms the first supporting page renders from disk.

Switch back to your text editor.
Select the contact.html tab.
Write a complete plain HTML document that uses Contact for its browser title plus its visible heading.
Save contact.html.
Return to the static-page folder in the file browser from earlier.
Double-click contact.html to open it in your browser.

You will see the Contact heading. All three pages now render directly from disk.

Check the site locally

The deployment comparison needs this folder to stay below 5 MB. Three text-only pages should leave plenty of room.

Before you check the folder, how close do you think three plain HTML files are to the size limit?

macOS

Return to Finder from earlier.
Select the static-page folder on your Desktop.
Click File in the top menu bar.
Select Get Info.
Confirm the displayed folder size is less than 5 MB.

Windows

Return to File Explorer from earlier.
Select Desktop in the sidebar.
Right-click the static-page folder.
Select Properties.
Confirm the displayed folder size is less than 5 MB.

You will see a folder size comfortably below 5 MB. The site fits the small-folder requirement for the next deployment.

Before you reopen the landing page, do you expect it to render without any terminal process running?

Return to the static-page folder in your file browser.
Double-click index.html to open it directly from disk.

Your browser shows the Static Page heading. The local proof is complete because the page rendered without deployment.

✔️ Awesome, I've got everything!

Your three HTML files are saved inside static-page. The folder is ready for deployment.

ⓧ I'd like to double check the full code

These are the required file states for this step.

The local static-page folder contains index.html, about.html, plus contact.html.
The index.html file is a plain HTML landing page.
The about.html file is a plain HTML supporting page.
The contact.html file is a plain HTML supporting page.
The total folder size is less than 5 MB.
The index.html page renders successfully when opened directly from disk.

Your local site is small enough for the artifact path. Next, you will deploy this exact folder to a live production URL.

Deploy on the Fast Path

Your plain HTML site already works from disk. A local file can only be viewed on your computer.

Now you'll publish that same folder with Vercel. Because the folder contains only three small HTML files, the CLI can upload it as an artifact without running a build.

In this step, get ready to:

Deploy the existing static-page folder to Vercel production.
Record the elapsed time from the CLI output.
Open the production URL in your browser.

Deploy and capture the timing

The deployment command inspects the current folder before choosing a path. Your existing three-file site qualifies for direct artifact upload.

Return to the terminal from earlier.
Select your authenticated Vercel account if the CLI asks you to choose an account.
Create a new project for static-page if the CLI asks whether to link an existing project.
Accept the suggested settings if the CLI asks you to confirm the project configuration.

Before you run the deployment, predict whether the terminal output includes a build phase.

Move into your existing static-page folder and deploy it to production by running these commands:

cd [[STATIC_PAGE_PATH="path to your static-page folder"]]
vercel deploy --prod

What does this deployment do?

The first command points your terminal at the existing static-page folder.
The deployment command publishes the current folder.
The --prod flag targets the production environment.
Vercel recognizes the eligible folder as a static artifact.
Direct artifact upload removes the build phase.

You should see the deployment finish without a build phase.

The final readiness line reports the elapsed time. The output also prints a production URL.

Record the elapsed time shown in the final readiness line: your fast deployment time.
Record the production URL from the output: your first production URL.

That is the fast path working. Your static files are live with a measured deployment time.

Deployment not completing?

Confirm that your terminal is inside the existing static-page folder. Check that your internet connection is active before retrying.

You can ask for help diagnosing the failed Vercel deployment or share the output in the NextWork community.

Verify the production page

The production URL proves that the upload reached Vercel's public environment. Loading it also confirms that index.html became the live landing page.

Before you open the URL, predict whether the page will match the file you opened from disk.

Switch back to the browser from earlier.
Paste your first production URL into the address bar.
Press Enter to load the deployment.

You'll see the same landing page that rendered from disk. The address bar now shows your Vercel production URL.

Live page not loading?

Copy the production URL from the terminal output again.
Paste the complete URL into the browser address bar.
Refresh the page after the deployment has completed.

If the page still does not load, help me troubleshoot my Vercel production URL.

Your first production URL is live with its fast-path timing recorded. Next, you'll push the folder beyond the limit to trigger a normal build.

Exceed the Fast-Path Limit

Your under-limit site is already live through a fast artifact deployment. That first elapsed time is your baseline.

A fast path is useful only when you know where it ends. This experiment changes the folder's total size while keeping the other eligibility rules stable.

You will deploy the larger folder to production with the Vercel CLI. The second timing exposes the cost of returning to a normal build.

In this step, get ready to:

Add two HTML test files that push static-page above the fast-path size limit.
Create a second production deployment from the larger folder.
Record the normal-build elapsed time for comparison.

Push the folder past 5 MB

The fast path accepts up to 10 HTML or Markdown files with a total size of 5 MB or less. You will keep the file count at five while making two files large enough to cross the size boundary.

Switch back to the terminal you used for the first deployment.
Return to the static-page directory if your terminal is no longer inside it.
Create two test files containing a combined 6 MiB of data by running this command:

node -e "['limit-test-1.html', 'limit-test-2.html'].forEach(file => require('node:fs').writeFileSync(file, Buffer.alloc(3 * 1024 * 1024, 32))), console.log('Created 6 MiB across two HTML files')"

What does this command do?

This one-liner uses Node.js to create test files with a predictable size.

The -e option lets the node command evaluate the expression without creating a script file.
The Buffer.alloc() call supplies exactly 3 MiB of space characters to each file.
The writeFileSync() call saves both buffers as HTML files inside static-page.
The .html names keep the file type eligible while total size becomes the only crossed limit.

Confirm the terminal prints Created 6 MiB across two HTML files.
Keep limit-test-1.html inside the static-page directory.
Keep limit-test-2.html inside the static-page directory.

Your controlled test folder is ready. It now exceeds the size limit without crossing the file-count limit.

Files created in the wrong folder?

Check that your terminal prompt ends in static-page.
Return to the static-page directory from earlier if the files were created elsewhere.
Rerun the command to overwrite both test files with the expected size.

If the confirmation still does not appear, help me create the two large HTML test files.

Deploy the over-limit folder

The folder now differs from your baseline by one controlled variable: total size. Running the same production deployment command makes the comparison fair.

This creates another real production deployment. Your earlier deployment remains available at its unique URL.

Before you run the deployment, do you expect the CLI to finish on the artifact path?

Deploy the current static-page folder to production by running this command:

vercel deploy --prod

What does this command do?

The deploy subcommand sends the linked folder to Vercel.
The --prod option creates a production deployment.
Reusing the earlier deployment command isolates total folder size as the changed condition.

This time, you will see build activity in the command output before the deployment finishes. The final elapsed time should be longer than your baseline.

That is the boundary made visible. Your larger folder now has a normal-build production deployment.

Record the elapsed time shown at the end of the deployment here: your second deployment time.
Place your second deployment time beside the fast deployment time you recorded earlier.
Confirm the second deployment took longer than the first deployment.

Still seeing the fast artifact path?

Confirm both test files are inside the same static-page directory as index.html.
Confirm each test file has a size of 3 MiB in your file browser.
Return to the terminal inside static-page before rerunning the production deployment.

If Vercel still skips the build, help me check why my over-limit folder is using the fast path.

You now have two production deployments with recorded timings. Next, you will compare their logs in the Vercel dashboard.

Compare Deployment Logs

Your two production deployments are live with different elapsed times. Now you can move from a timing clue to dashboard evidence.

Timing alone cannot prove whether Vercel ran a build. The dashboard's build logs show the build history for each deployment.

In this step, get ready to:

Open both production deployments in the Vercel dashboard.
Compare the build evidence for the fast path against the normal path.
Record both timings beside the point where the fast path stopped applying.

Open both deployment pages

Telling these deployments apart is a little fiddly because their pages look almost identical. Creation order is the clearest marker.

The older deployment is the under-limit fast path. The newer deployment is the over-limit normal build.

Open the Vercel dashboard in your browser.
Select the team associated with your deployments from the team switcher.
Select the project that contains the two production deployments.
Click Deployments in the sidebar.
Locate the two production deployments from the previous steps.
Hold Cmd (macOS) or Ctrl (Windows) while clicking the older deployment to open it in a new tab.
Repeat the shortcut on the newer deployment to open it in another tab.

You should now have one deployment detail tab for the fast path. A second tab should show the normal build.

Can't find both deployments?

Check that the team switcher points to the account used by the Vercel CLI.
Clear any filters from the deployment list.

Help me find both production deployments in the Vercel dashboard.

Record the timing comparison

A useful comparison pairs speed with the condition that selected the deployment path. Your earlier notes already contain the two elapsed times.

Return to the notes where you recorded both elapsed times.
Place the fast-path elapsed time beside the normal-build elapsed time.
Record the size boundary as five megabytes.
Mark the fast deployment as at or below that boundary.
Mark the normal-build deployment as above that boundary.

You should now have both timings recorded side by side. Your notes should also show the folder-size boundary between the two deployment paths.

Compare the build evidence

The deployment pages reveal which path processed each folder. This evidence connects the timing difference to a specific deployment action.

Before you inspect the pages, which deployment do you expect to contain a build step?

Switch to the browser tab for the older fast-path deployment.
Scroll to Deployment Status.
Check whether the section offers Build Logs or a Building step.

You should find no build output to inspect. That absence confirms that the fast deployment skipped the build step.

Add No build log beside the fast-path timing in your notes.

Switch to the browser tab for the newer normal-build deployment.
Scroll to Deployment Details.
Expand Building to inspect the logs.

You should see a build step with log output. This confirms that the over-limit folder followed the normal build path.

Add Build step shown beside the normal-build timing in your notes.

What do the logs prove?

An elapsed time can change with network traffic or platform load. Build evidence answers whether a build happened.

The fast deployment has no build activity. The over-limit deployment records a build step after crossing the folder-size boundary.

Can't see the expected build evidence?

Verify that the older tab shows the earlier deployment timestamp.
Reload the newer deployment page if the build details have not loaded.

Help me compare the build evidence for my two Vercel deployments.

Compare the fast-path dashboard tab with its matching note.
Compare the normal-build dashboard tab with its matching note.

You should see no build for the fast deployment. You should see a Building step for the over-limit deployment.

That's the comparison complete. Your side-by-side notes now connect both elapsed times to the five-megabyte cutoff.

Secret mission

Diagnose the Deployment Path

Turn your two production deployments into a reusable diagnostic. Use the recorded timings plus the build-log evidence to explain why one used the fast artifact path while the other ran a normal build.

Clean Up Your Resources

Your local static-page folder costs nothing to keep. Your two Vercel deployments remain under your existing account plan. Decide whether to keep them both, remove the comparison deployment, or delete every project resource.

Resources you used:

The first production deployment of the under-limit plain HTML folder, including its live URL.
The second production deployment of the over-limit static-page folder, including its build logs.
The local static-page folder, including index.html, about.html, contact.html, and the additional files.

Keep everything running

No action is needed. Choose this option if you want to keep the live page available or repeat the deployment comparison.

Keep the fast production deployment live as the finished result of your project.
Keep the normal-build production deployment available for comparing its build logs.
Keep the static-page folder in its current location for future experiments.
Store both recorded timings with the folder-size limit where the fast path stopped applying.

Pause - I'll come back to this later

There is no local server to stop. Remove the normal-build comparison deployment if you only want to keep the fast production URL.

Removing the comparison deployment leaves your fast page online. Your recorded timing comparison remains available in your notes.

Return to the normal-build production deployment page that is already open in the Vercel dashboard.
Open the management controls for that deployment.
Select the deployment deletion action.
Confirm the deletion.
Return to the deployment list for the project.

You should no longer see the normal-build production deployment in the list. Your first production URL remains live.

Keep the first production URL with your recorded fast-path timing.
Keep the local static-page folder in its current location.

Delete - I don't want to use this again

Deleting both deployments stops the live URLs from working. Your recorded timings remain safe in your notes.

Remove the normal-build production deployment first.

Return to the normal-build production deployment page that is already open in the Vercel dashboard.
Open the management controls for that deployment.
Select the deployment deletion action.
Confirm the deletion.
Return to the deployment list for the project.

You should no longer see the normal-build production deployment in the list.

The fast deployment holds the live page you built. Remove it when you no longer need that URL.

Return to the fast production deployment page that is already open in the Vercel dashboard.
Open the management controls for that deployment.
Select the deployment deletion action.
Confirm the deletion.
Return to the deployment list for the project.

You should no longer see either production deployment in the list. Both live URLs should stop loading.

The local static-page folder contains the source pages plus the files that exceeded the fast-path limit. Remove the folder using the instructions for your operating system.

macOS

Press Cmd+Space to open macOS search.
Type Finder into the search field.
Press Enter to open Finder.
Navigate to the folder that contains static-page.
Select the static-page folder.
Move the selected folder to the Trash.
Empty the Trash to remove the folder permanently.
Return to the folder that previously contained static-page.

You should no longer see the static-page folder in Finder.

Windows

Press the Windows key to open Windows search.
Type File Explorer into the search field.
Press Enter to open File Explorer.
Navigate to the folder that contains static-page.
Select the static-page folder.
Move the selected folder to the Recycle Bin.
Empty the Recycle Bin to remove the folder permanently.
Return to the folder that previously contained static-page.

You should no longer see the static-page folder in File Explorer.

Nice Work!

Project complete. Your static HTML page is live at a production URL. You also proved where sub-second artifact deployment ends and a normal build begins.

You learned how to:

Published a live static page with the Vercel CLI. Its production URL remains ready to share.
Measured fast-path and normal-build timings side by side. You pinpointed the folder-size limit where artifact deployment stopped applying.
Compared deployment logs in the Vercel dashboard. You saw no build for the under-limit deployment. You saw a build step for the over-limit deployment.
Secret Mission: Extended the deployment experiment through an optional challenge to push your skills further.

Ready to quiz yourself?