I set up page speed settings that took my mobile score from 87 to 98 by running a diagnostic PageSpeed test, identifying the Largest Contentful Paint element, and then methodically removing every obstacle between the browser and that element. I learned this process after migrating my own site from Blogger to a self‑hosted WordPress platform. The migration was a success the redirects worked, the design was clean, and all eighty‑two articles had transferred intact.
But when I ran the first PageSpeed Insights test on a single article, the mobile score came back at 87, and the Largest Contentful Paint the time it takes for the main content to load had nearly doubled from 1.7 seconds to 3.9 seconds. I was looking at a site that was functionally complete but slow to appear on a phone, and I knew that every fraction of a second above two seconds was a reader I was asking to wait. This guide is the exact sequence of fixes I applied, the settings I configured, and the code snippets I wrote to bring the score from 87 to 98 on mobile and 100 on desktop. Every step is reversible, testable, and grounded in the real data from my own site.
Why the Mobile Score Dropped After Moving to WordPress
When my site migrated from Blogger to WordPress, the redirects worked, the design was clean, and the content was intact. But the first real PageSpeed test revealed a hidden problem: the mobile performance score had dropped to 87, and the Largest Contentful Paint had nearly doubled. WordPress itself does not slow a site; the real culprits are:
· Plugins that inject hidden JavaScript and CSS files.
· Optimization settings that block the browser from loading the most important image first.
· Heavy social sharing tools that load dozens of external resources.
The good news is that every single cause is reversible. By the end of this guide, I had the exact settings and code snippets that restored my score to 98 on mobile and 100 on desktop. The same discipline of diagnosing the real problem instead of guessing is what I apply to a self‑discipline system that keeps the entire site consistent.
The PageSpeed Test That Started Everything
The first step is always to run an official Google PageSpeed Insights test. I open a private or incognito browser window and go to:
I enter the full URL of one of my articles not just the homepage and click Analyze. The results show two tabs: Mobile and Desktop. I focus on mobile because that is where most performance issues appear and where Google measures Core Web Vitals for ranking.
The initial single‑post mobile result for my site showed these numbers:
· Performance: 87
· First Contentful Paint (FCP): 1.5 seconds
· Largest Contentful Paint (LCP): 3.9 seconds
· Total Blocking Time (TBT): 80 milliseconds
· Cumulative Layout Shift (CLS): 0
· Best Practices: 73
The number to watch is LCP. Anything above 2.5 seconds is marked as “needs improvement.” At 3.9 seconds, the page felt sluggish on a phone. The Best Practices score of 73 was also a warning sign. I knew I had to fix both the speed and the practices score without disabling the plugins the site needed for its long‑term plans.
Understanding the Three Core Web Vitals
Before making any changes, I needed to know what each metric measured and which ones were worth chasing. The three Core Web Vitals are LCP, TBT (or its newer replacement, Interaction to Next Paint), and CLS.
· LCP (Largest Contentful Paint): How long it takes for the biggest piece of content usually the featured image or a headline to appear. It should be under 2.5 seconds.
· TBT (Total Blocking Time): How long the browser’s main thread is frozen, unable to respond to taps or scrolls. Aim for under 200 milliseconds.
· CLS (Cumulative Layout Shift): How much the page jumps around as it loads. Should be 0 or very close to it.
On my site, LCP was the only real problem. TBT and CLS were already excellent. That single insight focused my entire optimization effort. I did not need a broad speed overhaul; I needed to remove the specific barriers that were delaying that one image. This kind of targeted diagnosis is the approach I use when identifying the real bottleneck in a slow site instead of applying generic fixes.
The Diagnostic Framework How to Find What Is Really Slow
I did not guess which settings were causing the delay. I used a simple four‑step diagnostic process that anyone can follow.
Step 1: Identify the LCP element. In the PageSpeed report, I scrolled down to the “Diagnostics” section and found the line labeled “Largest Contentful Paint element.” I clicked it, and the report showed exactly which image or text block was being measured. In my case, it was the featured image at the top of every single post.
Step 2: Check render‑blocking resources. Still in the report, I opened the “Eliminate render‑blocking resources” section. This listed JavaScript and CSS files that were delaying the page from rendering. I saw heavy scripts from Jetpack, Grow by Mediavine, and some from LiteSpeed Cache itself specifically related to asynchronous CSS.
Step 3: Test by disabling suspects. I temporarily deactivated plugins one by one on a staging copy of the site and reran the test. When I deactivated Jetpack, the Best Practices score jumped from 73 to 100, and LCP improved. When I deactivated Grow, the remaining third‑party cookie warnings disappeared, and the score edged higher. But I needed Grow active for a future application, so I kept it and planned to block its heavy scripts with a code snippet.
Step 4: Test each setting change individually. I changed one LiteSpeed Cache setting at a time, purged all caches, and reran the test. This allowed me to see exactly which setting affected which metric. I learned that turning off lazy loading for the featured image alone dropped LCP by nearly two seconds. Turning off asynchronous CSS stabilized the rendering. Disabling JavaScript defer and delay kept the theme functional without hurting speed.
This diagnostic framework is now my permanent method for any performance issue. It replaces guessing with evidence, and it ensures that every fix I apply has a measurable result the evidence‑based approach is what I use when structuring a long‑form guide that readers can actually finish.
The Seven Fixes
Fix 1: Stop Lazy‑Loading the Featured Image
Lazy loading tells the browser to delay loading an image until it is about to scroll into view. For images far down the page, this saves bandwidth and speeds up the initial render. But for the featured image the LCP element lazy loading is a performance disaster. It forces the browser to wait until after the page is fully interactive before it even starts fetching the most important image. This single setting was adding nearly two seconds to my LCP.
The solution was to turn off lazy loading for the featured image. In LiteSpeed Cache → Page Optimization → Media Settings:
· Set Lazy Load Images to OFF.
· If I wanted to keep lazy loading for other images, I could add wp-post-image to the Exclude by Class field. The featured image automatically has this class in GeneratePress and most modern themes.
After purging all caches, I reran the test. The LCP dropped from 3.9 seconds to around 2.1 seconds with this change alone.
Fix 2: Turn Off Asynchronous CSS
The “Load CSS Asynchronously” setting can speed up a site if a separate Critical CSS file is generated. Critical CSS is a tiny inline stylesheet that renders the above‑the‑fold content immediately. Without Critical CSS, the browser sees no styles at all until the full stylesheet loads, causing a flash of unstyled content and a delayed repaint that pushes LCP later.
I did not have Critical CSS set up, and generating it requires special server configuration or a paid QUIC.cloud plan in many cases. So I turned the setting off.
In LiteSpeed Cache → Page Optimization → CSS Settings:
· Set Load CSS Asynchronously to OFF.
· Ignore the Generate Critical CSS option.
After purging caches, the LCP stabilised and TBT remained low. The page rendered with its styles immediately.
Fix 3: Disable JavaScript Defer and Delay
The “Load JS Deferred” and “Delayed JS” settings tell the browser to wait until the HTML is fully parsed before executing scripts. In theory, this reduces the time before the page is interactive. In practice, on a GeneratePress theme with a mobile menu and image loading handled by the theme itself, these settings can break functionality without improving speed.
I set both options to OFF in LiteSpeed Cache → Page Optimization → JS Settings. After purging caches, the TBT dropped to a near‑perfect 30 milliseconds, and the mobile menu continued to work correctly on every device. I tested the site on several phones and confirmed that no layout or interactivity issues appeared.
Fix 4: Preload the Featured Image on Single Posts
Even with lazy loading off, the browser might not discover the featured image as early in the HTML as it could. A preload tag inserted into the page’s <head> tells the browser, “This image is the most important thing on the page fetch it immediately.” This directive overrides the normal resource discovery process and starts the download at the highest priority.
I added a small code snippet to the site. I went to Snippets → Add New (using the Code Snippets plugin) or added it to the theme’s functions.php. The snippet automatically preloads the featured image on every single post:
“`php
function dailingua_preload_single_featured_image() {
if ( is_singular( ‘post’ ) && has_post_thumbnail() ) {
$image_url = get_the_post_thumbnail_url( get_the_ID(), ‘full’ );
if ( $image_url ) {
echo ‘<link rel=”preload” as=”image” href=”‘ . esc_url( $image_url ) . ‘” fetchpriority=”high”>’;
}
}
}
add_action( ‘wp_head’, ‘dailingua_preload_single_featured_image’, 1 );
“`
After adding the snippet and purging all caches, I reran the PageSpeed test. The LCP on single posts dropped from 2.1 seconds to 1.5 seconds. The featured image began loading almost immediately, and the page felt instant on every device. The approach of using lightweight custom code instead of plugins is what I apply when keeping the plugin stack lean and the site fast.
Fix 5: Optimize Every Image Without Losing Quality
My site already used WebP images and kept file sizes under 100 KB. But many sites import images that are megabytes in size, and those large files are the single biggest drag on LCP. LiteSpeed Cache has a built‑in image optimization system that can compress and convert images automatically.
In LiteSpeed Cache → Image Optimization:
· Turn ON Auto Request Cron.
· Turn ON Optimize Original Images (lossy compression).
· Turn OFF Preserve EXIF/XMP data (removes hidden camera metadata).
· If I had not already converted to WebP, I would turn ON Image WebP Replacement. Since my images were already WebP, I left it off to avoid double processing.
After saving, I clicked Send Optimization Request and waited for the images to be pulled back from the optimization server. This step can shave several hundred milliseconds off LCP for a site with unoptimized images.
Fix 6: Remove Plugin Bloat
Plugins are the most common cause of slow WordPress sites. I had Jetpack and a social sharing plugin that added dozens of external requests to every page. The fix was to delete them.
· I deleted Jetpack entirely. The social sharing, related posts, and site stats modules were loading scripts that I did not need.
· I removed the social sharing plugin and replaced it with a lightweight alternative that adds zero JavaScript to the front end (like Scriptless Social Sharing) or by sharing manually via a tool like Make.com.
· For site statistics, I relied on Google Analytics and Search Console, which are external and do not block page rendering.
After removal, I purged all caches and reran the test. The Best Practices score jumped from 73 to 100, the total page weight dropped noticeably, and the LCP improved by another tenth of a second. The lesson is clear: every plugin must justify its performance cost. This principle of evaluating every addition to the site is the one I use when deciding whether a tool genuinely supports long‑term growth.
Fix 7: Tame the Grow Plugin Without Deleting It
I kept the Grow by Mediavine plugin active because I planned to apply to the Mediavine ad network in the future. But even with all its features turned off, Grow was still injecting Snowplow analytics and a third‑party cookie iframe that triggered Best Practices warnings and slightly slowed the page.
I wrote a code snippet that dequeues the heavy Grow scripts while keeping the plugin active in the dashboard. The snippet hooks into WordPress and prevents the specific JavaScript files from being loaded on the front end:
“`php
function dailingua_remove_grow_scripts() {
global $wp_scripts;
foreach ( $wp_scripts->registered as $handle => $script ) {
if ( strpos( $handle, ‘grow’ ) !== false ) {
wp_dequeue_script( $handle );
}
}
}
add_action( ‘wp_enqueue_scripts’, ‘dailingua_remove_grow_scripts’, 999 );
“`
After adding this snippet, the Best Practices score returned to 100, and the LCP improved further. The cosmetic third‑party cookie warning remained in PageSpeed Insights, but this warning is about phasing out third‑party cookies and does not affect actual performance or search rankings. The snippet gave me the best of both worlds: the plugin remained available for future use without degrading the current site.
The Final LiteSpeed Cache Configuration
After applying all seven fixes, I ended up with a set of LiteSpeed Cache settings that produced the 98 mobile score consistently. Here is the exact, tested configuration:
Setting Value
Lazy Load Images OFF
Lazy Load Iframes OFF
Add Missing Dimensions OFF
Responsive Placeholder OFF
Load CSS Asynchronously OFF
Generate Critical CSS OFF
Load JS Deferred OFF
Delayed JS OFF
Image Optimization ON (lossy, EXIF removed)
Next‑Gen Image Format OFF (pre‑converted to WebP)
Preload LCP Image snippet ACTIVE
Block Grow Scripts snippet ACTIVE (if Grow is installed)
All other caching settings page cache, browser cache, object cache were left at their defaults. LiteSpeed Cache handles these well out of the box. This configuration is the result of testing each setting individually and keeping only what produced a measurable improvement.
How to Retest and Verify Your Score
After applying each fix I retested to confirm the improvement. Here is the exact process I used:
1. Purge all caches in LiteSpeed Cache, I clicked Purge All. Then I went to my hosting control panel (Hostinger hPanel → Cache Manager) and also purged the server‑level cache there.
2. Open a private/incognito window to avoid my logged‑in WordPress session affecting the test.
3. Go to https://pagespeed.web.dev.
4. Enter the URL of a single post – the same one I tested initially.
5. Click Analyze and wait for the results (about 15–30 seconds).
6. Check the mobile Performance score and the LCP time.
If the score was still below 90, I reopened the PageSpeed report and looked at the updated “Diagnostics” section. It told me what remained slow. I repeated the diagnostic framework and addressed the next issue. This cycle continued until the score reached 98 and the LCP was under 1.6 seconds.
Why 98 Is Better Than 100
A perfect 100 PageSpeed score often requires removing every third‑party script, including analytics and ad trackers. That is not realistic for a blog that plans to earn revenue. A score of 98 represents a site that is:
· Blazing fast for real users.
· Resilient to future Chrome updates.
· Still able to run necessary plugins (Grow, Rank Math, etc.).
The remaining Best Practices warnings third‑party cookies from Grow’s login iframe are cosmetic. They do not affect search rankings or user experience. Google’s own documentation confirms that these warnings are about phasing out third‑party cookies, not about site speed. I learned to stop when the Core Web Vitals were all green and the site felt instant on a phone. Any further tweaking risked breaking functionality without any real benefit to readers the principle of knowing when the work is done is something I apply to every writing session and every site project.
The One‑Minute Monthly Speed Audit
Performance is not a one‑time fix. Plugins update, new content is added, and hosting environments change. To keep the score stable, I run a brief monthly audit:
1. Run a PageSpeed test on the top 3 most‑visited articles (mobile).
2. Check the Lighthouse report for any new red or orange warnings.
3. Open the Redirection plugin’s 404 log – if I see broken resources, I fix them.
4. Go to Plugins → Installed Plugins and note any that have been updated. If a plugin added new scripts, I test again.
5. If everything is green, I close the tab. If not, I refer back to this guide.
This monthly routine has kept my site at 98 through multiple plugin updates and content additions. It is the maintenance equivalent of a daily blogging routine that makes consistent publishing feel normal.
Complete Code Snippet Library
Below is every snippet I used, collected in one place for easy copying.
Preload Single Post Featured Image:
“`php
function dailingua_preload_single_featured_image() {
if ( is_singular( ‘post’ ) && has_post_thumbnail() ) {
$image_url = get_the_post_thumbnail_url( get_the_ID(), ‘full’ );
if ( $image_url ) {
echo ‘<link rel=”preload” as=”image” href=”‘ . esc_url( $image_url ) . ‘” fetchpriority=”high”>’;
}
}
}
add_action( ‘wp_head’, ‘dailingua_preload_single_featured_image’, 1 );
“`
Block Grow Scripts (keep plugin active, remove bloat):
“`php
function dailingua_remove_grow_scripts() {
global $wp_scripts;
foreach ( $wp_scripts->registered as $handle => $script ) {
if ( strpos( $handle, ‘grow’ ) !== false ) {
wp_dequeue_script( $handle );
}
}
}
add_action( ‘wp_enqueue_scripts’, ‘dailingua_remove_grow_scripts’, 999 );
“`
Homepage LCP Preload (optional, if your homepage shows latest posts):
“`php
function dailingua_preload_lcp_image() {
if ( is_front_page() || is_home() ) {
$latest_post = get_posts( array( ‘numberposts’ => 1 ) );
if ( ! empty( $latest_post ) && has_post_thumbnail( $latest_post[0]->ID ) ) {
$image_url = get_the_post_thumbnail_url( $latest_post[0]->ID, ‘full’ );
if ( $image_url ) {
echo ‘<link rel=”preload” as=”image” href=”‘ . esc_url( $image_url ) . ‘” fetchpriority=”high”>’;
}
}
}
}
add_action( ‘wp_head’, ‘dailingua_preload_lcp_image’, 1 );
“`
These snippets are the permanent toolkit that came out of the optimization week. I keep them saved in a dedicated file and can add them to any new site in minutes.
The Real‑World Impact of a 98 Mobile Score
I did not optimize for a number in a testing tool. I optimized for the reader on a phone with a weak signal who opens an article and wants the text to appear instantly. The 98 score was validation, but the real result was what happened after the fixes went live.
Before the optimization, the average session duration had dropped sharply after the migration, and the bounce rate had risen. These metrics were affected by many factors, but page speed was one of them. After the LCP dropped from 3.9 seconds to 1.5 seconds, I noticed a gradual improvement in how long readers stayed on the page. The bounce rate began a slow but steady decline over the following weeks. These changes were not dramatic, but they were consistent, and they confirmed that speed directly influences whether someone reads an article or leaves before it loads.
The Core Web Vitals report in Google Search Console also shifted. Before the fixes, the report showed a number of pages in the “needs improvement” category for LCP. After the fixes, every page moved into the “good” category. Google uses these vitals as a ranking signal, so a site with all green vitals has a measurable advantage over one with orange or red warnings. The speed work was not just about a score; it was about giving every article the best possible chance to be found and read.
The 98 score was not the goal the goal was a site that felt instant on a phone and had no technical barriers between the content and the reader. The score was simply the confirmation that the barriers were gone this principle of focusing on the real outcome rather than the metric is what I apply to every piece of content I publish.
Common Mistakes That Undo Speed Fixes
During my testing week I made several mistakes that temporarily reversed my progress. I want to document them so they can be avoided.
Mistake 1: Forgetting to purge all caches. LiteSpeed Cache has multiple cache layers page cache, CSS/JS minify cache, and browser cache. If I changed a setting and ran a PageSpeed test without purging all of them, the test would show the old, slow version of the page. I learned to click “Purge All” in LiteSpeed and also clear the server‑level cache in my hosting panel before every test.
Mistake 2: Testing while logged into WordPress. The WordPress admin bar adds scripts and styles that are not present for regular visitors. If I ran a PageSpeed test while logged in, the results were artificially low. I learned to always use a private or incognito window, with no WordPress session active.
Mistake 3: Applying multiple fixes at once without testing individually. I initially turned off five settings at once and could not tell which one had the greatest impact. I learned to change one setting, test, record the result, then move to the next. This allowed me to build the exact configuration that produced the 98 score, and to know which settings were essential and which were optional.
Mistake 4: Assuming that a faster desktop score meant a faster mobile score. The mobile test uses a simulated slower network and a less powerful device. A site that scores 100 on desktop can still score 87 on mobile if the LCP image is too large or if render‑blocking resources are present. I learned to always test on mobile first.
These mistakes are common because they are easy to make. I now keep a checklist next to me whenever I work on site speed, and I follow it in order. The checklist‑based discipline is what I use when planning and executing any long‑term site project.
How Different Hosting Environments Affect These Settings
The exact configuration that produced the 98 score was tested on a LiteSpeed server with Hostinger. If the site were hosted on a different server type Apache, Nginx, or a managed WordPress host without LiteSpeed the caching settings would be different, but the underlying principles would remain the same.
On a non‑LiteSpeed server, the lazy loading, asynchronous CSS, and JavaScript defer settings would be managed through a different caching plugin or through manual code. The preload snippet and the Grow script blocker would work identically, because they are simple PHP functions that hook into WordPress. The image optimization would be handled by a different tool or by pre‑compressing images before upload.
The principles that transferred to any hosting environment were these: stop lazy‑loading the LCP element, eliminate render‑blocking resources, preload the featured image, and remove unused plugin scripts. The specific plugin and its settings might change, but the diagnostic framework remained the same. I learned that speed optimization is not about a particular plugin; it is about understanding what delays the page and removing those delays one by one. The principle of adapting the core method to different contexts is what I applied when recovering search traffic after any kind of platform change.
Troubleshooting When the Fixes Do Not Work
Sometimes a fix that worked on one site does not produce the expected result on another. When that happens, I return to the diagnostic framework and investigate deeper.
Issue: LCP did not improve after turning off lazy loading. This can happen if the LCP element is not an image but a text block, such as a large heading. In that case, lazy loading is not the issue. I check the PageSpeed report to confirm what the LCP element is. If it is a text block, the delay is likely caused by a web font loading slowly. I then check the font loading settings and ensure that the font is either a system font or is being loaded with font-display: swap.
Issue: The Best Practices score did not improve after removing Jetpack. Some plugins leave behind database entries or cached scripts that continue to load even after deletion. I use a plugin like WP‑Optimize to clean the database, then purge all caches and retest. I also check the page source to confirm that no references to the deleted plugin remain.
Issue: The preload snippet caused a console error. This usually means the featured image URL is empty or the function is running on pages that do not have a featured image. I wrap the code in an additional check for has_post_thumbnail() and confirm that the image URL is not empty before echoing the preload tag. The snippet I provided already includes these checks.
Issue: The score fluctuates between tests. PageSpeed Insights results can vary slightly between runs due to network conditions and server load. I run the test three times and take the median score. If the variation is large more than five points I check whether the server is under heavy load or whether a background process is consuming resources.
Troubleshooting speed issues is a process of elimination, not a single answer. Each symptom points to a different root cause, and the diagnostic framework provides the structure for finding it. The patience and systematic approach is what I use when writing through doubt and technical challenges without stopping.
The Connection Between Speed and Search Rankings
Page speed is a direct ranking signal in Google’s algorithm, and the Core Web Vitals are part of the page experience update. A site that passes all three Core Web Vitals has an advantage over a site that fails them, especially in mobile search results where speed is weighted more heavily.
After my site’s LCP dropped into the green zone, I noticed a gradual increase in the number of pages that Google chose to index. The indexation jump from 14 to 70 pages was primarily due to the redirect map and content fixes, but the improved speed gave Google a reason to crawl more pages in the same amount of time. A faster site allows Googlebot to process more URLs with the same crawl budget, meaning more content gets indexed and more opportunities for search traffic.
Speed also affects the user signals that indirectly influence rankings. If a page loads in under two seconds, the reader is far more likely to stay and engage. If it takes over four seconds, the probability of them leaving before it loads is high. Those engagement signals time on page, pages per session, bounce rate are not direct ranking factors, but they correlate with the kind of content that Google wants to rank. A fast site is a site that serves its readers, and search engines reward that.
The speed work I did after the migration was not separate from the SEO work. It was the foundation that allowed the SEO work to succeed. The integration of technical and content strategy is what I apply to every piece of the site’s long‑term growth plan.
How LiteSpeed Cache Works Under the Hood
Understanding what LiteSpeed Cache actually does helps explain why certain settings have such a large impact. LiteSpeed Cache is a server‑level caching plugin that integrates with the LiteSpeed web server. It can store fully rendered HTML pages in memory and serve them directly to visitors without executing PHP or querying the database. This is why page caching alone can make a site feel dramatically faster.
Beyond page caching, LiteSpeed Cache optimizes CSS and JavaScript by minifying, combining, and inlining them. It can also lazy‑load images and iframes, defer JavaScript execution, and generate critical CSS. Each of these features has a specific purpose, and each one can either help or hurt performance depending on how it is configured for the specific site.
The key insight I learned was that optimization features are not universally beneficial. Lazy loading helps pages with many images but hurts the LCP if it delays the featured image. Asynchronous CSS helps if a critical CSS fallback is present, but hurts if it is not. JavaScript deferral helps if the theme loads many scripts in the header, but can break functionality if the theme expects those scripts to load synchronously.
The art of configuring LiteSpeed Cache is not about turning everything on. It is about turning on only what the site needs and verifying each setting with a test. The configuration that produced my 98 score was the result of turning several settings off settings that are often recommended as optimizations because they were not helping my specific site. The principle of testing rather than blindly following recommendations applies to every configuration decision I make for the site.
Testing on Real Mobile Devices
PageSpeed Insights simulates a mobile device, but it does not replace testing on an actual phone. After I achieved the 98 score, I opened the site on several physical devices: an older Android phone on a cellular connection, a newer iPhone on a home Wi‑Fi network, and a tablet with an intermittent signal.
On every device, the page appeared ready to read in under two seconds. I tapped links, scrolled through articles, and checked that images loaded progressively without blocking the text. I noticed that on the older phone, the page felt slightly slower than on the new one, but it was still well within the range where a reader would stay. I also tested with the device in airplane mode to confirm that cached pages loaded instantly from the service worker cache, and they did.
Testing on real devices is the final confirmation that the speed settings are working for actual readers, not just for a testing tool. I now include a physical device test in my monthly audit, because an update to the theme or a plugin can sometimes introduce regressions that only appear on certain devices the commitment to testing on real devices is what I use when ensuring that every article reads well on any screen size.
The Role of a CDN in Page Speed
A Content Delivery Network stores copies of the site’s static files images, CSS, JavaScript on servers around the world. When a reader visits the site, the CDN serves those files from the server closest to them, reducing the physical distance the data must travel and lowering latency.
My site uses the CDN integrated into my hosting provider. I did not need to configure it separately because it was automatically enabled for static assets. However, I checked that the CDN was caching the featured images and the preloaded LCP image correctly. I also ensured that the CDN’s SSL mode was set to Full or Full Strict, so that HTTPS connections were properly terminated and no mixed content warnings appeared.
For sites that do not have a CDN, adding one can be the single largest speed improvement after the server‑side fixes are in place. A CDN does not replace the need for a fast theme and optimized images, but it amplifies the benefits of those fixes for readers who are geographically distant from the origin server. I consider a CDN to be part of the baseline configuration for any site that expects a global audience.
The Dailingua Speed Journey From 87 to 98
The journey from the first disappointing PageSpeed test to the stable 98 score took about a week of incremental fixes. I did not work on speed full‑time during that week; I worked on it in the gaps between other migration tasks. Each evening, I would run a test, identify one issue, apply the fix, and retest. The incremental progress kept me motivated because I could see the LCP number dropping with each change.
The most rewarding moment was not when the score hit 98. It was when I opened an article on my phone, tapped the link, and the text appeared before I had finished lifting my finger from the screen. That instant loading was the real goal, and the score was just the number that confirmed it.
I learned that speed optimization is not a mysterious art. It is a process of identifying what is slow and removing the obstacles, one by one. The diagnostic framework, the seven fixes, and the code snippets in this guide are the permanent record of that process. They are reusable, testable, and grounded in real data. And they have kept my site fast through every change that has come since.
The work of making a site fast is never finished, but it becomes a habit. Once the settings are in place and the monthly audit is routine, speed takes care of itself. The site stays fast, the readers stay engaged, and the search rankings follow. That is the lesson I carry forward from the week I turned an 87 into a 98.
A Detailed Walkthrough of the Diagnostic Steps
When I ran the first PageSpeed test, I did not immediately jump to the fixes. I spent time understanding the report so I knew exactly what to change. Here is a more detailed walkthrough of how I read the report.
Finding the LCP element. In the PageSpeed report, under the “Diagnostics” heading, there is a line called “Largest Contentful Paint element.” Clicking it reveals a small preview of the element and its HTML tag. For my site, it showed an <img> tag with the class wp-post-image. This told me the featured image was the LCP element. I noted the image URL and its file size. The file size was already small under 50 KB so I knew the problem was not the image size but the time it took to start downloading.
Reading the waterfall chart. The report includes a waterfall that shows every network request, when it started, and how long it took. I looked at the request for the featured image and saw that it did not start until well after other requests had finished. This confirmed that something was delaying the image from being discovered by the browser.
Checking the Opportunities section. The “Opportunities” section of the report lists specific actions that will improve the score. For my site, it listed “Eliminate render‑blocking resources” and “Reduce unused JavaScript.” I clicked into each opportunity to see which specific files were flagged. The render‑blocking resources included a CSS file from Jetpack and a JavaScript file from Grow. The unused JavaScript included several scripts from Jetpack that were loaded on every page but used nowhere.
Prioritizing the fixes. I sorted the opportunities by the estimated time savings they would provide. Eliminating render‑blocking resources had the largest estimated savings, so I started there. Reducing unused JavaScript was second. After those two, the remaining opportunities were small and optional. I focused on the fixes that would have the greatest impact first, and I left the small ones for later.
This detailed walkthrough is the method I now use on any site, and it turns a confusing report into a clear action plan. The ability to read data and extract a plan is what I use when analyzing search console data to understand traffic changes.
Common Myths About WordPress Speed
During my research, I encountered several pieces of advice that turned out to be either misleading or only partially true. I want to address them directly.
Myth 1: More plugins equal a slower site. The number of plugins does not directly affect speed; the quality and size of the plugins do. A site with ten lightweight plugins can be faster than a site with two heavy ones. I now evaluate plugins by their impact on PageSpeed, not by their count.
Myth 2: A caching plugin is all you need for speed. Caching helps, but it cannot fix a slow theme, large unoptimized images, or render‑blocking scripts. Caching is a layer on top of the site’s code; if the underlying code is slow, the first uncached visit will still be slow, and search engines often see the uncached version. I learned to fix the root causes first and use caching as reinforcement.
Myth 3: A 100 score is always better than a 98. As I explained, a 100 often requires sacrificing functionality that matters. The goal is a site that is fast and functional, not a perfect score that breaks essential features.
Myth 4: You need to be a developer to fix speed. The fixes I applied required no development skills beyond copying and pasting code snippets into the right place. Most of the improvements came from changing settings in a plugin interface. Anyone with access to the WordPress dashboard and LiteSpeed Cache can follow these steps.
Dispelling these myths is part of making speed optimization accessible the cutting through bad advice to find what actually works is something I apply to every area of building a digital asset.
How the Fixes Interact The Cumulative Effect
Each fix I applied had a measurable impact on its own, but the real power came from the way they interacted. Turning off lazy loading for the featured image made the image discoverable earlier. Adding the preload tag told the browser to prioritize it above all else. Removing Jetpack and blocking Grow scripts eliminated the render‑blocking resources that were queued ahead of the image. Together, these changes reduced the LCP from 3.9 seconds to 1.5 seconds.
If I had only applied one fix say, only preloading the image the improvement would have been smaller because the render‑blocking scripts would still have delayed the preloaded request. If I had only removed Jetpack, the LCP would have improved but the image would still have been delayed by lazy loading. The fixes worked as a system, each one removing a different obstacle in the critical loading path.
The lesson is that speed optimization is not about finding a single magic setting. It is about clearing the entire path from the server to the reader’s screen. Each fix is one obstacle removed, and the cumulative effect is what transforms a slow site into a fast one. The systemic thinking is what I apply to every technical system on the site, from redirects to DNS.
The Speed Toolkit I Carry Forward
I now have a permanent toolkit that I can apply to any WordPress site running LiteSpeed Cache. The toolkit includes the diagnostic framework, the seven fixes, the final settings table, the code snippet library, and the monthly audit routine. I can run through the entire process in under an hour on a new site, and I can restore the settings in minutes if they ever drift.
This toolkit is not a set of abstract principles. It is a concrete, tested method that produced a specific, measurable result on a real site. The 98 score is not a claim; it is a data point I can reproduce by importing the same settings and the same snippets. I share this toolkit here because I believe that a fast site should be accessible to every publisher, not just those who can hire a developer.
The seven fixes I applied turning off lazy loading for the LCP image, disabling asynchronous CSS, turning off JavaScript defer and delay, preloading the featured image, optimizing every image, removing bloated plugins, and taming Grow are not one‑time tweaks. They are permanent settings that form the foundation of a fast site. The diagnostic framework that identified the LCP element and the render‑blocking resources is repeatable on any WordPress site running LiteSpeed Cache. I have used it on staging sites, on new installations, and on client sites, and it has never failed to improve the score when applied methodically.
What I learned during that week of testing is that speed is not a gift. It is a discipline. It requires testing, measuring, and refusing to accept a slow page as normal. The tools are free, the settings are accessible, and the code snippets are just a few lines. The barrier to a 98 mobile score is not technical skill; it is the willingness to open PageSpeed Insights, look at the LCP number, and decide that it will come down. That diagnostic sequence identify the LCP element, check render‑blocking resources, test by disabling suspects, and test each setting individually is now my standard approach for any performance issue. The one‑minute monthly audit ensures that the score does not drift as plugins update and content grows. Speed is not a mystery. It is a series of small, reversible decisions that anyone can make. I made those decisions, and this guide is the result.
The site you are reading now, dailingua.com, loads its articles in under two seconds on a phone because of the work documented in this guide. That speed is not an accident. It is the result of a week of methodical testing, a commitment to evidence over assumptions, and the willingness to keep tweaking until the numbers told me I was done. I wrote this guide to be the reference I wish I had when I stared at an 87 on my phone and wondered if it could ever be fixed. It can. And now you have the exact roadmap.