【WordPress】画像軽量化とpreloadを試してもLCPが安定して下がらなかった記録｜PSIモバイル測定の実例

WordPress Speed Optimization Log: Image Compression and Preload Didn't Stabilize LCP | A PageSpeed Insights Mobile Case Study

This article was structured and written with the help of several AI tools, based on the actual development and testing records of FUKABORI COLORS. It records the work that was actually done and the measurements taken, including what improved, what could not be confirmed, and what the cause remained unidentified for.

I measured the homepage of my WordPress site (theme: Cocoon) with PageSpeed Insights (PSI) on mobile and got a Performance score of 58 and an LCP of 10.1 seconds. I preloaded the background image, shrank images and converted them to WebP, tidied up the font settings, and changed how the slider outputs its images.

The result: PSI's estimate of potential image savings dropped from about 1,318 KiB to about 960–970 KiB, but LCP kept fluctuating between 7.2 and 10.1 seconds, and I could not confirm a stable improvement. Even re-measuring the same state could move the score by tens of points. This article is a record of what I investigated, what I changed, and what I still don't know.

1. Test Conditions and Initial Results

I measured with PSI on mobile. According to the report, the setup was a Moto G Power emulation, slow 4G throttling, and Lighthouse 13.5.0. I ran many measurements, and the time of each one differs.

The first measurement (my own record) was:

• Performance 58, FCP 3.8 s, LCP 10.1 s, TBT 70 ms, CLS 0.123
• Image delivery audit: estimated savings of about 1,318 KiB

TBT was low, so the problem was not JavaScript processing but how long it took for the page to start rendering.

2. Identifying the LCP Element

Opening PSI's "LCP request discovery" showed that the LCP element was not an image but div.entry-content.cf (Figure 1). Inspecting that element in the browser's developer tools revealed a 1200×1700 px WebP (88.0 KB) set as its CSS background-image (Figure 2). In other words, the LCP element was a background image.

The LCP breakdown of the first measurement (my own record) was about 1,490 ms of resource load delay, about 130 ms of load time, and about 120 ms of element render delay. The file was light, and the wait before loading even began stood out. However, the sum of the breakdown does not match the headline 10.1 seconds, and I have not confirmed why.

3. Compressing and Replacing Images

PSI's "Improve image delivery" audit listed images far larger than their display size (Figure 3). For example, a 1200×630 px file was used for an image displayed at about 256×134 px, and a 1407×768 px file was used for a logo displayed at about 192×105 px. Images written directly into Custom HTML do not get the srcset that WordPress generates for media library images, so the original large file is served as is.

The steps were:

1. Save the URL of the original image (the original file, not a derivative such as -768x403)
2. Resize it in Squoosh. I used roughly twice the display width as a guide
3. Use WebP at a quality of around 80
4. Upload it to the media library and replace the URL in the HTML
5. Keep the old images instead of deleting them, so the change can be reverted

I first replaced four images, including the logo, and measured. After that, I also replaced the speech-balloon and character images.

4. WordPress Code Changes and the Pitfalls

4-1. Preloading the background image

A background image is only discovered after the CSS has loaded, so it tends to be fetched late. I decided to instruct the browser to fetch it early in the <head>. I first tried to put a <link rel="preload"> into Cocoon's "Head code" field, but saving failed with a 403 error. I suspected the server's security feature (WAF) blocked a request containing HTML tags, but I did not isolate it, so the cause is not confirmed.

So I switched to a WPCode PHP snippet that outputs the tag only on the homepage (a static page).

The following is an example configuration. When you use it, replace the page ID and the image URL with the values for your own site.

add_action( 'wp_head', function () {
    if ( is_page( 123 ) ) { // 123 is the ID of the static page used as the homepage
        echo '<link rel="preload" as="image" href="https://example.com/.../background.webp" fetchpriority="high">' . "\n";
    }
}, 1 );

The pitfall: I thought I had saved and activated the snippet, but in the snippet list it was still inactive. Searching the page source found no preload, and I only noticed the problem when I looked at the list again. After activating it, I could confirm that the <link rel="preload"> appeared in the page source, and the fetchpriority=high item in PSI's "LCP request discovery" passed.

The lesson: saving code and having it activated and output are different things. Check the output in the page source.

After the preload, the LCP breakdown was TTFB 230 ms, resource load delay 1,280 ms, load time 120 ms, and render delay 550 ms. The delay only dropped from 1,490 ms to 1,280 ms, so the wait before loading did not shrink much.

4-2. Duplicate Google Fonts loading

PSI's "Network dependency tree" showed about 40 font files (woff2) hanging off two stylesheets (Figure 4).

• An @import in an on-page style (Zen Maru Gothic, weight 900)
• A font specification the memo-card plugin loads with wp_enqueue_style (Yuji Syuku, Zen Maru Gothic, Quicksand)

Japanese web fonts are served split into many small pieces, so overlapping specifications multiply the number of files. I changed one line in the plugin's font specification and removed the weights for which I could not find any use in the code. Specifically, I reduced Zen Maru Gothic from 400/500/700 to 500/700, and Quicksand from 400/500/600/700 to 600/700. Updating the plugin may revert this change.

I could not judge the effect of this change. Two measurements of the same state came out far apart: 31 points (TBT 2,040 ms) and 57 points (TBT 210 ms).

The pitfall: Later I noticed that the URL on the line I had changed contained a space between css2? and family=. I have not confirmed whether that URL was loading correctly (measurements C–H were taken in this state). The English text on the back of the memo cards still displayed normally, but that is not proof the font loaded, because the browser falls back to the substitute font in the specification. I removed the space, saved again, and measured three more times (measurements I–K).

The lesson: after rewriting a URL, check in the developer tools' Network tab that the font CSS actually loads (status 200).

4-3. The slider's image output

The "latest updates" slider calls WordPress's image function in PHP and lines up the thumbnails. PSI's "Improve image delivery" included several slider images where a 768×403 version was loaded even though the display size was about 438×230.

I added the following attributes to the image output code. Before the change, only class and alt were specified.

echo wp_get_attachment_image($thumb_id, 'medium', false, [
    'class'         => 'f-new-img',
    'alt'           => esc_attr($title),
    'loading'       => 'lazy',
    'fetchpriority' => 'low',
    'decoding'      => 'async',
    'sizes'         => '(max-width: 850px) 90vw, 350px',
]);

loading="lazy" defers loading of off-screen images, and sizes tells the browser which image size suits the display width. Note that the sizes value has to match the actual width of the display area, and I have not separately confirmed how this change affected the slider's loading.

4-4. Things I noticed but could not confirm the effect of

• The speech-balloon image URLs were written with http://. Changing them to https:// avoids an unnecessary redirect. I made this change, but I have not verified its effect separately.
• An <img> for the featured image, which is not visible on the homepage, was output with fetchpriority="high". It may compete with the background image preload for fetch priority, but I have not verified that. I have not dealt with it.

5. Measurement Results

The table lists each measurement together with the changes in place at that point.

Runs A, F, I, J, and K are my own records only. The measurement times were not consistent, so this table does not prove the effect of any change.

Here is what the table shows:

• The estimated image savings dropped from about 1,318 KiB to about 961–972 KiB. This is PSI's estimate and does not mean the actual transfer size shrank by about 350 KiB.
• LCP ranged from 7.2 to 10.1 seconds and did not move in any consistent direction. The last three runs (I–K) stayed within 7.4–8.2 seconds, but the baseline (A) is only a single record, so I cannot call this an improvement.
• Even in the same state, results varied widely: 31 and 57 points for C and D, 66 and 60 points for G and H, with CLS at 0.122 and 0.058. Runs I–K also fluctuated: 57–60 points, TBT from 80 to 510 ms, and CLS from 0.058 to 0.157.

The low score in C was mainly caused by TBT jumping to 2,040 ms, which was back to 210 ms in D with the same state. A single measurement cannot tell you whether a change worked.

The next two pairs are results measured back to back in the same state (Figures 5 and 6).

6. Why Lighter Images Did Not Stabilize LCP

What I could confirm

• The LCP element was a background image whose file is 88 KB, with a short load time of about 120–130 ms
• The largest part of the LCP breakdown was the delay before loading started (about 1,490 ms, and still about 1,280 ms after the preload)
• Even as the estimated image savings fell, LCP did not shrink consistently

From this, I think the file size of the background image is probably not the main cause of the slow LCP. However, I have not identified the cause. The following are candidates I have not verified.

• CSS or Google Fonts blocking rendering (PSI shows a potential saving of 150–510 ms)
• Rendering timing caused by the background being set as a CSS background on .entry-content
• Competition for fetch priority with the hidden featured image's fetchpriority="high"
• Variability from the simulated slow-connection calculation

As an unperformed check, an experiment that changes only one thing at a time could be run: temporarily removing the background image, or changing how fonts are loaded, and measuring each. Because I stacked several changes in this process, I could not separate which change had which effect.

7. What I Learned and What I Still Don't Know

What I learned

• The LCP element can be identified with "LCP request discovery" and the developer tools (here, a background image)
• Images far larger than their display size can be found in PSI's list and compressed
• After adding code, you need to check not only that it is saved but also that it is activated and output in the page source
• PSI scores and TBT can swing widely even in the same state

What I still don't know

• Why LCP does not improve consistently
• Whether real visitors' experience improved (there is no field data)
• How much each individual change helped

8. Why I Stopped

Before starting, I set a time limit of half a day. The estimated image savings fell, and TBT and SEO were good. On the other hand, the remaining LCP candidates had unpredictable payoffs, and since a single measurement cannot be trusted, every extra attempt costs more time. Given my other creative work, I decided to stop here. If it becomes necessary, I will retry by making one change at a time and measuring several times.

9. A Checklist for Anyone Facing the Same Problem

• Don't judge from a single measurement; measure several times and look at the spread
• Identify the LCP element with "LCP request discovery"
• If the LCP element is not an image, suspect a CSS background image
• Resize images to about twice their display size and use WebP
• Give images in Custom HTML width and height, and give off-screen images loading="lazy"
• Don't put loading="lazy" on the LCP image
• After adding code, check that it is activated and output in the page source
• Check the dependency tree for duplicate Google Fonts loading
• After rewriting a font URL, confirm in the Network tab that it loads (status 200)
• Distinguish "estimated savings" from actual transfer size
• Distinguish lab data from field data
• Decide on a time limit and a stopping condition before you start