Front‑End Performance Optimization: Key Metrics and Practical Techniques to Reduce First Paint and Improve Interactivity

This article explains essential front‑end performance metrics such as FP, FCP, LCP, TTI, FID, TBT and CLS, and provides a comprehensive set of network, code, CSS, image, and build‑time optimization techniques—including gzip, HTTP/2, lazy loading, SSR, debouncing, and tree‑shaking—to dramatically shorten white‑screen time and improve user experience on H5 pages.

ByteFE
ByteFE
ByteFE
Front‑End Performance Optimization: Key Metrics and Practical Techniques to Reduce First Paint and Improve Interactivity

Background

When developing a consumer‑facing H5 page, the author noticed a long white‑screen time on the homepage, which users repeatedly complained about, prompting a need to understand and improve first‑screen loading performance.

Performance Metrics

FP & FCP

First Paint (FP) records the time when the first pixel is rendered, while First Contentful Paint (FCP) records the time when the first text, image, non‑empty canvas or SVG appears. Both metrics are directly related to white‑screen duration, and lower values are better.

LCP

Largest Contentful Paint (LCP) measures the time when the largest element within the viewport is rendered. The value updates as the page renders and stops after the first user interaction.

TTI

Time to Interactive (TTI) is the moment when all resources have loaded and the page can reliably respond to user input. It is calculated after FCP, requires a continuous 5‑second period without long tasks (>50 ms) and without more than two concurrent GET requests, and is traced back to the end of the last long task before that period.

FID

First Input Delay (FID) measures the latency between the first user interaction after FCP and the moment the browser can actually process that interaction, often delayed by long tasks such as JavaScript parsing.

TBT

Total Blocking Time (TBT) is the sum of blocking time of all long tasks between FCP and TTI. For each long task, the portion exceeding 50 ms is counted as blocking time.

CLS

Cumulative Layout Shift (CLS) quantifies unexpected layout movements caused by late‑inserting elements. It is calculated as the product of the shifted area and the shift distance, with a recommended value below 0.1.

Key Indicators

LCP reflects page speed and the rendering time of the largest element.

FID reflects interactive experience; lower latency feels smoother.

CLS reflects visual stability, especially important on mobile devices.

Optimization Measures

Network Layer

Enable gzip compression

Gzip reduces transferred size by up to 70 % and is supported by major browsers and servers (Apache, Nginx, IIS).

Use HTTP/2

HTTP/2 introduces binary framing, multiplexing, header compression, prioritization, flow control and server push, all of which lower latency and improve throughput.

Replace icon images with iconfont

Icon fonts are vector‑based, small in size, and can be styled like text (size, color), reducing request count.

Image Optimization

Lazy‑load images when they enter the viewport.

Lower image quality using image-webpack-loader.

Prefer CSS effects over small decorative images.

Use WebP format for better compression without visual loss.

On‑Demand Loading

Split code at logical breakpoints and load additional bundles only when needed, reducing initial bundle size.

Code Layer

Replace location.herf redirects

In the teacher‑side project, location.herf caused full page reloads during login; refactoring to router‑based navigation avoids the performance penalty.

CSS Strategy

Optimize selectors (right‑to‑left matching), avoid deep nesting (>3 levels), remove unnecessary ID selectors, avoid universal selectors, and eliminate duplicate rules.

DOM Offline Rendering

Detach elements from the DOM (e.g., using display:none) to perform batch updates without triggering reflow/repaint, then re‑attach them.

Server‑Side Rendering (SSR)

SSR pre‑renders HTML on the server, eliminating the initial white‑screen and improving SEO, though it adds complexity.

Debounce & Throttle

Debounce resets the timer on each event to prevent rapid firing (e.g., preventing multiple login clicks). Throttle limits execution to once per interval, similar to rate limiting on the server.

Web Worker

Web Workers run JavaScript in a background thread, offloading heavy computations and preventing UI blocking.

Packaging Layer

Use CDN for images

Hosting images on a CDN reduces bundle size and leverages edge caching.

Optimize SourceMap

For development, use cheap-module-eval-source-map; for production, use cheap-module-source-map to balance speed and detail.

Compress JS and CSS

With Webpack 5, built‑in compression is available; for earlier versions, install terser-webpack-plugin (v4 for Webpack 4).

Tree‑shaking and on‑deman​d imports

Use babel-plugin-component or import specific functions (e.g., import lodash/get) to reduce bundle size.

Conclusion

The techniques described cover only a fraction of front‑end performance optimization. Readers are encouraged to explore the referenced articles for deeper knowledge.

OptimizationWebMetrics
ByteFE
Written by

ByteFE

Cutting‑edge tech, article sharing, and practical insights from the ByteDance frontend team.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.