If you ran your page through PageSpeed and saw a low score, the first instinct is usually to blame the server or the platform. It almost never is.
On a page we analysed in September, the server answered in 40 milliseconds and the main image downloaded in under 1 second. The score was still low. The weight was in the page content, and most of it the client could fix without help from anyone.
Below are the five factors that show up most often, in the order they usually weigh, with what to do about each one. There is a checklist at the end.
Where the time goes
A PageSpeed score adds up several things, but in practice almost all the weight of a builder page sits in five places. On that measurement the page came to 2,520 KB in total, and around 1,700 KB of it was recoverable without leaving the editor:
- One unoptimised image905 KB
- Form captcha542 KB
- Fonts205 KB
- International phone field178 KB
- Icon library152 KB
For comparison: a whole light page, everything included, usually weighs less than 1,000 KB.
Heavy or unoptimised images
The builder has an automatic optimisation that converts your images and serves the right version for each screen size. When it is off for an image, the file reaches the visitor exactly as you uploaded it, at the original size and format. A camera photo or a screenshot can run to several megabytes.
Check that image optimisation is on for every image on the page. Before uploading, resize the image to the width it actually appears at: above 1200 pixels wide is waste on most pages. Aim for under 200 KB for the top image and under 150 KB for the rest.
First things first: PNG, JPEG or WebP?
This is the decision that ruins the most otherwise good pages. The three formats exist for different jobs, and picking the wrong one multiplies file size without improving anything on screen.
| Format | Use for | Do not use for |
|---|---|---|
| JPEG | Photos. Anything with a person, a room, a photographed product. | Logos, icons, screenshots or anything that needs a transparent background. |
| PNG | Logos, icons and images that need a transparent background. | Photos. This is where the expensive mistake lives: the same photo as a PNG usually weighs 5 to 10 times what it would as a JPEG. |
| WebP | Almost everything. It replaces the other two, supports transparency and lands about 30% smaller than a JPEG of equivalent quality. | Nothing, in practice. Every current browser opens WebP. |
| SVG | Logos, icons and line art. A few KB, and sharp at any screen size. | Photos. SVG is not built for images with texture. |
The short rule
Is it a photo? JPEG or WebP. Does it need a transparent background? PNG or WebP. Is it a logo or an icon? SVG, if you have the file. And if you can only change one thing today, save everything as WebP.
The screenshot trap
Screenshots come out as PNG by default on practically every computer. Take a screenshot, upload it straight away, and you have uploaded a photo as a PNG without noticing. That is exactly what happened on the page we analysed: a 905 KB file that, once converted, would land near 180 KB.
Too many fonts
Each font family is a file the browser must download before it can draw the text, and each weight inside it (light, regular, bold, and the italic of each) is another file. It is very common for a page to request three full families, with every weight, while actually using two or three variations.
Pick one family and keep two or three weights, usually regular and bold. If the headings use a different font from the body, that is two families, and still with few weights each.
The entire icon library
When you use a ready-made icon from the editor, the page usually downloads the complete icon pack, not just the one you picked. That is two large files to deliver, sometimes, two or three drawings on screen.
If the page uses few icons, it is worth swapping them for individual SVG images, a few KB each. If the page uses many, the pack earns its keep and this is not where you should start.
What the form brings along
Some fields carry luggage. The international phone field, the one with the little flag and the country picker, downloads the dialling codes of every country and an image holding every flag in the world. The captcha is the extreme case: on the page we measured it passed 500 KB on its own.
If you only serve one country, swap the international phone field for a plain phone field. The captcha is your call: worth keeping where real spam arrives, but on a contact form with a handful of submissions a day it usually costs more than it protects.
Duplicated pixels and tags
It is common for the same pixel to be installed twice: once directly on the page and once through Tag Manager. Both load, both occupy the page, and the data arrives duplicated in the report.
Pick one path. If you use Tag Manager, keep every pixel there and remove the loose ones from the page. Also ask whoever runs your traffic to fire them after the page appears, rather than during loading.
The part with no switch
One piece does not depend on you. The builder marks every image on the page for deferred loading, including the one at the top. The idea behind it is sound: an image far down the page only downloads once the visitor scrolls to it, and that saves time.
The problem is that the rule applies to all of them, without exception. The top image, which is precisely the one Google times to grade the page, joins the waiting queue too. In our measurement the browser took 4 to 6 seconds just to start downloading that image, long after it had everything it needed to do so.
There is no switch for this in the editor. What exists is a snippet that gives priority back to the first images on the page. It helps, but it has two limits worth knowing before you paste it:
<script>
(function () {
var QUANTAS = 2, tratadas = 0;
function priorizar(img) {
if (!img || img.dataset.hlLcpFix) return;
img.dataset.hlLcpFix = '1';
img.setAttribute('fetchpriority', 'high');
if (img.getAttribute('loading') === 'lazy') img.setAttribute('loading', 'eager');
tratadas++;
}
function varrer(no) {
if (tratadas >= QUANTAS || no.nodeType !== 1) return;
if (no.tagName === 'IMG') return priorizar(no);
var imgs = no.querySelectorAll ? no.querySelectorAll('img') : [];
for (var i = 0; i < imgs.length && tratadas < QUANTAS; i++) priorizar(imgs[i]);
}
var obs = new MutationObserver(function (lista) {
for (var i = 0; i < lista.length; i++)
for (var j = 0; j < lista[i].addedNodes.length; j++) varrer(lista[i].addedNodes[j]);
if (tratadas >= QUANTAS) obs.disconnect();
});
obs.observe(document.documentElement, { childList: true, subtree: true });
document.addEventListener('DOMContentLoaded', function () {
if (tratadas < QUANTAS) varrer(document.body);
obs.disconnect();
});
})();
</script>In the funnel or site editor, under Settings, Tracking Code, in the Head field. Paste it as high as possible above whatever is already there.
The two limits of this snippet
- It acts while the page is already loading. Despite the field name, the builder does not place this code at the top of the page: it delivers the page first and inserts the snippet right after. The adjustment happens with loading already under way. It helps, but it does not deliver the full gain the same code would give if it sat at the top.
- It only applies when the top of the page is an image. If the top is a section with a background image, or a text heading, the snippet has nothing to adjust. And that is the most common case: on three of the four builder pages we measured, the main element at the top was a section background image. There, what fixes it is weight: keep that background image under 200 KB, at the width it actually appears.
To find out which case you are in: in the PageSpeed report, look for the Largest Contentful Paint (LCP) element. If it shows an image, the snippet applies. If it shows a section block or text, skip the snippet and deal with the background image weight.
If you would rather not touch this
This adjustment is the only part of this guide that touches code, and it is not the one that pays off most. If you would rather not go near it, talk to us and we will apply it on your account. The rest of the list, where most of the gain lives, you can do yourself in the editor.
Checklist
In the order that usually pays off most:
- 1Find the heaviest image on the page and check whether it is a photo saved as PNG. If so, convert it to JPEG or WebP.
- 2Check that image optimisation is on for every image.
- 3Resize images to at most 1200 pixels wide before uploading.
- 4Keep one font family with two or three weights.
- 5Drop the icon pack if the page uses few icons.
- 6Swap the international phone field for a plain one, if you only serve one country.
- 7Decide whether that form really needs a captcha.
- 8Check whether any pixel is installed twice.
- 9If the top of the page is an image, apply the header snippet (or ask us to). If it is a section with a background image, keep that image under 200 KB.
What to expect at the end
It is worth agreeing on the target before you start. Building the page in a builder carries a fixed cost: the platform loads its own code before your content, and that cannot be switched off anywhere.
With the list above done, expect the page to land in a good performance range on mobile, well above where it started. Getting close to 100 is the reality of a site built by hand, line by line, with no visual editor. Anyone promising that inside a builder is selling what the tool does not deliver.
The good news is that what the visitor actually feels lives almost entirely in the first part: the page opening quickly and showing its content without the screen jumping. The list above handles that.