> ## Content Index > Fetch the complete content index at: https://iris-on-bookrest.info/llms.txt > Use this file to discover other available public pages before exploring further. # Key Strategies for Achieving High Scores in PageSpeed Insights - URL: https://iris-on-bookrest.info/en/pagespeed-muzui-en/ - Published: 2026-08-29T15:05:15.000Z - Updated: 2026-08-29T15:05:15.000Z - Description: Learn how to boost your website's speed using Google PageSpeed Insights. This engineer's guide covers specific improvements for key metrics like FCP, LCP, and TBT, plus realistic score targets without chasing perfection. - Author: やまぐろ - Tags: ブログ運用, ノウハウ, Ghost, en Hello, I'm a professional engineer. Today, I'm going to discuss optimizing with PageSpeed Insights! ## What is PageSpeed Insights? It's a web page performance measurement tool provided by Google. By simply entering the URL of the page you want to check, you can evaluate the display speed for both mobile and PC in a score format out of 100 points. ## About the Evaluation Metrics The main evaluation metrics (lab data) used to calculate the PageSpeed Insights score (0-100 points) are primarily the following five: Each metric has a 'weight (distribution ratio)' towards the score, and the total is graded out of 100 points. | **Evaluation Metric** | **Simply put?** | **Ideal Benchmark** | **Weight** | | --------------------- | ------------------------ | ------------------- | ---------- | | **FCP** | **First Display** | Within 1.8 seconds | **10%** | | **LCP** | **Main Content Display** | Within 2.5 seconds | **25%** | | **TBT** | **Inactivity Period** | Within 200 ms | **30%** | | **CLS** | **Screen Instability** | 0.1 or less | **25%** | | **SI** | **Visual Completion** | Within 3.4 seconds | **10%** | FCP, CLS, and TBT seem to be areas that can be relatively easily addressed with some effort, I think. ## Improvement Methods for Each Metric Next, let's look at the improvement methods for each metric. ### 1\. Improving FCP Reduce blocking factors that prevent the browser from rendering the first element after it starts loading HTML and CSS. - **Eliminate render-blocking resources:** Postpone (using `async` / `defer`) unnecessary CSS and JavaScript for the first view, and inline only critical CSS. This is essentially asynchronous loading. External resources that don't affect rendering, such as Google Analytics, and comment areas or share buttons often placed at the bottom of the page, can also be delayed. - **Reduce Server Response Time (TTFB):** Accelerate the initial return of HTML by implementing server-side caching and leveraging edge caching from CDNs (like Cloudflare). However, server caching carries various risks if not configured correctly. Be especially cautious as it doesn't always play well with (and can be difficult for!) membership sites. - **Speed up Font Display:** Set `font-display: swap;` for web fonts to prevent text from being invisible (FOIT) while waiting for fonts to load. Japanese fonts, in particular, have many characters and tend to have large file sizes, so if this is a concern, it might be better to use system fonts. ### 2\. Improving LCP Render the hero image or title text that occupies the largest area in the first view as quickly as possible. - **Optimize and Convert Main Images:** Adopt next-generation formats (WebP / AVIF) and perform appropriate resizing and compression. Many web tools exist for compression, so while it might be a bit tedious, it's easily done. - **Prioritize Main Element Loading:** **Never** apply `loading="lazy"` to hero images that are LCP. Instead, specify \`\` or `fetchpriority="high"` to request them with the highest priority. This can be a bit tricky, so it's okay to postpone it. - **CDN Delivery and Asset Caching:** Deliver images and media files from a CDN and transfer them in parallel using HTTP/2 or HTTP/3\. Let's implement Cloudflare! ### 3\. Improving TBT (Total Blocking Time) Distribute and reduce the load of JavaScript that monopolizes the main thread for long periods (Long Task: 50ms or more). - **Remove Unnecessary Code and Code Snippets:** Delete unused JS libraries and dynamically import (Dynamic Import) only the scripts needed for each page, loading them in segments. This is prone to issues, so it's generally recommended to postpone it. - **Delay and Organize Third-Party Scripts:** Delay the loading of tag managers, analytics, ad tags, social media embeds, etc., until after user interaction, or offload them to a Web Worker (e.g., Partytown). Approaching this with the question, 'Is this content even necessary?' often makes it easier. - **Break Down Heavy Processes:** Split long processing loops into smaller chunks using `requestIdleCallback` or `setTimeout` to free up the main thread. This is also prone to issues, so it's generally recommended to postpone it. ### 4\. Improving CLS (Cumulative Layout Shift) Eliminate content shifting caused by asynchronously loaded elements. It's especially important to pay attention to the first view. - **Specify Aspect Ratios for Images/Videos:** Explicitly set `width` / `height` attributes or CSS `aspect-ratio` for all `and` tags to reserve space before loading. - **Pre-allocate Space for Dynamic Content/Ad Slots:** Set `min-height` on parent elements of ad banners and dynamic widgets to prevent layout shifts upon loading. - **Mitigate Shifts During Font Swaps:** Match the size ratio of web fonts and fallback system fonts using CSS `size-adjust` or similar properties to minimize paragraph shifts caused by character width changes during font swaps. My impression is that significant deductions aren't very common here. ### 5\. Improving SI (Speed Index) Increase the speed at which the entire first view content is rendered progressively and stably. This is based on the points discussed so far. - **Thoroughly Improve FCP and LCP:** Since SI is a metric that integrates the visual progress of the entire screen, addressing FCP and LCP naturally leads to a correlated improvement in the SI score. - **Eliminate Waste in Above the Fold (Non-Scrollable Area):** Consistently apply `loading="lazy"` or lazy hydration to images and components outside the first view. This is also something we covered for FCP. ## Don't Aim for Perfection! While I've outlined various optimization methods so far, my honest opinion is that aiming for perfection is not highly recommended. This is because while image compression and CDN usage can be implemented relatively safely without significantly impacting display, misconfiguring elements for lazy loading can lead to issues where page operations don't work correctly or elements that should appear in the first view are not displayed. If you want to achieve results quickly and safely, it's best to organize your content and simply remove unnecessary resources. ## This Blog's Score This blog loads quite a few external resources, which often become bottlenecks. - Google AdSense - Comment section (cusdis self-hosted) - Like count retrieval & update API (implemented with Cloudflare Workers) - Popular article ranking (implemented with Cloudflare Workers) - Web fonts Therefore, I've implemented strategies like lazy loading and caching for these elements. The scores look like this: Smartphone. The device and network used by PageSpeed Insights are low-spec, making it difficult to achieve a high score. PC. It's recommended to improve this score first. At one point, I was extremely particular about the scores, addressing every single point PageSpeed Insights recommended for improvement, which resulted in quite high scores! Even with these efforts, there are still areas where I've compromised. For example, some things are 'beyond the control of site-specific settings' (external resources), as shown below. Cache time for external resources also results in negative points. There's nothing that can be done about it. While self-hosting scripts and setting your own cache TTL would improve things, it would mean constantly having to track script updates yourself. That's simply too much operational burden, so I've decided to overlook it. There are also other items, like 'image sizes can be improved further!', but seriously tackling them would likely involve complex conditional logic, so I'm skipping those. It's difficult to properly process images for all device sizes! It's better not to overdo it. In terms of performance goals, I think it's sufficient if the homepage, article pages, and list pages each score around 70 points, so aiming for that and tuning accordingly is probably a good approach. 100 points is generally unrealistic, so let's stop there. Honestly, going from 90 to 100 points doesn't significantly change the user experience; both are fast. ## Other Potential Improvements To be honest, I don't often find client-side code to be the bottleneck. In practical work, performance considerations are usually on the backend. More specifically, I believe database design, SQL design, and tuning consume the most time. Since this site uses a CMS, I haven't touched the backend at all. It's possible that data unnecessary for display is being fetched, but for this part, I'm assuming the CMS handles appropriate DB design and queries. Moreover, messing with it risks breaking things during future updates. Client-side considerations would involve the unit of API requests, but again, if the endpoints provided by the CMS are appropriate, it shouldn't be an issue. If anything, since I have about three custom endpoints for external resources, I've designed them with performance in mind. For instance, separating endpoints for single item retrieval and list retrieval. But then again, there isn't that much to consider for a blog site. You can probably get decent scores with the CMS as is. ## Conclusion This site is run on Ghost, which is a very fast CMS even by default. Achieving good scores with WordPress would likely require significant effort and ingenuity. However, in terms of functionality, WordPress is probably superior. The more features there are, the more performance tends to decrease. So, it's important to choose a CMS by considering the balance between the functionality you need and the desired performance. --- *This article was translated from the [original Japanese version](https://iris-on-bookrest.info/pagespeed-muzui/) (ページスピードインサイトで高得点を目指す際のポイントを見ていこう) using Gemini API.*