Skip to main content

Perceived Load Speed (PLS)

A cross-browser metric for real-world speed

Vasil Dachev avatar
Written by Vasil Dachev
Updated this week

Introduction to PLS

Perceived Load Speed (PLS), created by Uxify, is a real-user performance metric that measures how quickly a page feels like it loads to users.

PLS is a subjective metric, where the subjects are your real users. It aims to reflect the moment when users perceive the page as loaded and ready for consumption.


Why we created PLS?

At Uxify, we believe that page load speed only matters when it drives real impact — increasing user engagement and boosting conversions.

After analyzing millions of user sessions and running A/B tests comparing fast and slow pageviews, we found that user engagement is strongly tied to perceived load speed, or how fast the page feels to load. This perception directly influences a user’s willingness to click, scroll, and stay engaged.


Here is how different types of page load metrics relate to engagement:

Experience Metric

Correlation to Engagement

Notes

Page load time

Low

Includes late-loading of non-visual resources like ads and trackers

Document load time

Low

Can complete before key visual elements are rendered, while users are still waiting to load.

FCP - First Contentful Paint

Low-Mid

Measures when first visual element appears, but the page may still look not loaded.

LCP - Largest Contentful Paint

Mid-High

First in line metric for perceived loading. It measures the time to load of the largest element on the screen (e.g. hero image or title). It measures maximum of one element per page.

PLS - Perceived Load Speed

High

Similar to LCP but measures the time to load of all meaningful elements on the screen. It doesn't have the limit for one element per page.


Comparison to LCP

Perceived Load Speed (PLS) closely aligns with Largest Contentful Paint (LCP), but they differ in scope. PLS measures the visual completeness of all meaningful on-screen elements, whereas LCP measures only the largest element's load time.

Below is a visual comparison example featuring Nike's website.

While LCP and PLS are often similar, the example above shows a 523-millisecond difference, reflecting the additional time required for all visible elements to load after LCP is triggered.

Metric

PLS

LCP

Browser support

Safari, Chrome, Firefox, Edge

Chrome, Firefox, Edge

What it measures

Time to all large elements in the viewport

Time to largest element in the viewport

Real User PLS

Real User PLS (Perceived Load Speed) is measured directly from user behavior, tracking when the page feels loaded - not just when a single element appears. Uxify calculates PLS based on the rendering of multiple visible elements and how the page visually stabilizes during load. Captured from every pageview via our script, this unsampled dataset gives you deep insight into how quickly your users perceive your site as “ready.” Unlike Core Web Vitals, which focus on specific metrics like LCP or CLS, PLS captures the holistic experience - making it one of the most user-aligned metrics in your performance toolbox.

Real User PLS – CrUX URLs only

This filter focuses your Real User PLS dataset on the pages that are part of the Chrome UX Report, letting you align perceived speed insights with CrUX-recognized URLs. Even though PLS isn’t part of the Core Web Vitals, this filtered view helps you connect user-perceived speed with the pages that matter most to Google. It’s especially useful when LCP and PLS tell different stories - for instance, when LCP reports fast but users still feel the page is incomplete. By correlating PLS with CrUX pages, you can prioritize fixes that improve both user satisfaction and SEO relevance.

Feedback loop

PLS is continuously calibrated through an automated feedback loop. Via the Uxify Chrome extension, users can provide thumbs-up or thumbs-down feedback on whether the PLS timing aligns with their perceived load experience. This input refines the metric, improving its accuracy.

Did this answer your question?