Website Image Optimisation

Image optimisation is one of the most “rewarding” aspects of WordPress performance: for the same page structure and theme, as long as the image size, dimensions, formatting and delivery are correct, the loading experience will improve immediately.

But image optimisation is also the easiest way to make a mess, not because it's technically too difficult, but because the information is too fragmented:
You read a few articles, know that “compression”, “WebP/AVIF”, “lazy loading”, and then look at the plugin introduction and said “free every month! 100 credits per month”, “Free 20MB”, “1 credit per image”, but the more I read, the more confused I get-- Is free enough? How to deduct the fee? Did you misunderstand “the same thing”? And most importantly:Did it actually take effect after you did it or not?

This article does only three things:

1. Give you an executableroadmap (also fig.)(What to do first, what to do second)
2. Be clear about the option you're going for (what's the difference between free/paid and who each is suitable for)
3. Write out the most common pitfalls ahead of time (so you don't have to search around to troubleshoot when you're done)

1. The Bottom Line: What WordPress Comes With and What It Doesn't

If you don't first figure out what WordPress core already does, it's easy to do one of two things:

• Instead of using the “free capacity” you should be enjoying, you spend time/pay money to build the wheel over and over again.
• I thought WordPress would “automatically convert all old images to WebP/AVIF”, but it turns out it doesn't!

WordPress core has these key capabilities built in:

• Responsive images (srcset/sizes): As of WordPress 4.4, the core will output images for the srcset 与 sizes, and utilises the multi-sized images generated during upload to allow the browser to choose a more appropriate resource to load by screen conditions.
• Native lazy loading: WordPress 5.5 onwards enables native lazy loading of images by default, using HTML standards. loading attribute implementation.
• Support for uploading WebP: Since WordPress 5.8, you can upload and use WebP as JPEG/PNG (provided the hosting environment supports WebP).
• Support for uploading AVIF: WordPress 6.5 onwards can upload and use AVIF as JPEG/PNG (also dependent on hosting support).

But pay attention:
“Support for upload/use” ≠ “Automatic conversion/automatic delivery”.
That is to say: even if you are already on WP 6.5, those JPG/PNGs in your media library won't turn into WebP/AVIF on their own; you won't automatically get the full “output AVIF/WebP according to the browser's capabilities and fallback to the original image for unsupported browsers” link! --this part usually needs to be patched by a plugin or service.

2. Roadmap: Image optimisation in 5 steps

What to do, why, what to do to qualify, and what a typical pit is.

2.1 Getting the “size” right first (the most overlooked, but the most rewarding)

Many stations are slow not because the compression isn't done, but theDownloaded a large image that extends well beyond the display area：
For example, if the page is actually only 900px wide, and you ask the visitor to download the original 3000px image, the browser just “downloads it and then shrinks it”. This wastes bandwidth, increases decoding time and slows down the first screen.

WordPress 4.4+Responsive Image Mechanism（srcset/sizes) is designed to address this very issue.

Do what counts as a pass:

• When opening a page on a mobile phone, the size of the downloaded image should be significantly smaller than on the desktop
• The same image loads with different resource sizes on different devices (instead of always downloading the original image)

The most common pitfalls:

• There are themes/builders that treat diagrams as CSS background images, or output them in a custom way that may bypass the srcsetThe result has been a large picture of the
• You use externally linked image beds, third-party image blocks, and may also bypass the multi-size system generated by the media library

---

2.2 Compression (bring down the KB, but don't “crush” the quality)

The core of compression is not “the smaller the better”, but “the difference is barely visible to the naked eye, but the volume drop is obvious”.

The rules are as follows:

• Photographs/live shots (people, products, landscapes): Priority lossy compression (maximum gain)
• Screenshots of the interface / text-heavy images: Compression should be more conservative to avoid fuzzy text
• Logo/Icon: Priority SVG or discreet lossless (lossy is easy to edge paste)

Do what counts as a pass:

• Significant reduction in image size on most pages
• No visible noise, muddy edges, colour block breaks, blurred text

---

2.3 WebP / AVIF (format strategy: smaller for equal definition)

WordPress already supports uploading WebP (5.8) vs. AVIF (6.5)。
But to make the Next Generation Format really work, two things usually have to be resolved:

1. How to batch convert historical media libraries(Otherwise you are only optimising for “new images uploaded later”)
2. Whether to generate a copy or replace the original image(This is a risky watershed; we'll focus on Plus WebP's “Replace and Delete Original Image” later)

Recommended writing style:

• WebP: generally preferred as default (more stable compatibility)
• AVIF: a further compression direction, suitable for large images/first screen large images/album images (but moreDependence on environmental support）

---

2.4 Lazy loading should be used correctly (not one size fits all)

WordPress 5.5 onwardsDefault lazy loadingPicture.
It reduces the bandwidth usage during initial rendering:

• Lazy loading for “off-screen resources”
• The most critical large image on the first screen (and in many cases the key image on the first screen) is often unsuitable for delayed loading

---

2.5 Delivery Layer: CDN / Photo CDN

Compression, sizing, and formatting solve the problem of “smaller files that fit”.
However, if the images are always pulled from a distance from the source, network latency will still significantly affect the experience. This is where the “delivery layer” solution (CDN/image CDN) comes in.

Two typical directions:

• Cloudflare Polish：Cloudflare DocumentationPolish compression methods (lossless/lossy/WebP) are introduced, and it is mentioned that compression with the format=auto WebP/AVIF format is allowed.
• Jetpack Site Accelerator：Jetpack DocumentationExplain that it will optimise images and distribute them through its network along with static resources.

Image optimisation is responsible for getting smaller and more appropriate.CDN Responsible for delivering closer and more stable

3. Selection: two main routes only

The most common failure in image optimisation is not “no plugins”, but too many plugins leading to duplicate processing:
A is compressing, B is compressing, A is converting to WebP/AVIF, B is converting, A is changing URLs, B is rewriting - you can't even tell what's going on in the station.

Rules:

There's only one route to take: either all free local or cloud compression of the three.

• Route A (all free local):Plus WebP or AVIF + EWWW Image Optimizer(or just one)
• Route B (cloud compression triple option):ShortPixel / Imagify / TinyPNG

---

3.1 Route A: Full Free Local (Plus WebP or AVIF or EWWW)

This route is characterised by:

• You do not rely on “per month/per sheet” third-party compression services (although some features may be offered as optional services).
• The cost: batch processing can be more server-hungry at CPU/IO, requiring you to pay more attention to “strategy and risk”.”

3.1.1 Plus WebP or AVIF: the core is “generate/replace”, it is not the traditional “compression tool”.”

• When generating full-volume images:The original image file ID is overwritten by WebP/AVIF, the original file is deleted, and the URL in the content is replaced.。
• The plugin provides WP-CLI commands and reminds: WP-CLI is more reliable when there are many files.

This means that instead of “quietly generating a WebP for you”, it could be aAsset migration(Especially if you turn on the “Replace and delete original image” option).

Differences between the two models

Mode 1: Keep original image + generate WebP/AVIF copy (more stable)

• Pros: Easier to fall back in case of compatibility issues
• Cost: Disk usage will go up (original image + new format + multi-sized thumbnails)

Mode 2: Replace and delete the original image (more aggressive)

• Pros: disks don't expand as fast; station references go directly to the new format
• Risk: You're “changing assets + changing references”, which makes it more expensive to troubleshoot compatibility issues (especially if some external systems or theme logics depend on the original filename/path/format).

Typical Pitfalls of Plus WebP or AVIF

1. After replacing the entire library, some page images are displayed abnormally.
   The reason is usually not that the image is “broken”, but that some link in the chain of URL substitution, caching, thumbnail policy, etc. is not correct.
2. The greater the number of thumbnails, the greater the scope of the change
   WordPress generates multiple sizes for uploading an image; themes/plugins may also add more sizes. Full replacement means you may be altering a very large collection of files.
3. Just doing a format migration does not necessarily mean that the volume is always the smallest
   WebP/AVIF are generally smaller, but “size strategy” and “compression strategy” are still critical. Don't think of Plus WebP as “one click faster”.

---

3.1.2 EWWW Image Optimizer: representative of free local compression

The EWWW plugin page is very well positioned:

• It can be optimised on your server using a range of tools (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp, etc)
• You can also offload CPU-consuming processing to its server (optional) if you need higher compression or more CPU savings.

What role should EWWW take in Route A?

If you're using Plus WebP as a “format migration/replacement strategy”, then EWWW is a better fit:

• Compression and Volume Optimisation(especially weight reduction of raw resources such as JPG/PNG)
• Batch optimisation of historical media library(targeting “volume reduction” rather than “URL replacement”)

Typical Pit of EWWW

1. Elevated server load during batch optimisation
   Because local compression eats CPU/IO, the solution is not “don't use it”, but “batch, low peak, offload/cloud option if necessary”.
2. “A WebP is generated” does not mean that the frontend must be producing a WebP.
   Many plugins suffer from this misunderstanding: generation is one thing, delivery strategies (rewrites, picture tags, cache hits, etc.) are another.
3. Doing the same thing over and over with other plugins
   If you go route A, try not to overlay ShortPixel/Imagify/TinyPNG type of cloud compression; if you go route B, don't turn on Plus WebP replacement logic. Core principle:One route to the end.

---

3.2 Route B: Cloud Compression Triple Choice (ShortPixel / Imagify / TinyPNG)

This route is suitable for people who “want to save server resources, want to do batch with less effort, and accept per credit/per volume billing”.
But the most misleading point about cloud compression is:Free credits are not as simple as “free sheets”!.. The number of thumbnail sizes, whether or not WebP/AVIF is generated, and whether or not it is repeatedly re-pressurised can significantly affect consumption.

The following will explain: what's going on with free/fee, how credits are deducted, what pitfalls are most likely to be stepped into, and what site types are appropriate.

---

3.2.1 ShortPixel100 free credits/month, but credits are consumed by thumbnails and WebP/AVIF enlargements.

What's going on with free/paid

The ShortPixel plugin description clearly states:

• 100 free credits per month
• There are also “Extra Unlimited Monthly Credits” (the plugin page gives information on the corresponding prices)
• Also available as “one-time credits packs that never expire” (with starting price information)

Tip:

• Free: give a certain amount of credits per month for light sites or testing
• Disposable packs: suitable for sites with large media libraries that want to clear out their stock at once (buy once and use it up, it usually doesn't expire).
• Monthly/Unlimited: suitable for sites with continuously updated images and long-term stable optimisation

ShortPixel's official KB has also given an update on “One Time Pack vs Unlimited Monthly”.explicit explanation: Unlimited Monthly is a monthly (or yearly) payment that offers unlimited credits with a fixed CDN allotment; one-time credits that don't expire, giving you more control to use them as needed.

The bottom line: how are ShortPixel credits calculated?

ShortPixel Official Documentation KB put it very bluntly:

• WordPress generates multiple thumbnails when you upload an image;
• Each thumbnail optimisation counts as a credit；
• If you choose to generate a WebP or AVIF, theEach WebP/AVIF version of the original image and thumbnail consumes an additional credit.；
• You can exclude certain thumbnails from being optimised to reduce credits consumption.

Credits Example：

Let's say you upload 1 image and the theme/plugin generates 8 thumbnails:

• Optimise only the original image + thumbnails: 1 (original) + 8 (thumbnails) = 9 credits
• If you also want to generate WebP/AVIF: one more next-gen version for each of the 9 above → +9 credits.
  In other words, what you think is “1 picture” may actually consume close to “2-digit credits”.

So:“Free 100 credits” is not the same as “free 100 images”.

ShortPixel's most common pitfalls

1. Free 100 credits runs out fast
   Root cause: lots of thumbnails + extra credits for generating WebP/AVIF.
   suggestion：

• Assess the number of site thumbnails first
• Exclude unnecessary thumbnail sizes (only optimise sizes that will actually be used)
• Determine the compression strategy before running in bulk to avoid repeated trial and error consumption

2. Stacking other converter plug-ins at the same time
   If you have Plus WebP replacements and ShortPixel generating/inserting next-gen tags, the logic stacks up and becomes harder to troubleshoot. For route B, let ShortPixel do it alone.
3. I thought if I installed it, it would be “WebP/AVIF in the foreground”.”
   ShortPixel plugin pageMentioned that it converts WebP/AVIF and can add next-gen images to the front page (e.g. by tagging).
   But it is still important to verify the results after doing so.

---

3.2.2 ImagifyFree: 20MB/month; quota deducted according to “original image size + number of thumbnails”, repeated deductions will be made for re-pressing.

Free amount and positioning

Imagify Official Price PageThe writing is clear:Free Account Monthly 20MB Quota。
Its plugin page also makes it clear that it can compress, resize, and convert WebP/AVIF.

How is the quota deducted?

Imagify Official Documentation “How is Quota Usage Calculated?” breaks down the deduction mechanism very clearly:

• Number of thumbnails affects consumptionFor example, if you have 10 thumbnail sizes, optimising 1 image becomes optimising 11 images (original + 10 thumbnails), which all contribute to quota consumption.
• Deduction of quota according to the size of the original document: For example, if you send a 100KB image to Imagify, 100KB will be deducted from the quota.
• Changing the compression level and re-optimising will consume quota again。
• The same API Key can be used for multiple sites, but quotas are shared between them.

This is Imagify's “core way of understanding”:
It's more like a traffic pack: it deducts as much as you send; the more thumbnails you have, the more it deducts; and you'll repeat the deduction if you repeatedly re-press it.

Easy-to-read Imagify quota example

Let's say you upload an original 800KB image and the site generates 8 thumbnails.

• Imagify optimises to include the “original image + 8 thumbnails” (if you choose to optimise all of them), which means that this single action consumes a quota close to the “original size of all these files combined”.
  That's why some sites feel that “20MB runs out fast”: it's not that Imagify isn't enough, it's that you're uploading too many images at a time, too many thumbnails, and you're probably trying compression levels over and over again.

Imagify's most common pitfalls

1. Free 20MB Not enough to do a “full site history inventory”
   20MB is usually better suited for testing with light updates; if your media library is already large, a one-time purge is likely to require an upgrade.
2. Repeated adjustment of compression levels results in duplication of quota consumption
   Imagify makes it clear thatRe-optimisation will consume the quota again.
   I suggest you make the “strategy” clear on this page:

• Start with a small number of images to determine the compression level and look and feel.
• Determine the strategy and then run in bulk
  Avoid repeated trial and error on the full library

3. Multiple sites sharing API Key leads to “inexplicable quota reduction”.”
   If you use the same API Key for more than one station, the quota is shared.
   So in team/multi-station scenarios, it's best to be clear: which stations are shared and which are used individually to avoid uncontrollable budgets.

---

3.2.3 TinyPNG(Tiny Compress Images): free 500 credits/month; switching to WebP/AVIF will “deduct an extra 1 credit per size”.”

Free credits and its billing ideas

TinyPNG's WordPress plugin page is very clear:

• 500 credits per month for free
• In the “General WordPress Installation”, you can probably compress the Approx. 100 images/month
• However, if AVIF or WebP conversion is enabled:Each image size consumes an additional creditSo presumably it can only be compressed and converted Approx. 50 images/month(depending on how many thumbnail sizes you have).

Meanwhile, Tinify (the developers of TinyPNG/TinyJPG) have also made their API Pricing PageDescription: Sign up and get 500 free compressions per month; after that, you will be billed by the number of successful compressions, no mandatory subscription.

Summarise the way TinyPNG is understood in one sentence:
It counts credits; the more thumbnail sizes you have and the more WebP/AVIF you have turned on, the faster credits are consumed.

Easy-to-read examples of TinyPNG credits

Suppose your site generates 8 thumbnail sizes for each image:

• Compression only: original + 8 thumbnails → 9 credits required
• If WebP/AVIF conversion is turned on: one extra credit per size → probably nearly double!
  This corresponds to the description on the plugin page: after switching on, the free amount changes from approximately “100 cards/month” to “50 cards/month”.

The most common pitfalls of TinyPNG

1. Thought 500 credits = 500 images
   It is not. It is consumed by “image size/variant”. The plugin page clearly warns that “Conversions deduct an additional 1 credit for each image size”.
2. Themes/e-commerce plugins are generating too many sizes and the free credits are dropping significantly
   The more sizes there are, the easier credits are to be scaled up and consumed.
3. After enabling the conversion, you find that the credits are suddenly unused.
   It's not a bug, it's its billing mechanism.
   Strategy Advice:

• If the free phase is mainly used for compression and weight reduction, you can start with compression only, and then turn on conversion when you are sure that your site structure is stable and you really need next-gen.

4. Sub-scenario recommendation: how to choose different types of sites

Also WordPress, content sites, e-commerce sites, portfolios, and membership sites don't have the same “pressure points” for images.

4.1 Content sites/blogs (lots of article graphics, medium frequency of updates)

Priority Recommendations:

1. Sizing Strategy (Step 1)
2. Compression (Step 2)
3. WebP (Step 3)

A more suitable route:

• Want to save: Route B Triple Choice (ShortPixel / Imagify / TinyPNG)
• If you want to go free: Route A (Plus WebP + EWWW), but it is recommended to start with the “conservative mode (without deleting the original image)” to assess the risk.

Typical pit:

• The first image of the article page is very large, improper lazy loading strategySlows down the first screen

4.2 E-commerce/product site (many thumbnails, many image variants, stability first)

E-commerce is most likely to be the problem is not “compression effect is not good”, but “optimised some of the size is not right, missing thumbnails, front components can not get the picture”.

Priority Recommendations:

1. Stability first: conservative compression strategy, do not do a full library replacement right away
2. Evaluating thumbnail sizes: e-commerce themes usually generate more sizes, and the amount consumption is magnified (ShortPixel/TinyPNG is particularly noticeable)
3. Do small scale validation before batch (very critical)

A more suitable route:

• Route B tends to be more hassle-free: ShortPixel/Imagify/TinyPNG can all batch, and it's critical that you understand the quota mechanism and assess the cost in advance
• Route A is fine, but be more careful with Plus WebP's “overwrite IDs/delete original images/replace URLs” behaviour: it's an asset migration, and it's not recommended to replace the whole thing right off the bat.

4.3 Portfolio/photographic station (single image quality sensitive, large images, high demands on viewing)

Priority Recommendations:

1. Size policy (display area control)
2. Compression strategy (better to be bigger than to crush the details)
3. WebP/AVIF (big picture scene gains are obvious, but verify the view)

A more suitable route:

• Imagify: Deduct the quota according to the “size of the original image”, this site is easier to do “budget-controlled” (you know how much to deduct for each large image), but to avoid repeated repressions.
• ShortPixel: If the thumbnail size is not much, credits are also very intuitive; but if you generate many sizes +next-gen, credits consumption will be magnified, and you need to plan ahead.

5. Quota/billing comparison: putting “free is not enough” into perspective

Which one is the better deal and how long will the free last?

5.1 Three Chargeback Models

• ShortPixel(credits): Credits based on “original image + number of thumbnails”; additional credits will be deducted for each corresponding version of WebP/AVIF generated.
• Imagify(MB quota): Deduct the quota according to the “original file size”; the more thumbnails, the more deductions; re-pressing will deduct again.
• TinyPNG(credits): 500 credits per month; enabling WebP/AVIF conversion deducts additional credits for each image size.

5.2 Rapid estimation methods

You can estimate it like this:

1. Find a random “original image you often upload” and see how big it is (e.g. 300KB / 1MB / 3MB).
2. Depending on how many thumbnail sizes your site generates (e.g. 5 / 10 / 20)
3. Decide if you want to generate WebP/AVIF (yes/no)

Then use the following “mental maths” to understand consumption:

• ShortPixel: ≈ (1 + number of thumbnails) credits per image; if generating WebP/AVIF, ≈ doubles again (since the next-gen version also takes credit)
• Imagify: Each image ≈ (original size + each thumbnail size) deduct quota; change compression level and recompress will deduct again.
• TinyPNG: 500 credits free; if your site generates a lot of sizes per image, and conversion is enabled, the number of free credits drops significantly (the plugin page gives a visual expectation of “~100 credits/month” vs. “~50 credits/month”)

6. Risk alerts

Risk 1: Don't let multiple plugins do the same thing over and over again

It's the most common “source of disaster.”

• Route A:Plus WebP or AVIF + EWWW(Split labour between the two, don't do like-for-like conversions and deliveries at the same time, or install only one of them)
• Route B: ShortPixel / Imagify / TinyPNG choose three(choose one for compression and next-gen)

Risk 2: Plus WebP's “Overwrite ID / Delete Original Image / Replace URL” is an asset migration.

Emphasis added:Plus WebP The description clearly states that full generation overwrites the original image ID, deletes the original file, and replaces the content URL.
This means that it is not a “small setting that can be withdrawn at any time”, but an asset-level change.

The suggested strategy should be:

• Small test first (a few dozen to a few hundred)
• Confirm that the frontend display, thumbnails, and cache updates are all working properly
• Reconsider full library processing

Risk 3: The real consumption of cloud compression “free credits” depends on the number of thumbnails and the next-gen selection.

• ShortPixel: Thumbnails and next-gen significantly affect credits.
• TinyPNG: Enabling WebP/AVIF deducts an additional credit for each image size.
• Imagify: deducted according to the size of the original picture, the more thumbnails deducted more, heavy pressure will repeat the deduction!

Risk 4: “WebP/AVIF generated” does not mean “WebP/AVIF is being delivered by the front office”

Many people feel “not faster” after the conversion because the frontend is still producing JPG/PNG (caching/rewriting/tagging/browser negotiation etc. are not in alignment).

7. How to verify that it has taken effect after it has been done

4 very simple validation points:

1. Whether the same page is refreshed a second time and loads more consistently and faster(Caching and optimising the physical sense of whether it works)
2. Are the sizes of images loaded on mobile phones and desktops significantly different(responsive) srcset/sizes (whether or not they work)
3. Spot-check a few images: whether WebP or AVIF files/resources are present(Is the site actually using next-gen）
4. Sample a few images: zoom in to see if they're visibly muddy, if the text is fuzzy(compressed mass is not excessive)

If all four of these match, the route you've chosen has been run. Next up. CDN “Delivery Layer”, the overall will be more stable.

8. Recommendations for action

1. Pick your route first:

• Trying to be as free as possible.: Plus WebP or AVIF + EWWW (or just one of them)
• Want to save server resources, pay per credit for more peace of mind: ShortPixel / Imagify / TinyPNG - choose one!

2. Do a small test first (a few dozen)
3. Make sure it's okay before you batch
4. Further improvements in delivery stability are required:read CDN Acceleration

common problems

1. How many plug-ins do I have to install? Can I install them all?

Try to take only one route.

• Route A: Plus WebP or AVIF + EWWW Image Optimizer (or just one of them)
• Route B: ShortPixel / Imagify / TinyPNG - choose one!
  In the same station at the same time let multiple plug-ins to do “compression / transfer WebP / AVIF / change URL / delivery rewrite”, the most likely to get more and more chaotic, but also the most difficult to check.

2. Doesn't WordPress already support WebP/AVIF? Do I still need a plugin?

It needs to be separated:
“Support for upload/use” ≠ “Automatic conversion/automatic delivery”.
WordPress 6.5 also doesn't automatically batch-convert old JPG/PNGs to WebP/AVIF, nor does it automatically do the whole “export AVIF/WebP to browser capable and fallback” thing for you. It usually takes a plugin or service to make the historical media library work.

3. What is the most “rewarding” step in image optimisation?

It's usually Get the “sizes” right first (srcset/sizes).。
Many sites are slow not because they don't have compression, but because the page is only 900px and the user is asked to download a 3000px image. Compression saves KBs, but the “wrong size” will make you download several times more data for nothing.

4. How can I be sure that I am loading the “smaller one” and not the original image forever?

Look at two phenomena:

• When opening a page on a mobile phone, the size of the downloaded image is noticeably smaller than on the desktop
• The same image loads with different resource sizes on different devices
  If the original image is downloaded forever, a common reason is that the theme/builder treats the image as a CSS background image or custom output, bypassing the media library's multi-sizing with srcset.

5. Does “WebP/AVIF generated” mean that the frontend must be producing WebP/AVIF?

Not equal.
Generation is just the “file layer” done; whether the frontend actually delivers WebP/AVIF depends on rewrites, picture tagging policies, cache hits, browser negotiation in effect, and so on. When you're done, be sure to “spot check a few images for resource types”.

6. Plus What's so dangerous about WebP or AVIF? Can I run the whole library in one click?

Its risk point is not “compression”, it isChanges in asset migration levels：

• Full generation may overwrite the original image file ID, delete the original file, and replace the URL in the content.
  the reason whyIt's not recommended to replace the whole library right off the bat: Test on a small scale first (tens ~ hundreds) + have available backups, then consider full library processing.

7. What is the choice between the two modes of Plus WebP: keep the original image vs. replace and delete the original image?

Simple to understand:

• Mode 1: Keep original image + generate WebP/AVIF copy (more stable): Convenient for rollbacks, but the disk goes up (original image + new format + multi-sized thumbnails).
• Mode 2: Replace and delete the original image (more aggressive): Disks are less prone to bloat, but you're “changing assets + changing references”, which makes it more expensive to troubleshoot compatibility issues.
  The more complex the site (e-commerce/multi-plugin/multi-size), the more recommended it is to start with a more stable model.

8. Is EWWW Image Optimizer free local compression enough? Will it overwhelm the server?

EWWW is more of a “local compressor”: it eats CPU/IO.
It is common for load to rise during batch optimisation, which doesn't mean it “doesn't work”, but rather that the strategy should be right: batch, low peaks, and offloading/cloud options if necessary.
If you're looking for savings, or if you're strapped for server resources, Route B is more server-friendly.

9. ShortPixel's 100 free credits/month, why do I feel like it's gone in a few pictures?

on account of credits is not “number of pictures”.”The next-gen will be enlarged by a thumbnail with the next-gen:

• Original image + every thumbnail counts as credit
• If a WebP/AVIF is generated, an additional credit is consumed for each corresponding version.
  So what you think is “1 image” may actually consume close to “2-digit credits”. shortPixel

10. Imagify's free 20MB/month, why does it also run out quickly?

Imagify is more like a “traffic pack”:

• As you sent it.Original file sizededuction of quotas
• The more thumbnails you have, the more you consume
• Changing compression level to re-optimise will consume quota again
• Same API Key for multiple sites, quota sharing
  So “20MB will run out soon” is often caused by too big images, too many thumbnails, or repeated trial and error.

11. TinyPNG is free for 500 credits/month, why does the plugin say it's only about 100 credits/month and then 50 credits/month with WebP/AVIF?

Because TinyPNG credits are also enlarged by “size/variant”:

• A regular WordPress installation probably compresses about 100 sheets/month.
• Enable AVIF or WebP conversion:Each image size consumes an additional creditSo you can probably only compress and convert about 50 images/month (depending on the number of thumbnail sizes).
  So 500 credits ≠ 500 images.

12. How many thumbnails are there on my site? Why does it matter so much?

WordPress generates multiple sizes for uploading an image; themes/plugins (especially e-commerce) may add more sizes.
Cloud compression credits/quotas are usually “original + thumbnails together”, so the more thumbnails you have, the less free credits you have to use.

13. Is lazy loading always faster? Why do some people say that lazy loading slows things down?

Lazy loading is suitable for “off-screen resources”.
If the first screen of the most critical large image is also delayed loading, may slow down the first screen experience. WordPress 5.5 since the default lazy loading is fine, but do not “one size fits all”.

14. I am travelling on Route A or B. When do I need CDN / Picture CDN?

Compression, sizing, and formatting solve the problem of “smaller files that fit”;
CDN The solution is to deliver closer and more stable。
When images are pulled from a distance from the source site resulting in significant latency, then supplementing CDN/images with CDN (e.g. Cloudflare Polish / Jetpack Site Accelerator) will be overall more stable, read WordPress CDN Acceleration。

15. What is the easiest way for me to verify that “it really works” when I'm done?

The most time-efficient verification method:

• Whether the same page is refreshed a second time and loads more consistently and faster
• Are the sizes of the images loaded on mobile phones and desktops noticeably different (does srcset/sizes come into play)
• Spot-check a few images: whether WebP or AVIF files/resources are present
• Sample a few images: zoom in to see if they're visibly muddy, if the text is fuzzy