Ta Thai™Loading / 000%
Code. Design. Ship.

Loading

Preparing a focused brutalist interface for projects, skills, writing, and product work.

HCMC, VNBooting portfolio
Back to Blog

Web Performance + 2026-06-06 + 15 min read

React and Next.js Web Performance: Core Web Vitals for Product-Focused Developers

A practical performance guide for React and Next.js developers covering Core Web Vitals, image optimization, JavaScript cost, rendering strategy, and product UX.

React and Next.js Web Performance: Core Web Vitals for Product-Focused Developers

React and Next.js Web Performance for Product-Focused Developers

Performance is not a final polish task. It is part of product quality. A slow portfolio, SaaS page, dashboard, or AI tool makes users wait before they trust the interface. For a developer portfolio, performance also becomes a hiring signal. A full-stack developer who claims to build high-performance applications should have a site that proves it.

React and Next.js give developers strong tools, but they do not guarantee fast pages automatically. Images can still be too large. Client JavaScript can still grow. Layout shifts can still happen. Animations can still block usability. Search metadata can still be correct while the user experience feels heavy.

Google's web.dev Core Web Vitals guidance is a practical starting point: focus on loading experience, interactivity, and visual stability. For a portfolio, this means the user should understand who you are quickly, browse projects without jank, and open blog posts without waiting for unnecessary JavaScript.

Performance starts with product decisions

Before optimizing code, ask what the page needs to do. A homepage needs fast identity, clear navigation, and immediate project signals. A blog page needs readable content, accessible typography, and fast images. A project case study needs screenshots, but those screenshots should not make the page feel broken.

Every decorative effect has a cost. That does not mean a site must be plain. Brutalist design can be visually strong and fast when it uses typography, borders, layout, and limited motion instead of heavy media. A portfolio can feel expressive without shipping a large animation engine to every route.

Performance should be evaluated against user intent. If a recruiter opens the site on a laptop, can they identify role, location, stack, and contact path in a few seconds? If a hiring manager opens a blog article, can they read it without layout shifts? If a founder opens a project page, can they understand the product before images finish loading?

Optimize images before anything else

Images are often the largest assets on a portfolio. Project screenshots, gallery photos, portraits, and hero images can improve credibility, but only if they are handled carefully.

In Next.js, use next/image when possible. Provide sizes, stable aspect ratios, and meaningful alt text. Avoid letting images define layout height after loading. If a card has a fixed image ratio, reserve that space. If a hero image is important, prioritize only that image, not every image on the page.

For blog posts, featured images should support the topic. A performance article can use a clean technical image. A Japan career article can use a city image. But avoid overly dark, blurred, or irrelevant stock-like images when the reader needs clarity.

Reduce client JavaScript

React applications can become slow when too much UI runs on the client. Next.js App Router helps by making server components the default, but developers still need discipline. Client components should be used when the component needs state, browser APIs, animation, or event handling.

A blog article page does not need to be fully client-rendered. The content, metadata, JSON-LD, related posts, and table of contents can be server-rendered. Search filters on the blog index can be client-side because they are interactive. This split is a performance and architecture win.

This connects directly to TypeScript and Next.js architecture. Clear server/client boundaries reduce JavaScript and make the codebase easier to maintain.

Watch layout shifts in brutalist interfaces

Brutalist UI often uses big typography, grid systems, thick borders, and strong cards. These elements can be stable if dimensions are planned. Problems appear when hover states change size, fonts load late, images lack dimensions, or dynamic content pushes surrounding elements unexpectedly.

Use stable grid tracks, aspect ratios, and min heights for repeated cards. Avoid button text that overflows at smaller widths. Avoid loading states that collapse and expand. A brutalist border system should feel intentional, not shaky.

In portfolio pages, cards should not resize unpredictably when data changes. Blog cards should handle long titles. Skill tiles should keep stable dimensions. Project rows should preserve their structure across categories.

Measure what users feel

Core Web Vitals are useful because they approximate user experience:

  • Largest Contentful Paint: how quickly the main content appears.
  • Interaction to Next Paint: how responsive the page feels after user input.
  • Cumulative Layout Shift: how stable the layout is while loading.

Metrics should guide attention, but they are not the whole story. A page can score well and still be confusing. A page can be beautiful and still be too slow. The best performance work connects measurement to product outcomes.

Use Lighthouse, PageSpeed Insights, browser performance tools, and real user monitoring when available. For personal portfolios, even a manual checklist helps: test mobile, throttle network, inspect image sizes, and confirm that navigation feels immediate.

Performance and SEO work together

Search engines care about useful content, crawlable structure, and page experience. A technical blog with strong metadata but slow rendering leaves value on the table. A fast site with thin content also leaves value on the table.

The strongest SEO portfolio combines:

  • Helpful long-form content.
  • Semantic headings.
  • Internal links.
  • Fast pages.
  • Optimized images.
  • Structured data.
  • Clear canonical URLs.

That is why performance belongs in the same content cluster as portfolio SEO, AI engineering, and architecture. It proves that the developer can think beyond features.

Common Next.js performance mistakes

The most common mistakes are simple:

  • Marking large page trees with 'use client'.
  • Loading every image eagerly.
  • Using large images without responsive sizing.
  • Importing heavy libraries globally.
  • Adding animation to elements that should be stable.
  • Ignoring mobile layouts.
  • Testing only on a fast desktop connection.

Fixing these issues rarely requires exotic techniques. It requires attention. Start with images, JavaScript boundaries, layout stability, and route-level rendering.

Performance checklist for a developer portfolio

A practical portfolio performance review can be simple. Open the homepage on mobile width. Reload with a slower connection. Watch whether the hero text appears quickly, whether the navbar stays usable, and whether large images push content down. Then open the projects page, blog page, and a blog article. Look for layout movement, oversized images, and delayed interactions.

For a Next.js portfolio, check that blog content is generated on the server, that images use stable aspect ratios, that decorative assets are not bigger than necessary, and that pages do not import heavy client libraries unless they need them. If animation is used, it should support the experience instead of fighting the content.

Also check fonts. Custom fonts create visual identity, but they should be loaded predictably. Use font-display: swap or the framework's font optimization where possible. Avoid layouts where a late font swap changes dimensions enough to cause visible shifts. Big typography is beautiful only when it remains stable.

How performance supports recruiter trust

Recruiters may not run Lighthouse, but they notice friction. A portfolio that opens quickly and communicates clearly feels professional. Engineering managers may inspect implementation details, and performance work gives them concrete signals: image optimization, server rendering, stable layout, accessible headings, and disciplined client JavaScript.

For product companies and AI startups, performance also suggests product empathy. Users do not care whether a page is slow because of images, hydration, or a third-party script. They only feel the delay. Developers who can connect technical causes to user experience are easier to trust with real products.

Conclusion

Web performance is a product skill. For React and Next.js developers, it demonstrates care for users, respect for recruiters' time, and engineering maturity. Fast pages make content easier to consume and projects easier to evaluate.

A developer portfolio should not only say "high-performance". It should load quickly, stay stable, and make the important information visible. That is how performance becomes part of personal branding.

FAQ

Why do Core Web Vitals matter for a developer portfolio?

They matter because users feel speed immediately, and search systems consider page experience as part of overall quality. A fast portfolio also supports the developer's credibility.

What usually slows down a Next.js site?

Large images, too much client JavaScript, layout shifts, third-party scripts, and unnecessary animation are common causes.

Should every React component be a client component?

No. Use client components for interaction and browser-only behavior. Keep static content and metadata server-rendered when possible.

Previous articleTypeScript and Next.js Architecture for Scalable Full-Stack ApplicationsNext articleAI Engineering with Next.js: A Production Guide to RAG, Evaluation, and Product UX
Article: Web Performance15 min readWritten by Ta Van ThaiLearning in public
LET'S WORK TOGETHERTA THAI™FULL-STACK DEVELOPERLET'S CONNECTJAPAN-FOCUSEDIMPACT-DRIVENCODE. DESIGN. SHIP.

LET'S WORK
TOGETHER一緒に作りましょう

Have an idea or project?
Let's build something amazing.アイデアやプロジェクトがありますか?素晴らしいものを一緒に作りましょう。

© 2026 Ta Thai™
Built by Ta Thai™