I optimize every image for my WordPress site before I upload it by running it through a two‑tool workflow that converts it to WebP, compresses it to under 100 kilobytes, and preserves visual clarity at 1200 pixels wide. I learned this process after a single unoptimized featured image dragged my entire site’s Largest Contentful Paint to 3.9 seconds and dropped my mobile PageSpeed score to 87.
That image was a 2‑megabyte JPEG, loaded at full resolution, and on a slow mobile connection it consumed most of the loading budget before a reader saw a single word. After I built the workflow I describe in this guide, that image became a 68‑kilobyte WebP file visually identical to the original and my LCP dropped to 1.5 seconds. The mobile score climbed to 98 and has stayed there ever since. This was not the result of expensive software or a hosting upgrade. It came from a repeatable, manual process that takes about two minutes per image and guarantees that no file I publish slows down a reader.
The Real Cost of One Unoptimized Image
I learned the cost of an unoptimized image the first time I ran a PageSpeed Insights test after migrating my site from Blogger to WordPress. The report flagged the featured image on a single post as the LCP element. The image was a 2‑megabyte JPEG a screenshot I had taken, saved at full resolution, and uploaded without a second thought. On a fast desktop connection, it loaded acceptably. On a simulated mobile connection, the browser spent nearly four seconds downloading and rendering that single file before the page became readable.
I had not thought about image size before that moment. I assumed that if the image looked clear, it was fine. The PageSpeed report showed me the truth: that one image was the bottleneck. Every other optimization I could apply caching, minification, script deferral would not fix the fact that the largest element on the page was simply too large. I had to change how I prepared images, not just how I served them.
The solution was not to compress images into blurry, artifact‑filled approximations. I tested aggressive compression tools that promised tiny file sizes, and the results were unusable text became illegible, edges smeared, and the professional feel of the site evaporated. I needed a method that reduced file size without any visible quality loss the two‑tool workflow I landed on AnyWebP for resizing and conversion, TinyPNG for final compression gave me exactly that. The 2‑megabyte JPEG became a 68‑kilobyte WebP that I could not distinguish from the original in a side‑by‑side comparison.
The real cost of an unoptimized image goes beyond a slow page. Every extra kilobyte increases the chance that a reader on a weak connection leaves before the page finishes loading. Search engines measure Core Web Vitals like LCP and use them as ranking signals. A site with LCP above 2.5 seconds is at a measurable disadvantage. Before the optimization, my LCP was 3.9 seconds, and my indexed pages were growing slowly. After bringing LCP down to 1.5 seconds, Google crawled my site more efficiently, and the indexed count rose from 14 to 70 pages in a single update. Speed and indexation are connected. The discipline of fixing the root cause rather than chasing symptoms is what I applied to build a self‑discipline system that keeps the entire site consistent.
The Dailingua Image Optimization System
Most image optimization guides focus on a single metric: file size. I focus on a different question: can I make this image so small that it loads instantly, while keeping it so sharp that a reader never notices it was compressed? The answer requires four principles that now govern every image I publish.
The first principle is to start with the right dimensions. A blog post never needs a 5000‑pixel‑wide image. My content area is about 1200 pixels wide on desktop, so every image I prepare is sized to 1200 pixels wide with the height scaling proportionally. This alone discards millions of unnecessary pixels before any compression happens. The second principle is to convert to WebP before upload. WebP offers dramatically smaller file sizes than JPEG or PNG at equivalent quality, and every modern browser supports it. The third principle is to compress in two stages a coarse resize and conversion pass, followed by a fine lossy compression pass that preserves sharpness. The fourth principle is never to sacrifice visual clarity. Every compressed image is checked against the original. If it looks blurry or shows artifacts around text, it is rejected and reprocessed.
This system is applied manually to every image I use on dailingua.com. The workflow takes about two minutes per image and guarantees that no file exceeds 100 kilobytes, while the vast majority land between 50 and 80 kilobytes. The result is a media library where every image is WebP, every image is correctly sized, and every image loads as fast as the server can deliver it.
But beyond the technical steps, the philosophy is about building a habit. When I first started, I would occasionally skip the compression step because I was in a hurry. That one unoptimized image would then become the LCP bottleneck on a new post, and I would have to go back and fix it. The habit of running every image through the workflow, every time, without exception, is what ensures consistent speed for building quality into the process rather than fixing problems to choosing a WordPress theme that will not slow down the site.
The Pre‑Upload Workflow: The Two‑Tool Method
The workflow I use before uploading any image to WordPress has two stages, and it uses two free tools that require no installation. I follow these steps every time, and they produce consistent results regardless of whether the source image is a screenshot, a photograph, or a graphic.
Choosing the Right Source Image Dimensions
Before I open any tool, I decide on the maximum display width. My content area is 1200 pixels wide on desktop, so there is no reason to serve an image wider than that. If the image is a horizontal photograph or a full‑width screenshot, I set the width to 1200 pixels and let the height scale proportionally. If the image is vertical, I set the width to 900 pixels as a maximum and let the height adjust. This initial sizing discards the unnecessary pixels that make up the bulk of a large file. The browser will never display the image wider than the content area, so every pixel beyond that limit is wasted bandwidth.
For Retina or HiDPI displays, which have twice the pixel density, a 1200‑pixel‑wide image still looks sharp because the browser can scale it up slightly without visible degradation. I have tested my images on a Retina MacBook and an iPhone, and the quality at 1200 pixels is indistinguishable from a larger source. If I ever needed to serve higher‑resolution images for photography sites, I would use the srcset attribute to provide a 2x version, but for a content blog, 1200 pixels is the ideal balance of sharpness and file size.
Tool 1: AnyWebP Resize and Convert
AnyWebP is a free, browser‑based converter. I open the site, drag in my original image, and set the Width to 1200 while leaving Height blank. This keeps the aspect ratio intact. I choose WebP as the output format and click Convert. The original 2‑megabyte JPEG becomes a WebP file weighing roughly 100 to 150 kilobytes. That is already a massive reduction, but I take it one step further.
AnyWebP also allows adjusting the quality slider. The default setting produces excellent results, but for images with fine text, I sometimes increase the quality slightly to prevent any softening. The tool shows a live preview, so I can compare the original and the converted version side by side before downloading. This preview step saves me from downloading a file only to reject it later.
Tool 2: TinyPNG Final Compression
TinyPNG compresses WebP files using intelligent lossy compression that reduces file size without introducing visible blur. I upload the WebP from AnyWebP, wait a few seconds for the compression to finish, and download the result. A 150‑kilobyte WebP typically compresses to 50 to 80 kilobytes with no perceptible quality loss. This two‑step process is the core of the workflow.
TinyPNG works by reducing the number of colors in the image where the changes are not noticeable, and by applying advanced algorithms that preserve edges and text. I have uploaded the same image to TinyPNG multiple times, and the output is consistent. The free tier allows up to 20 images at a time, which is more than enough for a single article’s worth of images. For bulk optimization of older images, I use the LiteSpeed Cache image optimization feature, but for new content, the manual two‑tool workflow gives me full control.
Quality Check and File Naming Rules
After compression, I open the final WebP and compare it side‑by‑side with the original. I zoom in on text or fine details. If I see any blur or blocky artifacts, I go back to AnyWebP and adjust the resize width slightly usually reducing it to 1000 pixels is enough to eliminate compression artifacts on text‑heavy screenshots. The default settings almost always produce perfect results, but I never skip the check.
Once the image passes, I rename the file on my desktop using five to seven words that describe exactly what is in the image, separated by hyphens. Examples from my own media library include wordpress-page-speed-score-98-mobile.webp and litespeed-cache-image-optimization-settings.webp. I never leave a filename as IMG_20260501.webp. Descriptive filenames help search engines understand the image content, and they make the media library searchable when I need to find an image later.
The file naming convention I follow is simple: all lowercase, hyphens between words, no stop words like “a” or “the,” and no underscores. The filename becomes the default title in WordPress, so a clean filename means a clean title. I delete the original large files and keep only the final WebP versions, which keeps my local storage clean and prevents accidental uploads of unoptimized versions.
Batch Processing for Multiple Images
When I have a long article with many images, I process them in batches. I open AnyWebP in one tab and TinyPNG in another. I drag all the source images into AnyWebP, set the dimensions for each, convert, and then move the resulting WebP files to TinyPNG. The entire batch for a dozen images takes about ten minutes. The time investment is small relative to the performance gain, and it becomes faster with repetition the methodical approach to preparation is what I use for structuring a long‑form guide that readers can actually finish.
Advanced Compression Techniques for Different Image Types
Not all images compress equally. I learned through testing that screenshots with text require different treatment than photographs or graphics with flat colors. Applying the settings to every image can result in blurry text or unnecessarily large files.
Screenshots and Images With Text
Screenshots of dashboards, settings panels, or code editors contain fine text that is easily blurred by aggressive compression. For these images, I use a slightly higher quality setting in AnyWebP moving the quality slider to 90 or 95 instead of the default 80. This preserves the sharpness of the text while still producing a file under 100 kilobytes in most cases. I also pay extra attention during the quality check, zooming in to 200% to ensure every letter remains crisp. If the text appears soft, I reduce the resize width to 1000 pixels, which gives the compression algorithm more room to preserve details.
Photographs
Photographs with natural scenes, gradients, and no sharp text are the most forgiving. I can use the default AnyWebP quality setting and apply TinyPNG compression without visible loss. These images often compress the most a 2‑megabyte photo can become a 40‑kilobyte WebP and still look excellent. The key is the 1200‑pixel width cap, which already removes the bulk of unnecessary data.
Graphics with Flat Colors
Logos, icons, and illustrations with large areas of solid color are best saved as PNG‑8 or SVG. If the image is a simple graphic, I use an SVG file directly, as SVGs are vector‑based and scale infinitely with zero file size penalty. For PNGs, I use TinyPNG alone, as it excels at reducing the color palette of PNG images without visible change. I do not convert these to WebP because the lossy compression can introduce artifacts around sharp edges that are more noticeable than on photographs.
Handling AVIF as a Future Option
AVIF is a newer image format that offers even better compression than WebP. However, browser support is not yet universal, and WordPress does not natively handle AVIF in all cases. I plan to adopt AVIF when support is widespread and when LiteSpeed Cache adds seamless AVIF conversion. For now, WebP is the best balance of compression, quality, and compatibility, and the workflow I have built is optimized for it.
Understanding how different image types respond to compression allows me to tailor the workflow and avoid the frustration of blurry screenshots or bloated graphics. The principle of tailoring the approach to the specific situation is to every technical decision I make for the site.
Uploading to WordPress: Metadata That Matters
After the image is compressed and renamed, I upload it through WordPress dashboard → Media → Add New. Because I renamed the file on my desktop, the filename is set permanently. WordPress uses this filename as the default title, but I fine‑tune the other metadata fields while the upload is fresh.
Alt Text: One Descriptive Sentence
The alt text describes what is in the image for screen readers and search engines. I write one natural sentence that includes the core subject and, when relevant, a keyword the post is targeting. I keep it under 120 characters. An example from my site: “A dark graphite bridge arch with an amber‑gold sun rising above it, the Dailingua favicon.” For informational images, I always write a meaningful description. For purely decorative images like background patterns, I leave the alt text empty.
Writing good alt text is not about keyword stuffing. It is about accurately describing the image so that a person who cannot see it understands its content. Search engines use alt text to index images and to understand the context of the page. An image with descriptive alt text is more likely to appear in Google Image Search, which can drive additional traffic.
Title Attribute and Caption
WordPress uses the filename as the default title. Because I rename files with descriptive phrases before upload, the title is already useful. I leave it as is unless the filename needs minor cleanup. The auto‑clean snippet I added to the site removes hyphens and capitalizes words, so the title reads like a natural phrase rather than a string of hyphenated words.
Captions are optional. I add a caption only when the image requires an explanation that the surrounding text does not provide. When I use a caption, I write a short, neutral sentence. I never use captions for keyword stuffing, as that degrades the reading experience and can be penalized by search engines.
The Cumulative SEO Value of Metadata
Each image I upload with proper alt text and a clean filename adds to the site’s overall search visibility. Over dozens of articles, the cumulative effect of well‑optimized images is significant. Google Image Search can become a consistent source of traffic, and the metadata I add during upload is the foundation of that traffic and how to keep old articles fresh through regular editing routines.
WordPress Settings That Keep Images Light
WordPress has built‑in behaviors that can work against manual image optimization. I use two code snippets to lock them down and keep the media library lean.
Disabling the Big Image Threshold
WordPress automatically scales images that exceed 2560 pixels in width. Since all my images are already capped at 1200 pixels, this feature is unnecessary and can create extra resized copies that clutter the server. I disable it with a code snippet added through the Code Snippets plugin or my theme’s functions.php file:
php
add_filter( ‘big_image_size_threshold’, ‘__return_false’ );
Auto‑Cleaning Image Titles From Filenames
When I upload an image, WordPress uses the filename with hyphens as the title. This snippet automatically removes hyphens and capitalizes words, making the title cleaner for internal use. I add this once and it runs on every future upload:
php
add_action( ‘add_attachment’, ‘tp_set_image_meta_upon_image_upload’ );
function tp_set_image_meta_upon_image_upload( $post_ID ) {
$post_obj = get_post( $post_ID );
if ( ! $post_obj ) return;
$post_title = $post_obj->post_title;
$post_title = str_replace( ‘-‘, ‘ ‘, $post_title );
$post_title = ucwords( strtolower( $post_title ) );
$my_image_meta = array(
‘ID’ => $post_ID,
‘post_title’ => $post_title,
);
remove_action( ‘add_attachment’, ‘tp_set_image_meta_upon_image_upload’ );
wp_update_post( $my_image_meta );
add_action( ‘add_attachment’, ‘tp_set_image_meta_upon_image_upload’ );
}
Managing Thumbnail Sizes
WordPress generates several resized copies of each uploaded image thumbnail, medium, large, and potentially others depending on the theme. Many of these sizes are never used and bloat the server. I review the dimensions in WordPress dashboard → Settings → Media and set any unused size to zero in both width and height fields. I do not disable sizes that my theme actively relies on for example, the featured image in GeneratePress may use the medium_large size. I leave the defaults for sizes I use and let LiteSpeed Cache handle further optimization of those copies.
To see which sizes are actually used, I check my theme’s template files or use a plugin that identifies the registered image sizes. I then set unused sizes to zero. This prevents WordPress from generating unnecessary files during upload, saving disk space and reducing the work LiteSpeed Cache must do during optimization.
These snippets and settings run in the background after the initial setup. I do not think about them during daily publishing because they are configured once and work automatically how to set up systems that run without ongoing attention for maintaining a daily routine that makes consistent publishing feel normal.
LiteSpeed Cache Image Optimization: The Perfect Companion
Even with manual compression, the LiteSpeed Cache plugin provides an extra layer of optimization that catches any image I may have missed and strips unnecessary metadata from the copies WordPress generates.
I configure the image optimization settings at WordPress dashboard → LiteSpeed Cache → Image Optimization. The exact settings I use are:
Setting State Reason
Auto Request Cron ON Automatically pulls optimized images from the server
Optimize Original Images ON Applies lossy compression to full‑size originals
Remove Original Backups OFF (initially) Keep backups until optimization is verified
Optimize Losslessly OFF Lossy compression yields much smaller files with no visible quality loss
Preserve EXIF/XMP data OFF Removes hidden camera metadata, reducing file size
WebP Replacement OFF Prevents double processing since I pre‑convert all images to WebP
WebP For Extra srcset ON Generates WebP versions for responsive sizes without affecting manually compressed originals
After saving these settings, I click Send Optimization Request. The plugin processes all images in the media library, including the resized copies WordPress generated during upload. This step further reduces the size of thumbnails, medium, and large versions, ensuring that every variant of every image is as small as possible.
The optimization request sends the images to LiteSpeed’s optimization server, where they are compressed and returned. The process can take a few minutes depending on the number of images. Once complete, the plugin replaces the original files with the optimized versions. I always verify a few images after optimization to ensure the quality is acceptable. The lossy compression is conservative and has never produced visible artifacts on my images.
This configuration complements the manual workflow rather than replacing it. The manual workflow handles the largest files the full‑size featured images and in‑post images with precision. The LiteSpeed Cache optimization then cleans up everything else, including images I might have uploaded before implementing the workflow. This layered approach of combining manual precision with automated consistency is what I use for setting up page speed settings that took my mobile score from 87 to 98.
Bulk Optimizing Existing Images
If I had a large library of unoptimized images from before the migration, I would run the LiteSpeed Cache image optimization on the entire media library first, then manually reprocess any featured images that were particularly large. The bulk optimization handles the repetitive work, and the manual workflow handles the precision work. For dailingua.com, I had already compressed most images manually before upload, so the LiteSpeed optimization was a final cleanup step.
Optimized files are only half the equation. How the browser fetches those files determines whether the LCP stays low. I use three specific tweaks to ensure images load as fast as possible.
Preload the Featured Image on Single Posts
The featured image is almost always the LCP element on a blog post. A preload tag inserted into the page’s <head> tells the browser to fetch that image immediately, before it finishes parsing the rest of the HTML. This single directive overrides the normal resource discovery process and starts the download at the highest priority. I added this code snippet, which 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 );
I verify the preload is working by viewing the page source of any single post and searching for <link rel=”preload”. The tag should appear near the top of the <head>. If it does not, I check that the post has a featured image set and that the snippet is active.
Stop Lazy‑Loading Above‑the‑Fold Images
Lazy loading delays image loading until the image is near the viewport. For images far down the page, this saves bandwidth. For the featured image the LCP element lazy loading is a performance disaster. It forces the browser to wait until after the entire page is interactive before it even starts fetching the most important visual element.
In WordPress dashboard → LiteSpeed Cache → Page Optimization → Media Settings, I set Lazy Load Images to OFF. For sites that want to keep lazy loading for other images while excluding the featured image, there is an Exclude by Class field where I can add wp-post-image the CSS class that WordPress automatically assigns to featured images. This prevents lazy loading only for the featured image while keeping it active for everything else.
I tested both approaches turning lazy loading off entirely gave a slightly faster LCP because the browser discovered all images sooner, but the bandwidth savings from lazy loading below‑the‑fold images were worth keeping it active with the exclusion. I chose the exclusion approach because it gave me the LCP improvement without sacrificing the performance of long articles with many images.
Responsive Images and srcset
WordPress automatically generates a srcset attribute that serves different image sizes to different screen widths. I ensure this feature is enabled it is on by default. When I upload a 1200‑pixel‑wide image, WordPress creates smaller versions, and the browser picks the most appropriate one based on the device width. This is why controlling the maximum uploaded width at 1200 pixels is so effective: it ensures the largest version in the srcset is never wastefully huge.
I also ensure that every image has explicit width and height attributes in the HTML. This allows the browser to reserve the correct amount of space for the image before it loads, preventing Cumulative Layout Shift (CLS). WordPress adds these attributes automatically for images in the block editor, but I check the page source of key posts to confirm they are present. A missing width or height on a featured image can cause the content below it to jump when the image loads, which degrades the CLS score and harms search rankings.
Adding Fetch Priority to the Featured Image
In addition to the preload tag, I ensure the featured image has a fetchpriority=”high” attribute. This is a newer browser feature that signals the image is important for the initial render. The preload tag already handles this for the LCP image, but adding the attribute to the <img> tag itself provides a backup signal. Most modern themes and the block editor do not add this by default, so I use the preload approach as the primary method and rely on the browser to prioritize accordingly.
These three tweaks preloading the LCP image, disabling lazy loading for above‑the‑fold content, and relying on responsive srcset with explicit dimensions work together to deliver the right image size to the right device at the right moment. The systemic thinking is what I apply to every technical system on the site, from redirects to DNS.
Measuring Image Performance With PageSpeed Insights
After applying all optimizations, I verify the results with real data. PageSpeed Insights is my primary tool because it directly measures Core Web Vitals and shows which specific images are causing delays. I run a test on a single post that contains a featured image and several in‑post images, using the mobile tab.
The key metrics I check are:
· LCP: Should be under 2.5 seconds. After optimization, mine is consistently 1.5 seconds.
· CLS: Should be under 0.1. Mine is 0 because all images have explicit dimensions.
· Render‑blocking resources: No images should appear in this list. If they do, it means the preload tag is not working or the image is being lazy‑loaded.
· Properly size images: This audit should show a green pass. If it shows warnings, an image somewhere is larger than its display size, which means I missed the 1200‑pixel cap.
I also use the Network tab in browser Developer Tools to check the actual file sizes and load times. After loading a post, I filter by image requests and confirm that every image is a WebP file under 100 kilobytes. If I find a JPEG or a file over 100 kilobytes, I know an image slipped through the workflow and needs to be reprocessed.
For deeper analysis, I use WebPageTest with a mobile device emulation. The waterfall chart shows exactly when each image starts loading relative to other resources. The preloaded featured image should begin downloading within the first few requests, before CSS and JavaScript files. If it does not, I troubleshoot the preload tag placement.
Testing after every major change or after publishing a batch of new articles ensures the optimization stays effective. I run a quick PageSpeed test on the homepage and the most recent post as part of my monthly maintenance routine. The evidence‑based approach is what I use when structuring a long‑form guide that readers can actually finish.
The Cumulative Impact of Image Optimization on Site Performance
The improvement in LCP from 3.9 seconds to 1.5 seconds was not the only benefit. The cumulative effect of optimizing every image across the entire site has had a measurable impact on several performance metrics.
The total page weight of a typical article dropped from over 2 megabytes to under 500 kilobytes. This reduction means faster load times on every device, lower bandwidth costs, and a better experience for readers on limited data plans. The reduced server load also means the site can handle more concurrent visitors without slowing down.
The Core Web Vitals assessment in Google Search Console shifted entirely into the green. Before optimization, several pages had “needs improvement” for LCP. After optimization, every page passed. This improvement signals to Google that the site provides a good user experience, which contributes to better search rankings.
The indexed page count, as I mentioned, rose from 14 to 70 in a single update after the migration. While the redirect map and content fixes were the primary drivers, the improved page speed gave Googlebot a reason to crawl more pages in the amount of time. A faster site allows the crawler to process more URLs with the same crawl budget, meaning more content gets indexed and more opportunities for search traffic.
Reader engagement metrics also improved gradually. The average session duration, which had dropped sharply after the migration, slowly recovered as pages loaded faster and readers were less likely to abandon the site before the content appeared. The bounce rate, which had spiked to 0.659, began a slow but steady decline. These changes are not dramatic overnight shifts, but the cumulative trend confirms that speed directly influences whether someone stays to read an article or leaves before it loads.
The speed of a site is not a single metric. It is the sum of every image, every script, and every server response. By optimizing the images, I removed the largest single source of delay. The remaining optimizations caching, script management, and hosting configuration were built on that foundation the stacking small improvements to create a large result is for building a content cadence that sustains a site through every phase of its growth.
How Image Optimization Affects Core Web Vitals Beyond LCP
While LCP is the most directly impacted metric, image optimization also influences Total Blocking Time (TBT) and Cumulative Layout Shift (CLS). Understanding how each metric connects to images helps prioritize the right fixes.
Images and Total Blocking Time
TBT measures how long the browser’s main thread is blocked by JavaScript execution. Images themselves do not block the main thread, but the scripts that control image loading lazy loading libraries, animation scripts, or heavy image optimization plugins can. After I removed Jetpack and a social sharing plugin that injected heavy JavaScript, my TBT dropped to near zero. The image optimization workflow did not directly reduce TBT, but the overall performance cleanup that accompanied it eliminated the script bloat that was contributing to the metric.
Images and Cumulative Layout Shift
CLS measures visual stability images are one of the most common causes of layout shift because browsers do not know the image dimensions until the file is downloaded unless explicit width and height attributes are present. WordPress automatically adds these attributes to images inserted through the block editor, but older images imported from Blogger did not have them. I manually added width and height attributes to featured images on key posts, and I now verify these attributes are present on every new upload. The result is a CLS of 0 on every page.
The Compound Effect on Search Rankings
When all three Core Web Vitals pass LCP under 2.5 seconds, CLS under 0.1, and TBT under 200 milliseconds Google considers the page to provide a good user experience. This assessment is a direct ranking signal. A site that passes all three vitals has an advantage over a site that fails them, especially in mobile search results where speed is weighted more heavily. The image optimization workflow I implemented is responsible for the LCP and CLS improvements, which together pushed my Core Web Vitals assessment entirely into the green.
CDN and Image Delivery: Making Optimized Images Even Faster
A Content Delivery Network (CDN) stores copies of the site’s static files on servers around the world. When a reader visits the site, the CDN serves those files from the server closest to them, reducing latency. My hosting provider includes a CDN that automatically caches static assets, including images. After implementing the image optimization workflow, I verified that the CDN was serving the optimized WebP files correctly.
I checked this by inspecting the response headers of an image request. The Server header showed the CDN’s server rather than the origin server, confirming the CDN was delivering the image. The Content-Type header was image/webp, confirming the format was preserved. I also checked that the CDN cache time was set appropriately long enough to benefit repeat visitors, but with a mechanism to purge the cache when images are updated.
For sites that do not have a CDN, adding one is one of the most impactful changes after optimizing images a CDN does not replace image optimization if the image is 2 megabytes, the CDN will serve a 2‑megabyte file faster, but the file is still too large. The combination of optimized images and a CDN delivers the best possible performance. The layering improvements is to choose a hosting plan that can grow with the site.
Bulk Image Optimization for Existing Sites
If a site already has a large library of unoptimized images, the manual two‑tool workflow is impractical to apply to every file. Instead, I use a tiered approach to bulk optimization.
First: I run the LiteSpeed Cache Image Optimization on the entire media library. This applies lossy compression to every image and its resized copies, which provides an immediate improvement without manual effort. The optimization reduces file sizes by 30 to 50 percent on average, depending on the original format and quality.
Second: I identify the images that matter most I sort the media library by attachment page views (if available) or by the date they were uploaded, and I focus on the images that appear on the most‑visited posts. For those priority images, I apply the full manual two‑tool workflow: convert to WebP, compress, and re‑upload. This ensures that the images on the highest‑traffic pages are as optimized as possible.
Third: I replace large featured images on older posts with newly optimized versions. I use the media library to locate the original image, download it, run it through AnyWebP and TinyPNG, and then use a plugin like Enable Media Replace to swap the optimized version in without changing the URL. This preserves any existing internal links or external references to the image.
Finally: I set a recurring monthly task to review the media library sorted by file size and optimize any new images that have been uploaded without going through the workflow. This monthly audit catches images that slip through and keeps the library lean over time the regular maintenance is needed to stay consistent with the habits that keep a site growing over the long term.
Using srcset and sizes for Responsive Images
WordPress automatically generates a srcset attribute that lists the available image sizes and their widths, and a sizes attribute that tells the browser how wide the image will be displayed at different viewport sizes. For a standard blog post with a full‑width featured image, the sizes attribute might look like (max-width: 1200px) 100vw, 1200px. This tells the browser that on screens up to 1200 pixels wide, the image will fill the entire viewport, and on wider screens, it will be 1200 pixels wide.
I ensure that the sizes attribute is accurate for my layout. If the theme uses a sidebar or the content area is narrower on certain pages, the sizes attribute should reflect that. An incorrect sizes value can cause the browser to download a larger image than necessary, negating some of the optimization. Most modern themes handle this automatically, but I verify by checking the page source and confirming that the sizes attribute matches the actual content width.
If I need to customize the sizes attribute for example, on a page with a two‑column layout where the image only fills half the width I can add a filter to wp_calculate_image_sizes. However, for dailingua.com, the default WordPress sizes attribute based on the theme’s content width is accurate, and I have not needed to customize it.
The combination of properly sized source images, correctly generated srcset, and accurate sizes attributes ensures that every device receives the optimal image size. This reduces bandwidth waste and improves LCP across the board.
Image Optimization for SEO: Beyond Alt Text
Image optimization contributes to search visibility in several ways beyond the alt text. The filename, the context of the surrounding content, the page load speed, and the structured data all play a role.
Filename as a Relevance Signal
Search engines use the filename as a relevance signal. A file named how-to-optimize-images-wordpress.webp is more informative than IMG_001.webp. I choose filenames that describe the image content and, when natural, include a primary keyword. I avoid keyword stuffing in filenames, just as I avoid it in text. The filename should read like a short description, not a list of keywords.
Image Sitemaps
WordPress includes images in the main XML sitemap, or a dedicated image sitemap if the SEO plugin supports it. I ensure that the sitemap is submitted to Google Search Console and that images are being discovered. In Google Search Console, under the “Sitemaps” report, I check the number of discovered image URLs. A healthy image sitemap helps Google index images faster, increasing the chance of appearing in Google Image Search.
Structured Data for Images
For articles that include product images, recipes, or other structured content, I ensure that the image is referenced in the structured data markup. The SEO plugin handles this for standard articles by including the featured image in the Article schema. For custom post types, I verify that the image field is mapped correctly in the schema settings.
Page Speed as an SEO Factor
As discussed, page speed is a ranking signal. Image optimization directly improves LCP, which is a Core Web Vital. By reducing image sizes, I improve the overall page speed, which contributes to better rankings. This is the most significant SEO benefit of image optimization, and it compounds across every page on the site.
The Complete Before‑Publish Checklist
Before I click Publish on any article, I run through a detailed checklist that ensures every image meets the standard. This checklist is the final gate between an unoptimized image and my readers.
File Preparation
· The featured image is a WebP file under 100 kilobytes and 1200 pixels wide.
· Every in‑post image is a WebP file under 100 kilobytes.
· All images have been renamed with descriptive, hyphenated filenames (5–7 words).
Metadata
· Alt text is present on every informative image and is under 120 characters.
· Title attributes are clean (the auto‑clean snippet handles this).
· Captions are added only where necessary, and are short and neutral.
Technical Settings
· The preload snippet is active and verified by checking the page source.
· Lazy loading is off for the featured image (either globally or via the wp-post-image exclusion).
· LiteSpeed Cache Image Optimization has been pulled and completed.
· The big image threshold is disabled (snippet active).
Testing
· I run a PageSpeed Insights test on the post and check that LCP is under 2.5 seconds.
· I check the browser Network tab to confirm all images are WebP and under 100 kilobytes.
· I verify that the featured image has a fetchpriority=”high” or preload tag and that width and height attributes are present.
This checklist takes less than a minute to run through because most items are handled automatically by the snippets and settings I have already configured. The only manual items are the file size check and the alt text review the checklist‑based discipline is for planning and executing long‑term site projects without burning out.
Maintaining Image Optimization Over Time
The workflow I have described works for new content, but what about images that were uploaded before the optimization habit was established? When I first migrated to WordPress, I had several dozen images that were not WebP and were larger than necessary. I handled these with a one‑time cleanup process and a monthly audit.
One‑Time Cleanup of Legacy Images
I used the LiteSpeed Cache Image Optimization feature to batch‑process all existing images. After the optimization, I reviewed the media library sorted by file size, identified any images still over 100 kilobytes, and manually reprocessed them through AnyWebP and TinyPNG. For images that were essential featured images on popular posts I replaced them with freshly optimized versions. For images that were decorative or replaceable, I either accepted the LiteSpeed optimization or deleted them.
Monthly Image Audit
Each month, I spend a few minutes reviewing the media library for newly uploaded images. I sort by date and check that recent uploads are WebP and under 100 kilobytes. I also run a PageSpeed test on the top three most‑visited articles to confirm their LCP remains low. If a new image has caused a regression, I identify it and reprocess it.
Keeping the Workflow Habit
The most important maintenance step is simply following the workflow every time. The two‑tool method becomes automatic with practice, and the habit ensures that no new unoptimized images enter the library. I think of it as part of the publishing process, like writing an introduction or adding internal links. It is not an extra step; it is a standard step.
The long‑term benefit of this maintenance is that the site’s speed does not degrade as it grows. New content inherits the same lightweight characteristics as old content, and the overall performance remains consistent the regular maintenance is the key.
The Dailingua Speed Payoff: From 87 to 98 and Beyond
Before I implemented this image optimization workflow, the mobile LCP on my single posts was 3.9 seconds, and the Performance score was 87. The primary bottleneck was the featured image a 2‑megabyte JPEG that was being lazy‑loaded, meaning the browser did not even begin downloading it until the page was fully interactive.
After I applied the two‑tool workflow to every featured and in‑post image, disabled lazy loading for the featured image, and added the preload snippet, the LCP on that post dropped to 1.5 seconds. The mobile score climbed to 98 and has stayed there through every article I have published since. The cumulative effect is that every new post inherits the same lightweight image workflow, and the site’s overall page speed remains fast regardless of how many images I include.
The speed improvement was not the result of a single dramatic change. It was the result of a consistent publishing habit two minutes per image, every time, without exception. The tools are free, the process is repeatable, and the results are permanent.
The site you are reading now, dailingua.com, loads its images instantly because of the workflow documented in this guide. That speed is not an accident. It is the result of a deliberate, repeatable process that any blog owner can learn and apply. Your images can be crisp, your pages can fly, and your readers will stay. That is the Dailingua standard and now it is yours.
The next time you upload an image will it be 2 megabytes or 68 kilobytes?