Rendering Time
Initialization Process Duration
Before a Lynx page is displayed, initialization tasks must be completed, including container initialization and preparing the TemplateBundle.
The diagram below shows the mandatory initialization phases before page display, covering initialization duration for three components: Container, LynxView, and Background Thread Runtime. The Performance API provides InitContainerEntry, InitLynxviewEntry, and InitBackgroundRuntimeEntry to describe key milestones in these phases. You can combine these performance metrics for detailed analysis of the entire initialization process.
Even though these preparations occur before page rendering, their performance directly impacts user experience. Slow initialization delays rendering, causing users to perceive poor app performance due to delayed content display.
To minimize loading time, pre-complete initialization tasks through local caching, pre-loading TemplateBundles, and pre-creating LynxViews. This ensures immediate response to user interactions and enhances user experience.
First-Frame Rendering Duration
Lynx's unique dual-thread architecture allows rendering operations in the main thread runtime. This enables Instant First-Frame Rendering (IFR): Lynx briefly blocks the main thread to ensure the first frame renders completely at once. Since users see no blank screen, this creates a perception of instant responsiveness.
Read First-Frame Rendering Best Practices to learn how to render meaningful content in the first frame.
Obtain LoadBundleEntry for detailed timing data of first-frame rendering.
Non-First-Frame Rendering Duration
Many pages can only display loading animations or skeleton screens in the first frame. Critical data from native modules or network requests is required to complete page display. In such scenarios, developers need the duration of rendering triggered by critical data updates.
Developers can mark the Lynx pipeline to track these important updates. After marking, detailed timing data for the marked Lynx Pipeline can be obtained. The rendering duration for this update is available via the PipelineEntry interface.
Built-in Metrics
Lynx provides two built-in metrics: FCP and ActualFMP, with corresponding data available through MetricFcpEntry and MetricActualFmpEntry.
FCP (First Contentful Paint)
FCP is a critical performance metric measuring the time until the first content (text, images, etc.) renders in a Lynx page. The FCP event triggers when Lynx finishes painting the first frame.
Lynx offers three FCP variants based on different starting points: fcp, lynxFcp, and totalFcp. Their definitions in the rendering flow are shown below:
ActualFMP (Actual First Meaningful Paint)
ActualFMP measures the time until "real data" renders on the page, reflecting how quickly users see actual content. MetricActualFmpEntry describes this metric and inherits from PerformanceEntry.
Mark critical component rendering completion using __lynx_timing_flag="__lynx_timing_actual_fmp" to generate this metric.
Lynx provides three ActualFMP variants: actualFmp, lynxActualFmp, and totalActualFmp. Their definitions are shown below:
Custom Metrics
Custom performance metrics align with specific business objectives. Usage of the Performance API is not restricted to analyzing
page performance using built-in metrics. You can flexibly combine key moments of different PerformanceEntry to build a set
of performance metrics tailored to your application.
For example, if you want to focus on the delay between the end of the first-frame rendering and the end of the first significant data updates. You can combine
LoadBundleEntry and PipelineEntry
to calculate a new performance metric waitingDuration like the following code. This metric can help you monitor the speed of network requests, file reads, and other
behaviors, pinpointing the reasons for deteriorating page performance.
