Since the introduction of Lighthouse, new parameters related to page speed have emerged. One of the most important of these parameters is First Contentful Paint (FCP). In Lighthouse version 10, effective as of June 2024, FCP's impact on the overall score is 10%.
To adopt and understand FCP as a metric, it is essential first to examine the psychology behind it. The concept is similar to the mirrors installed in elevators:
To summarize briefly: In the first half of the 1900s, the use of elevators in tall buildings increased significantly, but elevator systems were primitive compared to today. Therefore, the idea of installing mirrors in elevators emerged to make the time spent in the elevator feel shorter.
Returning to our topic: The point that perceptually makes you wait during the loading time when trying to access a page is FCP. The definition of First Contentful Paint is the time it takes for the first text, image, non-white canvas, etc., to be displayed for the user. The unit of FCP is seconds.
In Lighthouse, the color scale for FCP is determined as follows:
- 0-2 seconds: Green => Fast
- 2-4 seconds: Orange => Needs Improvement
- 4+ seconds: Red => Slow
According to HTTP Archive data, the number of sites that can be considered fast is 25%, and 50% of existing sites are classified as slow.
What Can Be Done to Improve FCP?
Reduce Server Response Time
Generally, this can be interpreted as improvements needed on the server side of the server and software. To list the issues that negatively impact server response time:
- The server's sharing, configuration (i.e., server settings), and server resources could be the problem. The capacity of your server should be increased according to your traffic. In some cases, poorly written database queries and highly complex software components can seriously affect server response time.
- Not using a CDN (Content Delivery Network) can cause delays in accessing content, affecting FCP. As the content size increases, for example, if a large animated GIF or video is attempted to be called without a CDN and the main server is on a different continent, you might need to consider CDN solutions to resolve FCP.
- Not serving static content with a proper and consistent cache policy can overload your server unnecessarily as the number of visitors increases. For example, if you don't keep your logo in long-term cache while loading it on every page, you unnecessarily harm your server's response time.
- Unnecessary page redirects while accessing the page can unnecessarily affect your FCP.
For instance, in the past, there used to be setups like this: when a user wanted to enter a site, there was an HTTP to HTTPS redirect, then if it was mobile, an HTTPS to mobile redirect (e.g., https://www to https://m), and if the page was removed and redirected elsewhere with a 301, it felt like the user was being passed from desk to desk in a tax office. This is an extreme example for better understanding, but if you redirect a page to another URL with a 301 redirect and then redirect that page to another with a 301, you might be making the same illogical setup.
- If you do not use preconnect or DNS-prefetch prefixes when connecting to your third-party services and connect to many third-party services, you are not doing anything beneficial for FCP.
Reduce Render-Blocking Resources
I must admit that this single point written as a line item can take months to address.
To achieve this, there is a solution method where all JS, CSS, and similar resources that block the page rendering are loaded after the page creation time, but the initially visible part of the site is loaded first while the site is loading. However, to do this, all JS, CSS, and similar resources need to be examined, and the most time-consuming processes need to be separated. Additionally, using as few third-party services as possible helps optimize FCP.
