Let’s be honest – there are already a ton of articles on image optimisation. Most of them tell you things you probably already know (like the difference between a JPEG and a PNG)
But in building our site recently, despite us being a leading web design agency building over 500 websites in the last 12 years, I found myself in the depths of appeasing Google Speed Insights. Despite my quite vast knowledge on the subject, I ended up discovering and implementing various tactics to sort out our images, get the loading times up to scratch, and do away with those annoying “Properly size images” and “Serve images in modern formats,” etc.
So where to start? Head over here: https://pagespeed.web.dev/, pop in your website, and if you get any warnings about images in your report, then keep reading on, and let’s try to sort them out.
Types of images
Ok, so basics first. If you’re a pro, read on to the next section. However, it’s always good to have a little refresher.
Different image and graphic types need different formats. If you’re jamming big JPEGs into your site for everything, you need to stop (collaborate) and listen.
Jpeg
Ok, what does JPEG even mean? Honestly, I use them every day, and I still had to Google this, JPEG stands for:
“Joint Photographic Experts Group.”
Great, what does that mean? If you want a guide on the nitty-gritty, head over here: https://www.geeksforgeeks.org/process-of-jpeg-data-compression/, but basically:
JPEG compresses images using lossy compression by transforming the image into frequency components via the Discrete Cosine Transform (DCT), quantizing the data to reduce precision, and applying entropy coding to efficiently store the remaining information.
Basically, it makes your image much smaller, often with minimal quality loss. Most places where you can save an image from Adobe, Figma, etc., allow you to choose a compression level. I usually go for around 60% unless there is visible quality loss because of this.
Great, so I’ll make all my images JPGs? Well, no-don’t do that. JPEGs work well for pictures. By pictures, I mean pictures of your offices, pictures of your staff, your holiday photos, pictures of your dog – that sort of thing.
JPEGs don’t work well for graphics – your logos, icons, infographics, flow diagrams, etc. If your logo on your website is a JPEG, you’re probably noticing it’s likely a bit blurry and not crisp. Other formats like PNG or SVG work much better for this!
So in summary, if you have an image or something that’s not a graphic, great-save it as a JPEG, aim for around 60% compression (and size it appropriately-more on this later).
NB: WebP and, to a lesser extent, AVIF have mostly replaced the need for JPEGs on your site in 2025, so still use them if you have something on-site to sort out delivering WebP from a source file like a JPEG. If you don’t, then skip ahead to WebP and read on.
PNG
So, PNG-it stands for Portable Network Graphic and is a type of raster image file. Again, the nitty-gritty here: https://www.adobe.com/creativecloud/file-types/image/raster/png-file.html, and a summary:
PNG compresses images using lossless compression by applying filtering to improve redundancy, then encoding the data with the DEFLATE algorithm, which combines LZ77 and Huffman coding for efficient storage without quality loss.
Great, so what should I use a PNG for? Basically, it’s a good option for a graphic that isn’t vectored. So if you have your logo, infographic, icon, etc., that isn’t vectored, a PNG is usually your best option. It allows transparency in the background as well, so you can save, say, your logo on a transparent background. If your header changes colour, no more white block background around your logo.
So you have your logo that isn’t in a vectored format? (By “vectored,” I mean an EPS, AI (no, not ChatGPT or the likes but Adobe AI), or SVG format.) Then a PNG is usually the best way to go.
Top tip: Put it through this tool – https://tinypng.com/ – this is great for reducing the size of your PNG without quality loss before popping it into your site.
GIF
So, whenever I say this in the office, someone usually tells me it’s pronounced “Jif” with a soft G. There’s your top tip for saying GIF and sounding like a pro.
It stands for Graphics Interchange Format-nitty-gritty: https://www.adobe.com/creativecloud/file-types/image/raster/gif-file.html, and a summary:
GIF compresses images using lossless LZW (Lempel-Ziv-Welch) compression, which replaces repeated patterns with shorter codes to reduce file size while supporting a limited 256-color palette.
Great, so when should I use this? Well, I rarely use GIFs-maybe I should use them more, but the problem I find is that GIFs, due to their limited colour profiles, often result in poor – quality output for more complex graphics. There are also much better options (cough, SVG) that allow for vectored formats so your graphic can resize without losing quality.
So, if you’ve got a simple icon, then a GIF can be a good way to go.
But wait! GIFs do animation.
Yes, they do. You can create animations with GIFs using multiple frames to animate things like your logo.
But if you use a GIF on your website, Google Speed Insights will show you this:
“Use video formats for animated content.”
So, as Google says, it’s not a good way to go. Animated GIFs are usually very big. If you’re using an animated GIF and don’t want it to be massive, then use this tool: https://ezgif.com/ – it’s pretty good!
Animated GIFs are good for email signatures, but use them on your site, and Big G is not your friend. If you need animation on your site, consider MP4, WebM (if you don’t care about Mac iOS support), or Lottie (https://lottiefiles.com/).
In summary, GIFs are somewhat of a dated format. We rarely use them on websites unless we have something like a non-vectored icon and a PNG doesn’t make sense. But if you want an animated email signature, GIF is still your friend.
SVG
Ok, we’re getting a bit closer to formats that really matter on a website in 2025.
SVG stands for Scalable Vector Graphics.
The guff: https://www.adobe.com/creativecloud/file-types/image/vector/svg-file.htm
SVG (Scalable Vector Graphics) represents images using XML-based vector paths, defining shapes, lines, and colors mathematically, allowing infinite scalability without loss of quality while remaining editable and lightweight.
So, if you’re building a site in 2025 and have a graphic, then SVG is your friend. They are great for your logo, icons-pretty much any graphic that isn’t too large or complex.
Why are they good?
- They are vectored, so whether you view them on your 8K gaming monitor or your grandma’s iPhone 8, they will not lose quality and will scale without loss.
- You can embed them! Unlike other images that require src=”urltoyourimage” (unless you’re doing something like Base64 encoding), embedding SVGs removes the need for extra “requests” on your webpage. Too many requests to images or files can slow down your site, and most speed test tools recommend reducing the number of page requests. (Oddly, I don’t believe Google Speed Insights does this, but it still matters as it contributes to a lower speed index.)
- They are great for use in, say, a logo carousel, where you would normally have 10 requests to different images. If you embed them as SVGs, there are no additional requests.
- But be careful! Embedding too many large SVGs can lead to an “Avoid an excessive DOM size” warning.
- SVGs can put a lot of code on the page. Google Speed Insights doesn’t like this, so you need to strike a balance between embedding SVGs and including them as standard images.
- If you’re embedding an SVG, this tool is great: https://jakearchibald.github.io/svgomg/-it optimises your SVG by reducing the amount of code and making them smaller.
- If you embed SVGs, you can apply CSS effects to them.
- Have a big map of the world and want hover effects on a location? SVGs allow you to do this.
- Want to apply a gradient or hover effect to your SVG across your site? SVGs allow you to do this.
- They are good for animation.
- In fact, the whole Lottie library (linked previously) is an SVG animation library.
- SVGs allow you to create vectored, scalable animations that you can trigger on interaction.
- Want your logo or icons to animate when a section comes into view? SVGs can do this-and they’re usually the best option.
- They are easy to work with.
- If you have a design in Figma, you can copy an SVG directly as code and paste it into your site when you’re developing it.
- You don’t have to go through the hassle of exporting, saving, optimising (although using SVGOMG as linked earlier is still a good idea), uploading, referencing the URL, dealing with relative URLs from staging to production, etc.
Where SVGs aren’t so good
- Embedding too many SVGs can create an excessive DOM size. As mentioned earlier, watch out for this.
- Watch out when you have an image inside an SVG.
- This happens quite often-sometimes an SVG will Base64 encode an image, meaning it won’t actually be vectored or scalable. An SVG imposter!
- In these cases, you can end up with a very large SVG that won’t scale properly-so consider using a PNG or another format instead.
In Summary
- If you have an icon or non-complex graphic that is vectored, SVG is the way to go.
- If you want animation or interactivity with your graphic, use an SVG.
WebP
WebP’s are pretty great-they are a modern format for images and graphics that drastically reduce file size. If you have a website in 2025 and aren’t using WebP’s, you need to start doing so.
It’s also what Google Speed Insights means when it says “serving images in modern formats.” WebP is a modern format, and guess what? Google owns it, and it’s developed by Google-maybe a reason they want you to use it, but credit to Google, they are good.
So, onto a definition of what WebP stands for… well, it doesn’t stand for anything-it is simply derived from “Web Picture.” I sometimes refer to them as What Even Breaks Photoshop? (since WebP wasn’t natively supported for ages).
Here is a link to Google’s page about WebP: https://developers.google.com/speed/webp
WebP compresses images using predictive coding for lossy compression (similar to VP8 video frames) and dictionary-based techniques for lossless compression, supporting transparency and animation with smaller file sizes than JPEG, PNG, and GIF.
I could go deep into WebP, but basically, if you have a JPEG, PNG, or GIF, then you should convert them to WebP (or AVIF in the next section) and use that instead.
When should you still use a non-WebP image?
The only time you want a non-WebP on your site is if you know your Content Management System (CMS), CDN, or server is converting them for you, and you want conversion and quality handling carried out by that tool. Otherwise, always convert them (or avif, see below)
🚨 Please don’t use massive JPEGs and PNGs.
In 2025, no one needs a 1.2MB PNG when a 76KB WebP will work just as well. They also support transparency, so that transparent background PNG you’re using? Make that a WebP too.
How to convert to WebP
This is a great tool for mass converting to WebP: https://towebp.io/ There are also some good CDNs and plugins that can handle conversions for you. I’ll go onto that later, along with the pros and cons.
The only downside to WebP?
This is becoming less and less of an issue, but compatibility. Check here to see what browsers support them: https://caniuse.com/webp
But basically, unless you are developing a website that must support backwards compatibility for outdated browsers (this might be needed for a developing country or because that CEO still thinks IE is the way to go), then WebP is fully safe to use.
AVIF
So, AVIF is a modern image format, released in 2019. I say modern, but six years ago isn’t all that modern in terms of the web.
AVIF stands for AV1 Image File Format, which is based on the AV1 video codec and uses the HEIF (High-Efficiency Image File Format) container for storing images with advanced compression.
Our friends over at Smashing Magazine have a good article on AVIF and modern file formats: https://www.smashingmagazine.com/2021/09/modern-image-formats-avif-webp/
When should you use AVIF, and when should you use WebP?
So, AVIF is a modern image format that Google doesn’t own-if you don’t like Google, that makes the choice easier.
Basically, AVIF offers better compression and is newer, but WebP is more widely supported.
Check browser support here: https://caniuse.com/?search=avif
In general, unless you have many older Edge users, AVIF should be safe to use.
Is AVIF better than WebP?
Yes, in real-time usage, AVIF is better-so really, in 2025, you should be using it and could even argue for it over WebP.
However, WebP has better support in design software (only recently with Adobe), whereas AVIF isn’t really a format you see when exporting an image from Adobe, Figma, or similar tools.
This is because:
- AVIF takes longer to encode and decode
- It’s more resource-intensive, especially on older hardware
- The uptake in design software is low
Compression: AVIF vs WebP
AVIF can offer 30-50% better compression than WebP.
That’s a big saving, but note that this is compound compression.
If you’ve already saved 900KB by converting a JPEG to WebP, you’re probably thinking:
“That’ll do-massive saving!”
At this point, the need to take one step further and optimise might get lost, especially if you’re already meeting Google Speed Insights’ requirements.
Example Calculation:
- Starting with a 1MB JPEG
- Converted to WebP at 100KB (90% smaller than JPEG)
- AVIF is 30-50% smaller than WebP, so:
At 30% smaller:
100KB × 0.70 = 70KB
At 50% smaller:
100KB × 0.50 = 50KB
That extra 30-50KB saving over the compatibility of AVIF often gets overlooked.
In Summary
✅ Yes, you should be using AVIF.
Its support is now almost as wide as WebP, it saves more file size, and it has all the same features (including transparency) as WebP.
So, if you’ve already converted to WebP, go one step further and use this to convert to AVIF: https://towebp.io/webp-to-avif
Image File Types Summary
In short: stop using JPEGs, PNGs, and GIFs unless you’re handling image conversion at the CDN, server, or CMS level.
There is now good and wide support for modern file formats like WebP and AVIF-there’s no good reason not to use them on a website.
The file size savings are massive, and you’re not going to achieve a good score on Google Speed Insights unless you’re using these formats.
Image sizing
Ok we’ve got your file types sorted. You’ve gone into your site, switched all your jpegs, pngs and gifs to webp or avif, we should be good right?
Not that easy, Google Speed Insights might still be giving you this warning:
Properly size images
So we’ve saved loads of space converting them to the right format, but if your image is still 2000px width and is being rendered in a 300px frame then there is still optimization that can take place.
At this point the most logical thing to do would be to resize your image to 300px. Yes thats right, but we live in a time of responsive web design, no more fixed width container divs (minus 60px for the scroll bar) or websites built in tables. Your 300px resized image is good for a desktop screen size (above around 1200px) but on mobile its likely rendering smaller, lets say 100px.
So what do you do here? This is where srcsets come in:
Srcsets
The Guff: srcset is an HTML attribute that lets you define multiple versions of the same image at different widths (e.g., 400w, 800w, 1200w). The browser uses this list, along with the sizes attribute, to choose the most appropriate image based on the device’s screen size and resolution. It helps reduce file size and improves loading speed without sacrificing image quality.
So in summary It lets the browser choose from different image sizes depending on the screen size and resolution. Saves bandwidth, improves speed, and stops Google Speed Insights moaning about properly sized images.
Here’s a basic comparison:
Standard image tag:
<img src="image.jpg" alt="Example image">With srcset:
<img src="image-800.jpg" srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w" sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" alt="Example image">What this means:
- srcset tells the browser which versions of the image are available.
- sizes tells it how wide the image will be at different breakpoints.
- The browser picks the best one based on screen size and resolution.
Sounds good, but writing that for every image is a pain-cropping, resizing, writing markup-it’s not realistic for most builds. Which is why this is usually handled at the CMS level.
In WordPress, if you’re using wp_get_attachment_image() or the_post_thumbnail(), it should be doing this for you automatically.
Example:
<?php echo wp_get_attachment_image( $image_id, 'full' ); ?>That’ll output the full srcset and sizes for you. As long as you’re using WordPress’s built-in image functions, it’s already sorted.
In React (Next.js), use the built-in <Image /> component:
import Image from ‘next/image’;
<Image src="/images/example.jpg" alt="Example image" width={1200} height={800} sizes="(max-width:600px) 400px, (max-width: 1200px) 800px, 1200px" />In Vue (Nuxt):
<NuxtImg src="/images/example.jpg" sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" alt="Example image" />If you’re not using a framework that handles this, you’ll need to do it manually-or look at a CDN to help out (we’ll come onto that shortly).
WordPress tip:
Sometimes WordPress’s auto-generated srcset and sizes aren’t ideal. You might find it defaults to things like sizes=”auto” or serves weird image breakpoints. If that’s the case, you can define your own image sizes in functions.php:
function cbd_register_custom_image_sizes()
{
add_image_size('mobile', 576);
add_image_size('large-mobile', 768);
add_image_size('tablet', 1024);
add_image_size('small-laptop', 1366);
add_image_size('medium-laptop', 1600);
add_image_size('full-width', 1920);
}
add_action('after_setup_theme', 'cbd_register_custom_image_sizes');
function cbd_custom_image_sizes_dropdown($sizes)
{
return array_merge($sizes, array(
'mobile' => __('Mobile (576px)'),
'large-mobile' => __('Large Mobile (768px)'),
'tablet' => __('Tablet (1024px)'),
'small-laptop' => __('Small Laptop (1366px)'),
'medium-laptop' => __('Medium Laptop (1600px)'),
'full-width' => __('Full Width (1920px)')
));
}
add_filter('image_size_names_choose', 'cbd_custom_image_sizes_dropdown');
This will give you more control over how WordPress handles your image breakpoints and what gets added to the srcset.
Summary:
If you’ve sorted your srcsets, your images should now be correctly sized across devices, and that “Properly size images” warning in Google Speed Insights should be gone.
Now we’ll go on to look at some other techniques that can help-like CDNs, lazy loading, and delivery optimisation.
Lazy loading
Okay, so you’ve done your srcsets, you’ve got your images in the right formats, everything’s looking good—and now you’re getting hit with “Defer off-screen images”, like the screenshot below.
What does this actually mean, and how do you fix it?
You can see Google is suggesting you consider lazy loading, so let’s go into what that actually is.
So, what is lazy loading?
In technical terms, lazy loading is a browser-level optimisation that defers loading of off-screen resources (like images) until they’re about to enter the viewport. Instead of requesting all assets as the page initially loads, the browser holds off on fetching anything marked with loading=”lazy” until it’s needed. This reduces unused data transfer, speeds up time to first paint, and lowers your LCP score in tools like Google Speed Insights.
Lazy loading works by using the native loading attribute on <img> and <iframe> elements. It’s supported by most modern browsers and doesn’t require any JavaScript or external libraries to use in basic cases.
Here’s the guff: https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading
Without lazy loading:
<img src=”example.jpg” alt=”An example image”>
With lazy loading:
<img src="example.jpg" loading="lazy" alt="An example image">
What this does: it tells the browser not to load that image straight away. It’ll only fetch it when the user scrolls close enough for it to actually matter. Saves bandwidth, speeds things up, and stops Google from shouting at you about deferring off-screen images.
The markup is pretty easy. You basically just add loading=”lazy” to your image tag.
In WordPress, this is handled for you in most cases—you can just include lazy loading as an option, and it’ll do the rest. Same goes for React or Vue. It’s pretty straightforward, so you don’t need me to walk you through that bit.
However—you don’t want to lazy load everything.
If you’ve got images that are needed on first load (like anything in your hero section), lazy loading them can actually cause more problems. You might end up with layout shifts or missing images on first render, and Google Speed Insights might start complaining about things like render-blocking or content not appearing fast enough.
So, general rule of thumb: Lazy load anything below the fold.
Don’t lazy load images that are needed for the first view of the page.
Native lazy loading vs JavaScript fallback:
Most modern browsers support native lazy loading with loading=”lazy”, but if you need to support older browsers (looking at you, Internet Explorer or older Safari), you might consider a JavaScript fallback like lazysizes. For most people in 2025, though, this is overkill.
Preloading key images:
If you’re not lazy loading a hero image or anything above the fold, and it’s critical to the visual load, consider preloading it to prioritise it:
<link rel="preload" as="image" href="hero.jpg">This can help boost LCP (Largest Contentful Paint) if that image is a big part of your page’s first impression.
CDN’s
Okay, so now we’re on to CDNs.
So what is a CDN?
It stands for Content Delivery Network. It’s a network of servers around the world that deliver your website’s files—images, scripts, stylesheets, that sort of thing—from the closest location to the user. This reduces latency and improves load times.
Here’s the guff on it if you want the deeper explanation: https://www.akamai.com/glossary/what-is-a-cdn
CDNs are generally a good thing to use on your website. They help load your content from different locations around the world, so it’s usually delivered faster. Say your server is in London and someone loads your site in New York,a CDN might have a server location much closer to them, so instead of waiting for everything to come from London, they get it quicker from a nearby server.
So they help speed up your website, which is great—but they can also do all sorts of things with your images. And that’s why I’m bringing them up here.
So at this point, you may have got down to this part of the guide—who knows, you might’ve got fed up by now—but you’re probably thinking, this is a lot of effort, isn’t it? I’ve got to convert all my formats, I’ve got to do srcsets, I’ve got to fiddle around with sizes and compression and all sorts. This seems like a right faff.
Is there not a better way?
And yes—there is. In some cases, you can just use a CDN, and it’ll sort a lot of it for you.
There are pros and cons to doing it this way, and I’ll go through the two CDNs that we use, explain how they work, and what the pros and cons are. But yes, there is a faster way.
Cloudflare
Cloudflare is great. If you’re not using it, you probably should be. It does your DNS, handles security, and acts as a solid CDN. I’m not going to go into all the ins and outs of what Cloudflare can do—there’s loads of guff on their site if you want that. Here’s the link: https://www.cloudflare.com
What I will go into is Cloudflare’s image optimisation—because this is where it gets useful for what we’re doing here.
There are two things worth knowing: Polish and Image Resizing.
Polish is Cloudflare’s automatic compression tool. It strips out metadata like EXIF data, compresses your images (you can choose lossy or lossless), and if the browser supports it, it’ll automatically convert and serve WebP. This all happens on the edge, so it doesn’t mess with the original image on your server. It just delivers a much smaller version when someone loads the site.
Image Resizing is the clever one. Instead of you having to create ten different sizes of every image and build your own srcset, you can just give Cloudflare a high-res version, and it’ll resize it on the fly. You can literally define the width and height in the image URL. So you might end up with something like:
<img src="/cdn-cgi/image/width=300,height=200/your-image.jpg" alt="Example image">That tells Cloudflare to resize your image to 300×200 before serving it. It works well with srcset too, so you can still give the browser a few options if you want to. Saves you from doing all the cropping and exporting manually.
So yeah—Cloudflare doesn’t just speed things up, it can also take a lot of the image optimisation hassle off your plate. Worth looking into if you’re not already using it.
The only thing I will say about Cloudflare’s Polish is that, in real-world usage, the compression isn’t that extreme. So for example, I might upload a PNG to the site—it could be, say, 300 or 400KB—and when I download it from the front end with Cloudflare enabled, it’s still 300 or 400KB. No real difference.
Even after fiddling with the settings, Polish will often tell me that image is as optimised as it can be and that there’s no benefit to converting it to WebP. But in reality, if I take that same PNG and run it through a manual tool and convert it to a WebP—or even better, to AVIF—I can usually save a massive amount of space.
So, same example: upload a 400KB PNG, Polish says it’s good to go. But if I convert that to AVIF manually, I can usually get that down to under 100KB. That’s a 300KB saving, and a pretty big one if you’re doing that across loads of images.
So yeah—Cloudflare Polish and Image Resizing are good, and I love Cloudflare generally, but if you really care about compression, especially on heavy pages, you’ll still get better results using manual tools to convert to AVIF or WebP before uploading.
So yeah—Cloudflare is great, and you should be using it. But I wouldn’t say its image optimisation tools are enough to just switch on and be done with it:
- You still need to lazy load.
- You still need to change your markup if you want to use image resizing properly.
- Polish is decent, but it’s not enough on its own—you’ll probably still get warnings in your speed test tools.
If you’ve got Cloudflare and you can enable these features, then yes—absolutely use them. But manual optimisation will still give you better results every time.
Ewww
The last one I’ll mention is EWWW.
It might be relatively unknown, but it’s a very good tool—and it works well with WordPress. If you’re looking for an all-round solution and you’re not particularly technical, this is a solid option. You can install it on your site, check a few boxes, and it’ll handle a lot of the heavy lifting for you. It comes with loads of features, including automatic srcset injection, lazy loading, format conversion, and CDN delivery. You can tweak the settings, turn things on or off, and generally get decent optimisation without much effort.
The only thing I’ll say is that it can cause conflicts. So depending on your setup, you might run into issues—things like JavaScript errors if it tries to lazy load something it shouldn’t, or even images going blurry no matter what settings you pick. It can be frustrating to get to the bottom of if that happens.
So I’d say: If you’ve got a site that’s already been built and image optimisation wasn’t thought about properly at the time, EWWW is a good way to go back and patch it in.
If you’re building a new site and you know what you’re doing, I’d lean more towards doing it manually. You’ll get better results and more control.
That being said, it’s a very good tool—and it plays nicely with things like WP Rocket and Cloudflare, so you can stack it with other optimisers to really speed your site up.
Final Notes & Summary
So, in summary—image optimisation is one of those things that sounds simple at first but ends up being more effort than you’d expect. And while there are tools that can help (and you should use them), you still need to understand what’s going on behind the scenes.
Here’s the quick version:
- Use modern formats like WebP or AVIF wherever you can.
- Resize your images to fit the actual size they’re being rendered at—don’t just chuck in a 2000px-wide image because it “looks better”.
- Use srcset to let the browser choose the right size based on the screen.
- Lazy load anything that’s not needed on first load—but don’t lazy load above-the-fold stuff.
- CDNs like Cloudflare or EWWW can save you time and fix bad habits—but they won’t fix everything.
- Manual optimisation will always give you the best results—but yes, it’s more work.
If you’re building a new site, get this right from the start. If you’re fixing an old one, tools like EWWW and Cloudflare can get you most of the way there.
And one last point—test everything. Run your site through Google Speed Insights or Lighthouse and check the results after every change. What looks good in theory doesn’t always translate into a faster site in practice.
That’s it. Hopefully, this has been useful—or at the very least, helped you avoid a few of the rabbit holes I ended up going down.