Table of contents9
A client once showed me her PageSpeed score with the pride of someone showing off a new car. Forty-one on mobile. She had built a gorgeous page: full-screen video hero, three image carousels, animated counters, parallax backgrounds on every section. It was beautiful. It was also so slow that half her visitors left before the hero finished loading. She had designed a page nobody would wait to see.
I am Sarah Mitchell, and I audit WordPress site speed for a living. Most of my work is not fixing servers or installing magic plugins. It is fixing layout decisions: the way blocks are stacked, sized, and nested on the page. This guide is my complete method for building block layouts that stay fast, covering the three Core Web Vitals that Google actually measures, and every technique uses only the block editor and sensible choices. No code required.
If your pages feel sluggish and you suspect the design itself is the problem, you are probably right. That is the fear I hear most: “Do I have to choose between a beautiful page and a fast page?” Here is my exact promise: this guide shows you how the way you compose blocks affects loading speed, interactivity, and layout stability, with concrete techniques for each, so you can keep your design and still hit strong speed scores. Whether your page scores 41 or 91 right now, you will finish this guide knowing exactly which layout choices to change. Let’s make your blocks fast.
One honest note before we start: layout optimization is not a substitute for good hosting and caching. Think of it as layers. Hosting is the foundation, caching is the walls, and layout discipline is the finish work. This guide covers the finish work, the layer most site owners completely ignore. For the full stack, pair this with the complete 2026 WordPress speed checklist.
What You Will Learn
- Understand the three Core Web Vitals in plain English
- Fix slow-loading heroes that kill your largest paint score
- Keep images from destroying your page weight
- Stop layout shifts that make buttons jump under fingers
- Reduce the invisible JavaScript weight in your layouts
- Measure correctly so you know what actually helped
Ready? Let’s get started.

Core Web Vitals in Plain English (No Jargon)
Google measures three things about your page’s speed, and every technique in this guide targets one of them. Let me translate them into human language, because the official names sound like engineering homework.
Largest Contentful Paint (LCP) answers: how fast does the biggest thing on screen appear? Usually that is your hero image or headline. If your hero takes four seconds to show up, your LCP is four seconds, and visitors feel every millisecond of it. This is the metric most block layouts fail, because heroes are where people put the heaviest media.
Interaction to Next Paint (INP) answers: when someone taps a button or opens a menu, how fast does the page respond? A page can load quickly but still feel sluggish if heavy scripts block every interaction. Bloated layouts with lots of animated blocks are the usual suspect here.
Cumulative Layout Shift (CLS) answers: do things jump around while the page loads? You have felt this. You are about to tap a button, an image loads above it, the button jumps down, and you tap the wrong thing. That rage-inducing jump is layout shift, and it is almost always caused by images and embeds without reserved space.
Here is the key insight from years of audits: the block editor gives you a natural advantage on all three, because it loads only the styles and scripts for blocks actually used on the page, producing leaner markup than heavier builders. But that advantage disappears the moment you stack heavy media and deep nesting without thinking. The editor is a fast car. This guide teaches you not to fill its trunk with bricks.
Let’s start with the biggest offender: the hero section.
Fix Your Hero: The LCP Killer Hiding at the Top
In almost every slow site I audit, the hero is the problem. It makes sense when you think about it. The hero is the first thing visitors see, so it is where everyone puts the biggest image, the background video, and the fanciest effects. The largest paint on your page is almost always in the hero, which means your hero largely determines your LCP score.
My first rule is blunt: no background videos in heroes. I know they look stunning. They also force visitors to download megabytes of video before the page feels complete. Every time I have replaced a client’s video hero with a well-chosen compressed image, the LCP improved dramatically and not one visitor complained about the missing video. Nobody ever emailed a site owner to say “I missed your background video.”
My second rule: compress the hero image aggressively and size it correctly. A hero image never needs to be wider than the screen it displays on. For most layouts, 1920 pixels wide is plenty for desktop, and you should serve smaller versions to phones. Upload the image at the right size instead of uploading a 5000-pixel original and letting the browser shrink it. Then compress it. Modern formats like WebP deliver the same visual quality at a fraction of the file size of old JPEGs. Aim for hero images under 200KB, and under 100KB if you can do it without visible quality loss.
My third rule: never lazy-load the hero image. Lazy loading is wonderful for images below the fold, but applying it to the hero delays the single most important paint on your page. In the block editor, select your hero image and make sure lazy loading is off for it, while keeping it on for everything below. This one toggle has fixed more LCP problems in my audits than any other single change.
Bonus Tip: If your hero uses a Cover block with a background image, keep the overlay simple. Heavy overlays and effects do not cost much performance by themselves, but every extra layer is another thing the browser must paint before the hero feels done. Simple and fast beats fancy and slow, every time.
Hero fixed. Now let’s talk about the thing that quietly doubles most pages’ weight: images everywhere else.

Tame Your Images: They Are 60 Percent of Your Page
Here is a number worth remembering: on a typical content page, images account for more than half of the total page weight. I have audited pages where a single uncompressed gallery weighed more than everything else on the page combined. Every image decision you make in the block editor is a speed decision, whether you realize it or not.
The workflow I teach every client has four steps. Step one: resize before uploading. If an image displays at 800 pixels wide in a column, do not upload a 4000-pixel original. Resize it to slightly above its display size. The block editor cannot slim down the bytes of an oversized upload; it can only display it smaller. The weight stays.
Step two: use modern formats. WebP images look identical to JPEGs at dramatically smaller file sizes. If your workflow still produces JPEGs and PNGs, convert them. Many optimization tools do this automatically on upload now. This single change has cut client page weights in half in my audits, with zero visible difference.
Step three: lazy-load everything below the fold. The block editor enables lazy loading on images by default, and you should keep it that way for every image visitors must scroll to see. Below-fold images should not compete with the hero for bandwidth. Only the hero gets the VIP treatment of loading immediately.
Step four: question every image. Before adding an image to a layout, ask what it does for the visitor. Decorative stock photos that add no information are pure weight. I have removed entire image carousels from client pages and watched both speed scores and conversion rates improve. Fewer, better images beat more, weaker images on every metric that matters.
Note: Galleries deserve special attention. A twelve-image gallery can quietly add megabytes to a page. If you must have one, keep the thumbnails small, lazy-load them all, and link to full-size versions instead of loading them inline. Your visitors’ data plans will thank you.
Images under control. Next is the metric that annoys visitors the most: things jumping around.

Kill Layout Shift: Stop Buttons From Jumping
Layout shift is the most viscerally annoying speed problem. Slow loading is frustrating, but at least it is honest. Layout shift is betrayal: the page invites you to tap, then moves the target. I once watched a user testing session where a visitor tried to tap a “Buy Now” button three times, and an ad loaded above it each time, pushing the button down. She gave up and closed the tab. That sale did not go to a competitor with a better product. It went to a competitor with a more stable page.
The cause is almost always the same: content loading without reserved space. When the browser does not know how tall an image or embed will be, it renders the page assuming zero height, then shoves everything down when the content arrives. The fix is to always give the browser the dimensions in advance.
In the block editor, this means three habits. First, always set image dimensions. When you insert an image, the editor usually knows its aspect ratio. Do not strip that information. If you crop or resize, keep the ratio locked so the browser can reserve the right space. Second, give embeds and iframes fixed aspect ratios. Video embeds are the worst shift offenders after images. A 16:9 wrapper around your video means the space is reserved before the video loads. Third, avoid inserting content above existing content after load. Popups, banners, and notices that appear at the top of the page after everything renders will shift the whole layout. If you must show them, reserve their space from the start.
Web fonts cause a subtler form of shift. When a custom font loads late, text reflows into its final shape and everything below it moves. The fix is to limit yourself to two font families maximum and make sure they load efficiently. Every additional font is another render-blocking request and another chance for text to jump. I have seen pages load five font weights “just in case.” Two is enough. Your design will survive.
Test for shift the honest way: load your page on a throttled connection and watch it render. If anything moves after the first paint, you have shift to fix. Chrome’s developer tools will even highlight the shifting elements for you. Fix them one by one until the page renders like a photograph developing: appearing, never jumping.
Stable layouts done. Now the invisible weight: scripts and block bloat.

Lighten the Invisible Load: Scripts, Nesting, and Block Discipline
Here is something that surprises most site owners: your layout choices affect how much JavaScript runs on the page. Every fancy block with animations, sliders, counters, and interactive effects brings scripts along. One animated block is harmless. Fifteen of them on one page is a traffic jam on the browser’s main thread, and that jam shows up as poor interactivity scores.
My rule is simple: one interactive showpiece per page. If the hero has an animated element, the rest of the page stays calm. If a testimonial slider is the star, nothing else moves. Visitors cannot appreciate five animations at once anyway. Pick the one that serves your goal and let the rest of the page be still. Your INP score and your visitors will both improve.
Deep nesting is the quieter problem. I have opened client pages with groups inside columns inside groups inside columns, seven levels deep, built by dragging blocks around for months. Every nesting level adds markup the browser must parse and style. Flatten your layouts ruthlessly. If a Group block contains only one Columns block which contains only one Paragraph, you have two unnecessary wrappers. The block editor’s speed advantage over page builders comes from lean markup. Do not give that advantage away with nesting lasagna.
Bonus Tip: Audit your plugins with layout speed in mind. Some plugins inject scripts on every page whether their blocks are used or not. If a plugin’s blocks appear on only three pages, but its scripts load everywhere, that is weight you pay on every visit. Keep plugins whose features you actually use across the site, and reconsider the rest. Lean plugins plus lean layouts is how pages stay fast for years, not just after one optimization sprint.
With the page lean and stable, the last step is measuring honestly so you know what worked.
Measure Right: Test Like a Visitor, Not Like an Owner
I have watched site owners test their speed by loading the page on their office fiber connection, on a powerful laptop, with the cache warm, and declare victory. Then a real visitor on a mid-range phone with a shaky 4G connection waits six seconds. Test like your worst-connected visitor, not your best-connected self.
Use PageSpeed Insights and look at the mobile score first. Desktop scores are almost always higher and almost always less relevant, because most of your visitors are on phones. Run the test three times and take the middle result. Single runs fluctuate. After each change you make from this guide, re-test and write down the before and after. This log becomes your proof of what works on your specific site.
Change one thing at a time. I know I sound like a broken record, but this is where it matters most. If you compress images, flatten nesting, and remove the video hero all in one afternoon, you will never know which change did the heavy lifting. Worse, if something breaks, you will not know which change broke it. One change, one test, one note. Slow is smooth, and smooth is fast.
Finally, remember that field data beats lab data. PageSpeed Insights shows you both: lab scores from a simulated test and field data from real visitors over the past month. Lab data tells you if your changes worked today. Field data tells you if your visitors actually feel the difference. Optimize for the field, and check it monthly. Speed is not a project you finish. It is a habit you keep. The complete block editor guide is a good companion reference while you build these habits into your daily workflow.
You now know exactly which layout choices affect speed and how to fix them. Let me answer the questions I hear in every audit.
Frequently Asked Questions
Will optimizing my layout really change my PageSpeed score? Yes, often dramatically. In my audits, layout fixes like hero image optimization, lazy loading discipline, and shift elimination typically move mobile scores by 15 to 30 points. The exact gain depends on how heavy your starting layout is, but layout is almost always the biggest lever after hosting.
Do block patterns slow down my site? No. Patterns are just saved groups of blocks. Once inserted, they are ordinary blocks with ordinary markup. A page built from patterns loads exactly like the same page built by hand. Patterns save your time, not your visitors’ bandwidth, and that is fine.
How many images are too many on one page? There is no magic number, but there is a magic question: does each image earn its weight? I have seen fast pages with twenty well-optimized images and slow pages with three massive uncompressed ones. Count bytes, not images. If your total image weight stays reasonable and below-fold images lazy-load, you are fine.
Should I worry about Core Web Vitals if my site is new with little traffic? Yes, but proportionally. Build the habits in this guide from day one, because retrofitting speed into a hundred heavy pages is miserable. But do not obsess over perfect scores before you have content worth ranking. Good habits now, fine-tuning as you grow.
Can a beautiful page also be a fast page? Absolutely, and that is the entire point of this guide. Beauty and speed conflict only when beauty means heavy: uncompressed images, video heroes, and animation overload. A beautiful page built from well-chosen images, clean typography, and generous whitespace is naturally fast. Restraint is the fastest design tool you own.
Final Thoughts
That client with the score of 41? We did not redesign her page. We kept every section, every headline, every testimonial. We compressed the images, replaced the video hero, flattened the nesting, and reserved space for the embeds. Her mobile score went to 94. Same beautiful page. Same content. Just built with speed in mind.
That is what I want you to take from this guide. Speed is not the enemy of good design. Sloppy layout habits are. Every technique here is a choice you make while building, not a chore you do afterward. Build lean heroes, respect your images, reserve your space, flatten your nesting, and measure honestly.
Pick one page this week, run it through PageSpeed Insights, and apply just the hero fixes. Watch the number move. Then come back and tell me your before-and-after in the comments. Those numbers are my favorite thing to read.










