What does "First Meaningful Paint" mean in Web Performance?

Create ads with Google AI.

Google Ads

From prompt to pro-level ads. All with Nano Banana Pro in Google Ads.

I used to get advice from Bluehost how to improve performance.

Most of it was simply keeping my account clean of junk files. If you have an email account or accounts, those tend to fill up with spam and scams. And it can drown out real messages.

If it says “unlimited” space, that does not mean to fill it up. You should have free space along with filled space for your web site files and applications.

For coding design, look up best algorithms and arrangements of script code.

I have seen that ads can slow down a page. Don’t put too many ads or third party content on pages that are for regular website business like login, registration and sales processes. I have accidentally clicked a hotel stay purchase ad that booked me at a wrong hotel. I was able to fix that at the hotel where I had planned to stay and was ...

Assistant

First Meaningful Paint (FMP) is a user-centric web performance metric intended to capture when the primary content of a page is visibly rendered and useful to the user. It aims to measure the moment a page appears to have meaningfully loaded, not just when any pixels first change.

What FMP tries to quantify

• The first render of content that corresponds to the page’s purpose — e.g., main article text, product images, or primary UI — rather than decorative chrome or loading spinners.
• A point in time when a user can perceive that the page is useful and starts to engage with it.

How it differs from related metrics

• First Paint (FP): records when the browser first renders anything (even a background color). FMP focuses on meaningful content, not any paint.
• First Contentful Paint (FCP): marks when the first DOM content (text, image, SVG, canvas) is painted. FMP aims a step later — the first paint that conveys the page’s primary content — so it can be more representative of perceived usefulness than FCP.
• Largest Contentful Paint (LCP): captures when the largest visible element (often hero image or large text block) is painted. LCP is now the preferred standardized metric for perceived loading completeness; it's more stable and simpler to compute than FMP.

How FMP was measured (practical notes)

• Originally introduced in Chrome’s devtools and Lighthouse, FMP combined heuristic analysis of the render tree, network activity, and visual significance to pick a “meaningful” paint event.
• Heuristics looked at element size, position, and whether rendered elements were likely primary content.
• Implementation proved brittle: results varied across pages and could be gamed by CSS/DOM order, making FMP inconsistent across sites and runs.

Why FMP fell out of favor

• Instability and complexity: determining “meaningful” content reliably in all layouts is hard.
• Difficulty in standardization: no robust cross-browser specification existed.
• Replaced by LCP in Core Web Vitals: LCP offers clearer definition, simpler computation, and better correlation with user perception, and is widely supported in browsers and tooling.

How to approximate perceived meaningful paint today

• Use Largest Contentful Paint (LCP) as the primary Core Web Vitals metric for perceived load completeness.
• Combine LCP with First Contentful Paint (FCP) and Time to Interactive (TTI) to understand early visual progress and interactivity.
• For custom needs (single-page apps, above-the-fold interactivity): measure visually significant elements with PerformanceObserver on 'paint' and custom DOM-snapshot heuristics or use visual metrics (Speed Index, visual progress from filmstrip or Lighthouse's simulated visuals).

Practical recommendations

• Prioritize optimizing LCP (reduce server time, optimize critical CSS, defer noncritical resources, compress/resize images, use preload for hero assets).
• Use Continuous Real User Monitoring (RUM) to capture LCP and FCP across real users; use lab tests (Lighthouse, WebPageTest) to diagnose root causes.
• If you need a bespoke “meaningful paint” signal, define deterministic rules (which elements count, bounding boxes, visibility thresholds) and measure them consistently rather than relying on opaque heuristics.

Note on timeframe

• Guidance and tooling summaries reflect public information and best practices through May 2024.

Images can be a quite sizable and can hinder performance if not optimised correctly. When opening a website on a mobile device with a screen width of approximately 375px, there is little point downloading 20 images that are 2000px wide. Its a waste of data and will cause the site to be slow to load. Therefore in order to optimise this, a series of different images are offered to the browser via an image srcset attribute and based on the CSS and device screen size the browser selects the optimal one to download.

A modern web application has multiple layers which have their own rules of optimization. Lets consider a simple three tier web application and their possible optimizations (generic)

Database

• Ensure enough hardware is made available viz CPU, RAM, Disk, Network etc.
• Tune the configuration for proper utilization of the resources
• Have least amount of logging

Server application

• Code review / Pair programming ensure minimal mistake and high quality code
• Use fast in-memory caching solutions to avoid making duplicate calls to database.
• Enable compression in web / application server to send gzipped response
• See if jobs can delegated asynchronously

Client side

• Set correct expiry headers for static resources such as Javascript, CSS, Images, media etc. This will help browser cache them properly and reduce page load time significantly
• Utilize a CDN for faster response to network requests.
• Combine multilple javascript, css files to lesser number of files. Lesser number of requests to server means faster page load
• Optimize your images for faster page load
• Put CSS in head of the page to avoid FOUC, javasripts at the bottom. Once all CSS is loaded browser knows how to render each element. Javascript load is a blocking requests (blocks rendering), hence to be put at bottom. Check if they can be loaded asynchronously.

Create Ads with Google AI.

Google Ads

From prompt to pro-level ads. All with Nano Banana Pro in Google Ads.

Varnish a http accelarator and acts as a reverse transparent proxy.
A typical scenario is varnish listening to port 80 for requests from web users and apache listening to port 8080 for requests from varnish at the backend.

The first time a web user asks for a page, varnish passes the request to the backend server (eg apache). If the request does not have any session or cookie associated with them, the resulting page/file is cached. The next time a web user asks for the same page, the cached version is served. The cache can be stored either in the disk or in memory.

Pros:

• Very fast. Dynamic pages can be cached in memory.
• The backend server is freed for other more labor intensive tasks. Static files that would normally consume the resources of apache are now served through varnish

Cons:

• It may be a little difficult to set up to take full advantage.

I have written many answers on this question which you can refer to. However, in principle it is like tuning a race car, in the sense that it is a complex piece of technology, and many details must be considered. This includes an appropriate spend on infrastructure (throwing more money at the problem is never the answer on its own, but also spending too little and expecting a quality product can be a barrier). It also includes skilled adjustment and testing of infrastructure, code, and content, paying attention to the diagnosis of any performance problems and identification of any standout problems.

The work will take into account the amount of traffic, the type of traffic. No two apps are the same in terms of the mix of code features, infrastructure, and traffic profile. The work will also review the type and quality of denial of service protection and web application firewall which has been bought in from a specialist provider—since malicious traffic is one reason for bad performance.

PyCharm. Feel the difference in data science and AI/ML workflows.

JetBrains

The only Python IDE you need to build data models and AI agents. Free forever, plus one month of Pro.

Web performance is very critical for e-commerce, media and streaming web apps. One questions they always have in back of their mind is "How fast should my site load?".

A recent article by Denys Mishunov at Smashing Magazine that looks at this question from a completely different perspective – human psychology – that is a nice rule of thumb when considering your site's load times. Within his analysis, he breaks down time into four categories:

Testing the performance of your website or application allows you to identify issues and improve the overall performance, which can lead to an improved user experience and increased revenue. There are many common issues that performance testing can uncover, such as bottlenecks.

Which web performance metrics matter?

Improving your website's performance begins with taking some measurements, but measurements are not the same thing as metrics. What's the difference?

Measurements refer to specific data points, such as the number of seconds it takes to process a request. Metrics are what is actually being measured. Here are some metrics relevant to performance testing:

• Response time: The amount of time between a specific request and a corresponding response. Response times can vary drastically for different actions under different conditions.
• Average load time: The average response time for all requests gives good insight into the overall user experience.
• Peak response time: The longest response time. If your peak response is much longer than your average load time, then you probably have a problem.
• Wait time: Sometimes called average latency, wait time refers the amount of time a request spends in a queue before it gets processed. Distinguishing between wait time and response time is important because they depend on different factors.
• Requests per second: The number of requests handled per second.
• Memory utilization: The amount of memory required to process a request.
• CPU utilization: The amount of time required for the CPU to process requests.
• Error rate: The ratio of errors to requests.
• Transactions passed/failed: Similar to error rate, but it takes into account other factors that cause requests to fail.
• Concurrent users: Also called the load size, concurrent users means the number of active users.
• Throughput: Typically measured in kilobytes per second, throughput refers to how much bandwidth gets used during performance testing. Since it is the best indicator of your website's capacity, setting a throughput goal is a good first step to improving your website's capacity.

Web performance has traditionally been measured using the load event. However, while load is a well-defined period in a page's lifecycle, it does not always match with anything the user is interested in.

A server, for example, could respond with a minimum page that "loads" immediately but then delays retrieving content and displaying anything on the page until many seconds after the load event triggers. While such a page may technically have a quick load time, that time does not equate to how a user really perceives the page loading.

Types of metrics

There are several other types of metrics that are relevant to how users perceive performance.

• Perceived load speed: how quickly a page can load and render all of its visual elements to the screen.
• Load responsiveness: how quickly a page can load and execute any required JavaScript code in order for components to respond quickly to user interaction
• Runtime responsiveness: after page load, how quickly can the page respond to user interaction.
• Visual stability: do elements on the page shift in ways that users don't expect and potentially interfere with their interactions?
• Smoothness: do transitions and animations render at a consistent frame rate and flow fluidly from one state to the next?

Given all the above types of performance metrics, it's hopefully clear that no single metric is sufficient to capture all the performance characteristics of a page.

Consider this image:

HTTP 1 gave us a single connection with which to load data.

HTTP 1.1 gave us 2 connections (most of the web still uses this).

HTTP 2 gave us multiple channel connections.

HTTP 3 gives us an entirely new protocol: QUIC (Quick UDP Internet Connections).

Before HTTP 3, all protocols used TCP which can stall on dropped packets. QUIC is a multiplexing protocol and does not (see QUIC documentation for an in-depth review).

HTTP 3 is far more like websockets, in that it allows for server push, not simple request-response. You can create a connection and not have to deal with TLS handshaking for every single request.

Here is a typical latency graph for the various layers:

And here is a link to where and how it can be used:

HTH

I was walking around ahref then I saw a strange case. Want to bring this issue for everyone to discuss.

VS

My page doesn't have many backlinks. Both pages have a lot of same products. But my page`s keywords are ranked higher than the competitor. The template keyword I used for testing is “Price + product name”. In Vietnamese is “Gia + product name”. “Gia” == “Price”

I compare some metrics in the same product:

Content

Mine: Poor content.

The competitor: rich content.

Keyword onpage

Mine:

The competitor:

Maybe their content less relevant to the keyword search.

Structured Data

Mine:

The competitor:

They don’t have breadcrumb.

Page performance:

1)AMP

Mine: Yes

The competitor: No

2)Page speed & page size

Mine:

The competitor:

3) Google speed insight

Mine:

The competitor:

I think the main reason here is the web performance of my page is very much better than them

There's a interesting post today (2/1/11) on "A Practical Guide to Varnish" in the Factual Dev Blog - http://devblog.factual.com/practical-guide-to-varnish.

(disclose, I work here)

Here's the opening section:

Varnish is an open source, high performance http accelerator that sits in front of a web stack and caches pages. This caching layer is very configurable and can be used for both static and dynamic content.

One great thing about Varnish is that it can improve the performance of your website without requiring any code changes. If you haven’t heard of Varnish (or have heard of it, but haven’t used it), please read on. Adding Varnish to your stack can be completely noninvasive, but if you tweak your stack to play along with some of varnish’s more advanced features, you’ll be able to increase performance by orders of magnitude.

Some of the high profile companies using Varnish include: Twitter, Facebook, Heroku and LinkedIn.