This content originally appeared on Web Performance Calendar and was authored by Conor McCarthy
Over the course of 2025, I have completed 100 site speed reviews at DebugBear. This is a free service we offer to trial accounts looking for a brief assessment of their current web performance.
Requests consistently come in from small independent websites to much larger teams, across a wide range of industries. Each site speed review contains a five minute video that walks through the test results for a single URL.
I typically praise people for the good work they have done, while also sharing knowledge and key optimizations they may not be aware of to help improve results.
This format has been helpful in opening up communication, understanding customers’ goals, and adding context and reasoning to the metrics they are seeing.
Here are five key takeaways I have learned from reviewing pages this year.
Lighthouse is highly valued
Many reviews come in with questions surrounding their Lighthouse score. This is consistent across the board, from individuals working on small business websites to SEO specialists tasked with improving the metric for enterprise organisations.
Lighthouse is the gateway into understanding web performance. Running a test on Page Speed Insights is straightforward and free to use. Because Lighthouse is widely accessible and provides an easy to digest breakdown of overall page performance, it’s easy to see why it has become the gold standard for many people.
For larger teams operating at scale, I believe Lighthouse should primarily be used as a reference, with a greater emphasis on CrUX and Real User Monitoring data.
It’s understandable that many users develop a bias towards prioritizing Lighthouse performance score over CrUX, simply based on the user experience when running a test.
When testing a URL with Page Speed Insights, CrUX data is displayed immediately. There is then an anticipation while the Lighthouse report is generated, once the test is complete, we receive actionable audits and scores.
After making some changes, the process repeats with hopes of improving the overall Lighthouse score. CrUX data won’t change due to the delay of data rolling out, so being blind to this data can become a habit formed early on.
The reason why I mention this, is that one review came in from a developer working for a SaaS company. The CEO had a goal of 80 or above for the Lighthouse performance score for the entire site. Total Blocking Time was the only metric holding the score back. After removing third-party scripts, reviewing Google Tag Manager scripts and optimizing main scripts, the TBT was still over 1000 ms.
Interestingly, the INP CrUX data was way below 200 ms. On the other hand, CLS CrUX data was in the “needs improvement” range. Due to the CEO’s priority of setting Lighthouse as the standard, this metric was going under the radar and affecting real visitors.
Total Blocking Time thresholds are high
Currently, to achieve a good score, TBT must be under 200 ms on mobile and 150 ms on desktop. On the majority of pages I review, TBT is well over one second and most pages score in the red. I am often surprised to see any TBT score under 1 second.
If we take a look at the DebugBear demo project, which monitors 22 desktop URLs from a range of homepages, only four of the websites have a good score of 150 ms or lower. Are these pages performing poorly? Not according to CrUX data.
Fifteen of these pages have good INP CrUX data of under 200 ms, indicating that TBT isn’t significantly impacting real user experience. There is a possibility of regression in TBT that could eventually affect CrUX scores, but historically this isn’t the case.
A good example is the Discord homepage: it has over three seconds of TBT but an INP of just 81 ms.
TBT is heavily weighted in the Lighthouse performance calculator, which has a large impact on the overall score.
Whenever the question arises of how to reduce TBT in order to improve the performance score, I first check the CrUX data and share our demo project to show how many websites are failing this metric while providing good real world experiences.
Performance starts with Time To First Byte
Everything begins with Time to First Byte. A poor TTFB score puts any page at a major performance disadvantage. When reviewing a page, this is the metric that I pay attention to. A good score is considered under 800 ms. However, I only mention TTFB as a potential issue if the score exceeds 1000 ms.
TTFB is probably the most common teaching point I mention in my reviews. We list TTFB, FCP and LCP as the top row metrics. This makes sense, as when the LCP element is an image, then each of these metrics tie into each other.
In some cases, pages are submitted that are well optimized, but FCP and LCP lag behind solely due to slow TTFB. This can be disheartening for a customer after making changes that should, in theory, improve rendering. However, if TTFB is excessive, then this is a battle they may not win till addressing the core issue.
Explaining LCP as a budget of 2.5 seconds tends to resonate well, especially when discussing LCP sub-parts. If TTFB exceeds 1 second, there is little budget left to work with.
Misunderstanding fonts
Many smaller or independent websites easily get carried away with fonts, to the detriment of performance. Fonts can be a critical part of a page’s layout for some websites. There’s no direct issue with using many fonts, but with each font added to a page, the potential for performance issues increases.
On the surface, it may seem logical to preload all fonts, as they are visible assets that render on the page. However, if other critical resources are already being preloaded, page rendering or LCP images can be delayed due to bandwidth limitations. This scenario is often overlooked.
When discussing optimizing fonts, there are three main points I tend to mention:
- Only preload fonts used above the fold
- Serve fonts from your own domain to reduce render delays
- Watch for layout shifts and invisible text
LCP as video elements
Most pages I review where the LCP element is a video usually score poorly, often exceeding 2.5 seconds.
This can be accepted, as videos typically have longer load times than images. However, preloading a poster image with fetchpriority="high" can significantly improve performance.
This is an exciting optimization to share because this technique is not widely known, easy to implement and usually has a large impact on LCP scores.
Prior to the release of Chrome 116 in August 2023, videos without a poster image did not contribute to LCP. This change is fairly recent, so it’s important to highlight the value of using poster images where possible.
The first frame of the video counts as the LCP score. Any image could work, such as a video thumbnail, but we recommend using the first frame for visual consistency.
When experimenting with this optimization last year I uncovered a couple of best practices:
- Ensure that the poster image matches the video’s aspect ratio.
- Use
object-fit: coverstyle as a failsafe so that the poster image fills the element and prevents re-renders.
We can also preload a poster image with the fetchpriority="high" attribute, as we would with any LCP image.
<link rel="preload" as="image" href="posterimage.svg" fetchpriority="high"/> .... <video poster="/assets/posterimage.svg" autoplay="" muted=""> <source src="/assets/video.mp4" type="video/mp4" /> </video>
This content originally appeared on Web Performance Calendar and was authored by Conor McCarthy
Conor McCarthy | Sciencx (2025-12-21T11:23:22+00:00) Insights from 100 site speed reviews in 2025. Retrieved from https://www.scien.cx/2025/12/21/insights-from-100-site-speed-reviews-in-2025/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.