Optimizing Images for Elementor: Ideal Sizes and Best Practices

Most slow Elementor sites we get asked to look at have the same problem: images uploaded straight from a camera or a stock library, 4,000 pixels wide and 2 MB each, placed in a column that renders at 600 pixels. The fix is not a magic plugin. It is sizing each image for the widest place it will ever be shown, serving it as WebP or AVIF, and letting WordPress and Elementor handle the rest. This guide gives you the exact pixel dimensions we use for each Elementor widget, the settings to switch on, and the mistakes that undo all of it.

Why image size decides your Core Web Vitals score

On a typical Elementor page, images account for 60 to 80 percent of the total bytes downloaded. Largest Contentful Paint (LCP), the Core Web Vital Google weighs most heavily, is almost always an image on Elementor sites: the hero background, the first slide of a carousel, or a featured image. If that one file is 1.8 MB, nothing you do with CSS minification will get you under the 2.5 second LCP target on a mobile connection.

There are three levers, and they compound. Dimensions (the pixel width and height of the file), format (JPEG versus WebP versus AVIF), and compression quality. Getting dimensions right alone usually cuts file weight by 70 to 85 percent. Switching a correctly sized JPEG to WebP takes another 25 to 35 percent off. AVIF saves a further 20 to 30 percent on top of WebP for photographs, though it is slower to encode and a little softer at very low quality settings.

Ideal image sizes for each Elementor widget

Elementor does not have a fixed “correct” size because it depends on your container width. Elementor’s default content width is 1140 pixels (Elementor → Settings → Layout, or Site Settings → Layout in the editor). Full-width sections stretch to the viewport. Starting from those two facts, these are the dimensions we upload for a standard desktop-first site. Width is the number that matters; height follows from your aspect ratio.

Placement	Upload size (px)	Aspect ratio	Target file size	Notes
Full-width hero / section background	1920 × 1080	16:9	Under 200 KB	Go to 2560 wide only if you have a lot of 4K desktop traffic. Serve a 1080 × 1350 crop for mobile via the Background Image responsive controls.
Boxed section background	1600 × 900	16:9	Under 180 KB	Covers 1140 px boxed content plus padding at 1.4× density.
Image widget, full column	1200 × 800	3:2	Under 150 KB	Matches the 1140 px content width with a small margin for retina.
Image widget, half column	800 × 600	4:3	Under 100 KB	A 570 px column at 1.4× density.
Image widget, third column	600 × 400	3:2	Under 70 KB	Icon Box and Image Box widgets sit here too.
Posts / Loop Grid featured image	800 × 450	16:9	Under 80 KB	Set the widget’s Image Size to “medium_large” or a custom 800 px size, not “full”.
Slider / carousel slide	1600 × 900	16:9	Under 180 KB	Only the first slide affects LCP. Lazy-load the rest.
Gallery thumbnail	600 × 600	1:1	Under 60 KB	Lightbox opens the “large” size (1024 px); upload at least 1600 px if you need a sharp lightbox.
Site logo	400 × 100 (SVG preferred)	4:1	Under 20 KB	SVG scales perfectly. Enable SVG uploads under Elementor → Settings → Advanced → Enable Unfiltered File Uploads, or use a sanitising plugin.
Testimonial / team avatar	300 × 300	1:1	Under 25 KB	Rendered at 80 to 150 px; 300 px covers retina.
Open Graph / social share	1200 × 630	1.91:1	Under 300 KB	Set per post in Yoast or Rank Math, not in Elementor.

The rule behind the table: upload at roughly 1.4 to 1.5 times the widest rendered width, not 2 or 3 times. Retina screens exist, but the visual gain from a full 2× image over 1.5× is hard to see on a photograph, while the byte cost is real.

How WordPress and Elementor pick which size to serve

Every time you upload an image, WordPress generates several copies: thumbnail (150 × 150, cropped), medium (300 px), medium_large (768 px), large (1024 px), plus 1536 px and 2048 px versions for anything wider than that. It then writes a srcset attribute so the browser picks the smallest copy that fits the slot. Elementor respects this for the Image widget when you leave Image Size at “Large” or “Medium Large”. It does not when you choose “Full”, and it never does for background images, which are plain CSS background-image rules with a single URL.

That last point catches a lot of people. A 1920 px hero set as a section background is served at 1920 px to a 390 px phone. The workaround lives in the widget itself: click the responsive mode icon next to the Background Image control and upload a separate, smaller crop for Tablet and Mobile. A 1080 × 1350 portrait crop at 90 KB does the job on phones and looks better than a squashed landscape image anyway.

If your theme registers its own sizes, you can add an 800 px size for Elementor’s Posts widget without another plugin:

add_action( 'after_setup_theme', function () {
    add_image_size( 'card-800', 800, 450, true );
} );

add_filter( 'image_size_names_choose', function ( $sizes ) {
    $sizes['card-800'] = __( 'Card 800', 'your-textdomain' );
    return $sizes;
} );

After adding this, regenerate thumbnails for existing uploads (the Regenerate Thumbnails plugin or wp media regenerate with WP-CLI) and pick “Card 800” in the widget’s Image Size dropdown.

Choosing a format: JPEG, PNG, WebP, AVIF or SVG

WordPress has accepted WebP uploads since 5.8 (2021) and AVIF since 6.5 (April 2024), so you no longer need a plugin to serve either format; you can upload them directly. Which one to pick is a short decision tree.

• Photographs: AVIF if your server has libavif (check under Tools → Site Health → Info → Media Handling for “AVIF support”). Otherwise WebP. Keep a JPEG only as a fallback for very old browsers, which in 2026 is a negligible share.
• Screenshots and flat graphics with text: WebP lossless, or PNG-8 if the palette is small. Lossy formats smear text edges.
• Logos, icons, simple illustrations: SVG. A 6 KB SVG beats any raster format and stays sharp at every size.
• Transparent images: WebP supports alpha and is usually 30 to 40 percent smaller than PNG-24. AVIF also supports it.
• Animated images: replace GIFs with a muted, looping MP4 or WebM in the Video widget. A 3 MB GIF is typically a 200 KB MP4.

On quality settings: WebP at quality 75 to 82 is the sweet spot for photos. AVIF at 55 to 65 gives comparable visual quality. Going lower saves little and starts to show banding in skies and gradients.

Step-by-step: an optimisation workflow that sticks

The most reliable setup we have found combines one decision before upload and one automatic layer after it. Here is the order we follow on client sites.

1. Resize before you upload. Use the table above. Squoosh (free, runs in the browser) lets you resize and export to WebP or AVIF at a chosen quality in one step. Batch tools like ImageOptim (Mac) or XnConvert handle folders.
2. Set a media upload ceiling. Even with good habits, someone will upload a 5,000 px image. Install an on-upload resizer (Imsanity is free and still maintained) and set the maximum width to 1920 px so the original itself is capped.
3. Convert the existing library. If you already have hundreds of JPEGs, use a conversion plugin. Elementor’s own Image Optimizer plugin (a separate install, not part of Elementor Pro) converts to WebP or AVIF, resizes to a maximum dimension you choose, and bulk-processes the library. It runs on a credit system: at the time of writing a free trial gives you 100 to 200 credits and paid plans start around $49 a year for 5,000 images. ShortPixel, Imagify and EWWW do the same job with different pricing models; EWWW can run entirely on your own server with no credits at all.
4. Turn on Elementor’s performance toggles. Under Elementor → Settings → Features (some items sit under Performance in newer versions), enable Optimized Image Loading, Lazy Load Background Images, and Optimized Gutenberg Loading. Optimized Image Loading adds fetchpriority="high" to the first image and lazy-loads the rest, which directly helps LCP.
5. Exclude the hero from lazy loading. Any image above the fold must not be lazy-loaded. WordPress skips the first image on the page automatically, but if your hero is the second image in the DOM (a logo comes first), add loading="eager" through the widget’s Advanced → Attributes field (Elementor Pro) or a small filter on wp_get_attachment_image_attributes.
6. Serve through a CDN that resizes on the fly. Cloudflare (with Polish or Image Resizing on paid plans), Bunny Optimizer, or Jetpack’s image CDN will convert and resize on the fly. This is the only practical way to handle responsive background images at scale.
7. Measure. Run PageSpeed Insights on a mobile profile before and after. Look specifically at the “Properly size images” and “Serve images in next-gen formats” audits; both should disappear from the list.

Mistakes that quietly undo your work

A few patterns come up again and again when we audit Elementor sites that “already optimised everything”.

• Image Size set to Full on every widget. This bypasses srcset entirely. Go through your templates and set it to Large or a custom size. Elementor’s Loop Grid in particular defaults to full-size featured images on some kits.
• Elementor’s “Custom” image size without regeneration. Choosing Custom and typing 800 × 450 only works for images uploaded after that point unless you regenerate thumbnails.
• Background images on mobile. Covered above, but worth repeating: a desktop hero as a mobile background is the single most common cause of a failed mobile LCP on Elementor sites.
• Double compression. Running ShortPixel and a CDN optimiser and Elementor Image Optimizer together does not triple the savings; it degrades quality and adds processing time. Pick one layer for conversion.
• Lazy-loading the hero. Some caching plugins apply loading="lazy" to everything. Check the rendered HTML of your hero image and exclude it in the caching plugin’s media settings.
• Huge images in Elementor’s Kit. Site Settings → Site Identity → Site Logo and Site Favicon pull from the media library. A 2,000 px PNG logo loads on every page.
• Ignoring the 2048 px size. WordPress generates a 2048 px copy of large uploads. If you never render anything that wide, remove it with add_filter( 'big_image_size_threshold', '__return_false' ) and drop the 1536 and 2048 sizes via intermediate_image_sizes_advanced to save disk space.

A worked example: one landing page, before and after

A recent marketing page for a community site built on BuddyX with Elementor had a 2.9 MB hero JPEG (4,032 × 2,268), six feature images at 1,600 px in three-column rows, and a testimonial grid with 1,200 px headshots. Mobile LCP measured 6.1 seconds in PageSpeed Insights; total page weight was 7.4 MB.

We resized the hero to 1920 × 1080 AVIF at quality 60 (168 KB), added a 1080 × 1350 mobile crop (94 KB), cut the feature images to 600 × 400 WebP (average 48 KB each), and the headshots to 300 × 300 WebP (around 18 KB each). We set Image Size to Medium Large on the Image widgets and enabled Optimized Image Loading. No other changes. Mobile LCP dropped to 1.9 seconds and page weight to 1.1 MB. The work took under two hours, most of it exporting files.

The same principle applies to any Elementor build, including pages assembled with the widgets in Wbcom Essential: the widget does not make the image heavy, the upload does.

FAQ

Does Elementor compress images automatically?

No. Elementor places whatever file is in your media library. WordPress applies a default JPEG quality of 82 to the resized copies it generates, but it does not touch the original and does not convert formats. Compression and conversion need either pre-upload work or a separate plugin.

Should I upload WebP directly or let a plugin convert?

Uploading WebP or AVIF directly is simpler and avoids plugin credits, and WordPress has supported both natively for years. The downside is that you lose the original JPEG if you later need to re-export. For most sites we upload WebP directly and keep source files in cloud storage.

What DPI should Elementor images be?

DPI is irrelevant on screen. Browsers only read pixel dimensions. A 1200 × 800 image at 72 DPI and the same image at 300 DPI render identically; the only difference is metadata.

Is AVIF safe to use in 2026?

Yes. Every current browser, including Safari since version 16, renders AVIF. The remaining caveat is server-side: your PHP image library needs AVIF support to generate resized copies, which you can check in Site Health. If it is missing, ask your host to enable it or stick with WebP.

Where to start

Open PageSpeed Insights, run your home page on mobile, and look at the “Properly size images” audit. Fix the single largest offender first, which is almost always the hero. Then set Image Size to Large on every Image widget, turn on Optimized Image Loading, and install one on-upload resizer so the problem does not creep back. Do those four things and you will have covered 90 percent of the gain before you spend a cent on credits. If you would rather have someone run the full audit and clean up the library, our WordPress performance optimisation service does exactly this, Elementor sites included.

Sources: Elementor Image Optimizer documentation, Elementor on WordPress image sizes, WordPress developer reference for add_image_size().