How to Optimize Images in Elementor

A photo can look small in Elementor while still requiring a large download. The editor controls how an image looks, while WordPress, your hosting setup and optimization plugins help determine which file visitors receive. This guide explains how those pieces fit together, with particular attention to image widgets, container backgrounds and the first large image on a page.

Choose the right Image Resolution in Elementor widgets

Select an Image widget and open its Content tab. Look for Image Resolution, called Image Size in some widgets or older versions. This chooses a WordPress image size, such as Medium, Large or Full. The separate Width and Max Width controls determine how much space the image occupies in your layout. Elementor's Image widget documentation describes these controls.

Full does not simply mean “fill the column.” It selects the full-size attachment as the image source. For a large upload, WordPress may already have created a scaled full-size copy, so this is not always the untouched camera original. WordPress explains this behavior in its image sub-size generation reference.

There is another layer: when the published image includes srcset and sizes, the browser can choose among available image files according to the layout, screen density and its own loading decisions. Selecting Full therefore does not guarantee that every visitor downloads the largest file. Still, an appropriate widget resolution and a sensibly sized upload provide a better starting point than relying on automatic selection alone.

These are examples, not required Elementor dimensions. WordPress's registered sizes depend on your settings, theme and plugins. A file also needs enough height for its intended crop. Doubling the display width can help on a high-density screen, but it is a quality-versus-size decision rather than a rule to export every image at twice its dimensions.

Custom resolution can be useful when the standard sizes do not suit a placement. Check that the resulting crop is correct and that the published image still has suitable responsive candidates. Do not assume Custom always improves delivery or always disables responsive images.

Changing Style → Width or Max Width does not resize or recompress the stored file. Responsive markup may help the browser request a smaller candidate, but a visual width adjustment alone is not proof that less data is being downloaded.

Optimize container backgrounds for mobile

An image added through a container or section's Style → Background settings usually becomes a CSS background. Unlike an HTML image, a CSS background has no srcset or sizes attributes. Unless another delivery system provides alternatives, a desktop background can therefore be used on a phone too.

First decide whether the image belongs in the background. A decorative texture or photograph may suit that role. A product photograph, diagram or image that carries essential information usually works better as an Image widget, where it can have alternative text and responsive image candidates.

For a background that needs a different composition on mobile:

1. Select the container or section and open Style → Background.
2. Use the responsive control for the background image, where available in your editor, to switch to the mobile breakpoint.
3. Choose a mobile copy cropped for that container's proportions. A tall hero may need a portrait crop; a short banner may still need a landscape crop.
4. Choose Cover when the image should fill the area without distortion. Cover preserves proportions by cropping anything that falls outside the container.
5. Adjust the background position so the subject remains visible, and preview nearby screen widths as well as the exact breakpoint.

Check the container's height, text contrast and image request on the published mobile page. A different crop can improve composition, but it only reduces downloading if the mobile version actually replaces the larger file. Hiding a separate desktop section is not reliable evidence that its images will never be requested.

Load the main hero image without delay

Largest Contentful Paint (LCP) measures when the largest visible content element appears in the initial viewport. That element may be a hero image, a background image or a text block. Find the actual LCP element in a performance report before changing image priorities.

Lazy loading is useful for images farther down the page. It can delay an important hero image, however, because the browser waits to decide when that image is needed. Google's LCP optimization guide recommends making the LCP image discoverable early and avoiding lazy loading for it.

• Start with Elementor's automatic handling: Enable Optimized Image Loading in the performance settings described below, then check the published output.
• Check other lazy-loading systems: A caching or image optimization plugin may change the result. If it delays the hero image, use that plugin's exclusion setting for the relevant image or element.
• Understand eager loading and priority: An HTML image without lazy loading can begin loading normally. loading="eager" explicitly requests that behavior; fetchpriority="high" is a separate priority hint. Giving every image high priority defeats the purpose.
• Treat background heroes separately: They do not use an image element's loading attributes. If your background is the LCP element and its request starts late, investigate when its CSS or lazy-loading script exposes the image URL. Resizing alone will not fix that delay.
• Review hero sliders: A single static image is easier to prioritize. If you keep a slider, check whether hidden slides compete with the first visible slide during loading.

Reserve image space before loading

Cumulative Layout Shift (CLS) measures unexpected movement of visible content. If the browser does not know how much space an image needs, text and buttons may move when it arrives. Image dimensions help the browser reserve that space.

1. Keep width and height attributes: Standard WordPress image output normally includes them. They describe the image's proportions and can work alongside responsive CSS.
2. Define the intended frame: For consistently cropped cards, reserve space with a suitable aspect ratio or explicit layout dimensions. Use the controls your widget provides, or CSS aspect-ratio where needed. If the image must fill a fixed frame, object-fit: cover preserves its proportions while cropping.
3. Check templates with different content: In Theme Builder or Loop Grid layouts, preview posts with landscape, portrait and missing featured images. Give the card a predictable image area, and choose a fallback image if the template needs one.

A CSS background does not give its container a natural height. Its space comes from the container's layout, content, padding or minimum height. Check those settings at each breakpoint rather than expecting the background file to hold the section open.

Check galleries, carousels and lightboxes separately

A gallery has two different jobs: displaying a compact overview and showing enough detail when someone opens a picture. Those jobs may need different files.

• Choose resolution from the visible slide or card: A carousel showing four small pictures does not need the same resolution as a single full-width slide. Check the mobile layout too, where fewer slides may make each image wider.
• Separate preview and enlarged images: Use an appropriate widget resolution for the grid, then configure Media File links and Lightbox if visitors need an enlarged view. Keep that larger file optimized as well. Verify the requests before and after opening the lightbox; preloading behavior can vary.
• Inspect the loop template: For archive cards and Loop Grids, adjust the Featured Image widget inside the loop item. A repeated oversized image can make the whole archive expensive even when each card looks small.

Choose a format that suits the image

Compare formats at the same dimensions and at a quality level you would actually publish. There is no fixed percentage saving that applies to every picture.

• WebP: A useful starting point for photographs and many illustrations. It supports lossy compression, lossless compression and transparency. Try JPG to WebP or PNG to WebP, then inspect fine details and edges.
• JPG: A practical option for photographs when another part of your workflow requires it. Adjust quality by comparing the result rather than treating a particular percentage as a universal setting.
• PNG: Useful for lossless graphics, screenshots and workflows that require it. Transparency alone is not a reason to prefer PNG over WebP. Photos saved as PNG are often much larger than a suitable lossy export.
• AVIF: Worth comparing for photos when your WordPress installation, host and optimization workflow support it. Check both upload processing and published delivery before converting a whole library.
• SVG: Suitable for vector logos and icons. Use files from trusted sources and follow Elementor's SVG upload guidance, including its sanitization and upload precautions.

Our guide to image formats for the web explains the trade-offs in more detail.

Prepare each image for its placement

Keep your original separately and prepare an export for the website. This makes the full-size file manageable too, which matters when it is used in a background or opened from a gallery.

1. Measure the largest intended display: Check desktop and mobile. An image beside text on desktop can become a wider, full-row image on a tablet.
2. Crop for the layout: Use the image cropper to remove unnecessary space and preserve the subject. Leave room for any overlaid text.
3. Resize a copy: Use the image resizer to compare dimensions that suit that placement. Avoid enlarging a small source just to reach a preset width.
4. Compress and inspect: Use the image compressor and compare the export at its intended display size. A 100–200 KB hero or a content image below 100 KB can be a useful starting budget, but detail, dimensions and the total page weight determine what is reasonable.
5. Name and describe it: Use a descriptive filename such as office-reception.webp. Add alt text that conveys a meaningful image's purpose; decorative images normally need empty alt text. Follow Google's image SEO guidance without stuffing keywords into either field.

If a plugin will optimize the upload again, compare the final delivered image. Repeated lossy compression can damage fine textures or text even when every individual quality setting appears reasonable.

Check Elementor's image performance settings

In the WordPress dashboard, current Elementor documentation places these controls under Elementor → Editor → Settings → Performance. Older installations may show a different menu structure. The official performance settings guide distinguishes the Performance tab from the Features tab.

• Optimized Image Loading: Helps prioritize the likely LCP image and manages lazy loading for images farther down the page. See Elementor's loading optimization guide. Verify the actual result, especially when other plugins also alter image markup.
• Lazy Load Background Images: Defers background images, with an exception for the first one according to Elementor's documented behavior. Check that the background visible at the top of your actual page loads promptly.

Enable one change at a time, clear the relevant caches and test the published page. These settings affect loading behavior; they do not replace choosing suitable dimensions or compressing the files themselves.

Verify the published page

Start with a visual check while signed out: is the crop right, is text readable, and does the layout stay steady as images appear? Then investigate further if the image file is still large, looks blurry or loads slowly.

1. Open the published page in a private window. Open Developer Tools, choose the Network tab, filter by Img, and enable Disable cache while the tools remain open.
2. Reload and sort image requests by transferred size. Start with the largest files and those visible immediately.
3. Inspect a request's URL and preview to identify its actual dimensions. Compare them with the displayed size and screen density. A 2400-pixel file in a 350-pixel card deserves investigation; a 700-pixel candidate may be appropriate on a 2× screen.
4. For an HTML image, inspect its srcset and sizes if the browser keeps choosing an oversized candidate. Check loading and priority attributes on the actual <img>, not just its surrounding widget.
5. Switch to mobile emulation before a fresh reload and check which background and image candidates are requested. Confirm the appearance on a real phone as well.

Run PageSpeed Insights before and after the change under comparable conditions. Look at the LCP element and image-related findings rather than relying on a single overall score. A small hero that starts downloading late has a different problem from an oversized image that starts promptly.

If an old image remains, check the widget's selected file and breakpoint settings first. Then clear the relevant page, optimization and CDN caches. When stale Elementor CSS is responsible for an old background URL, use Elementor's file or CSS regeneration option under its Tools settings; its label varies between versions. Regenerating CSS does not create missing WordPress thumbnail sizes.

Example: an image beside a text column

Suppose a team photograph starts at 4800 × 3200 pixels and 5.4 MB. Its column is about 550 pixels wide on desktop, but the image becomes a full row at a tablet breakpoint.

1. Check the widest placement: If the tablet image reaches about 700 pixels, use that width when comparing export candidates rather than basing everything on the narrower desktop column.
2. Prepare the crop and dimensions: If a 4:3 crop suits the composition, compare 1000 × 750 and 1400 × 1050 exports. Check faces and other important detail at the final display size.
3. Compare compression: Try WebP at a moderate quality setting and inspect the result. Record the actual file size; a detailed group photograph may need more data than a simple portrait at the same dimensions.
4. Configure the widget: Upload the chosen export, add appropriate alt text and choose a suitable Image Resolution. A 1400-pixel upload may need Full for the larger candidate to be available; verify the responsive files the page provides.
5. Verify the outcome: Check desktop and mobile requests, sharpness and layout stability. If the photo is lower down the page, lazy loading may be appropriate; if it is the LCP image, it should load promptly.

Troubleshoot common Elementor image problems

Why does an image look blurry?

Check the widget's Image Resolution, the source image's dimensions and the actual file selected by the browser. A 300-pixel thumbnail stretched across a 600-pixel column will look soft, but increasing resolution cannot recover detail missing from the original. Also check compression and any crop that enlarges a small part of the source. See our guide to blurry website images.

Why is a mobile background missing or cropped badly?

Check the image assigned at the mobile breakpoint, inherited settings, visibility controls and container height. Cover crops the image to fill the container; adjust position or supply a better crop when the subject disappears. It should not distort the image's proportions. If the file itself fails to load, inspect its request for an error before changing the crop.

Why are image changes missing from the live site?

Confirm that the correct widget, template and breakpoint were updated. Inspect the live image URL to distinguish an old file from old styling. Clear the relevant caches, and regenerate Elementor's CSS if it still references the previous background. Re-uploading repeatedly without identifying the stale layer can leave unnecessary duplicates.

Frequently asked questions

Should I always avoid Full resolution?

No. Full can be appropriate for an upload prepared for that placement. The important checks are the source dimensions, responsive candidates and downloaded file. Avoid treating Full as a way to make an image fill its column; that is a layout setting.

Does Elementor automatically compress uploaded images?

The page builder's resolution and loading controls do not compress your upload. WordPress creates image sizes and applies format-specific quality settings when generating files, but that does not guarantee an optimized library. Elementor also offers a separate Image Optimizer product, and your host or plugins may provide similar processing. Check which system is active on your site before adding another.

Can I upload WebP images directly?

WordPress supports WebP uploads. Your host also needs appropriate image processing support to generate resized versions, so test one file through upload, widget selection and published delivery before converting an entire library.

What dimensions should I use for a hero image?

Choose dimensions from the hero's largest display size and crop. A 1600–1920-pixel-wide copy is a reasonable starting comparison for many desktop layouts, but it is not an Elementor limit or a guarantee of sharpness on every screen. Check whether mobile needs a separate crop and compare file weight alongside visible detail.

Will image optimization improve Google rankings?

It can improve loading and support a better page experience, but higher rankings are not guaranteed. Google's page experience guidance explains that Core Web Vitals are used by its ranking systems, while good scores alone do not guarantee top rankings. Relevant images, descriptive filenames and useful alt text also help search engines understand your content. See our alt text and filename guide.