Light page, low score
The usual reasons a page scores badly on mobile are weight and JavaScript. tilda.cc has neither problem. The mobile run downloaded 746 KB in 100 requests, and total blocking time, the measure of how long scripts kept the main thread busy, came to 33 ms. Lighthouse gives that full marks.
The score is still 62. Lighthouse publishes its weights, so the 38 missing points can be traced metric by metric:
| Metric (mobile, original) | Value | Points lost |
|---|---|---|
| Largest Contentful Paint | 5.2 s | 19.3 |
| Cumulative Layout Shift | 0.309 | 15.5 |
| First Contentful Paint | 2.3 s | 2.6 |
| Speed Index | 2.9 s | 0.5 |
| Total Blocking Time | 33 ms | 0 |
About 35 of the 38 points go to two things: the hero arriving late, and the layout moving after it arrives. Neither is a weight problem. The desktop run of the same page scores 97, with a layout shift of 0.02.
The hero is a background the browser has to discover
The largest element on the first screen is a 71 KB SVG illustration, and it is not an
<img>. It is a CSS background on a div:
<div class="t-cover" id="recorddiv2340846391" bgimgfield="img"
style="height:100vh;background-image:url('https://static.tildacdn.net/…/main_cover4_4.svg');">
<div class="t-cover__carrier" id="coverCarry2340846391"
data-content-cover-bg="https://static.tildacdn.net/…/main_cover4_4.svg"
data-content-cover-height="100vh" role="img"
aria-label="Create beautiful websites on Tilda with Ai">A browser’s preload scanner reads ahead for src and href attributes. It does not compute
styles, so a background image can only be requested once the element exists and its style
is resolved. Lighthouse’s breakdown of the LCP from the unthrottled trace shows what that
costs: 931 ms of waiting before the request starts, then 29 ms to download the file.
The file is not the problem. Finding it is.
The same cover appears in the markup twice, once inside t935__big-cover for wide screens
and once inside t935__small-cover for phones, with the same ids on both. The phone run
paints the second copy.
A 20-pixel image that weighs 30 KB
Tilda lazy-loads images by default, and it does it well: the visitor first gets a tiny preview, 20 pixels wide, and the full image only when it scrolls into view. On this page that is why 62 images cost only 392 KB. The lab run loaded 40 of these previews, and 33 of them weigh about 1.4 KB each, which is what a 20-pixel image should weigh.
Seven of them weigh between 27.8 and 30.6 KB. We fetched one:
$ curl -sI 'https://thb.tildacdn.net/tild3066-3237-4332-b437-616465316631/-/resizeb/20x/TYPO6png.png'
HTTP/1.1 200 OK
Content-Type: image/png
Cache: HIT| PNG chunk | Bytes |
|---|---|
| Image header (20 × 10 px) | 13 |
| Colour profile (iCCP) | 2,600 |
XMP metadata (XML:com.adobe.xmp) | 26,590 |
| EXIF | 180 |
| Pixel data (IDAT) | 543 |
| File total | 30,027 |
Less than 2% of the file is the picture. The rest is metadata from the file it was made from, carried through into a preview the size of a thumbnail’s thumbnail. The seven heavy previews add up to 204,328 bytes, which is 27% of everything the page downloads on a phone.
100 KB of icons for links that do not exist
The single largest inline script on the page is 100,164 bytes, a fifth of the 470,585-byte HTML. It is the social-links renderer for the reviews slider:
<script>function t_social_init(recid,groupName) {var rec=document.getElementById('rec' + recid);
if(!rec) return;var socialLinks=rec.querySelectorAll('.' + groupName + '-social-links');
…
phone+='<svg role="presentation" … viewBox="0 0 100 100" …><path fill-rule="evenodd" d="M50 100C77.6142…The function looks for elements with data-social-links inside the reviews block and draws an
icon for each network it recognises: 37 URL patterns, 58 inline SVGs, written out as strings.
We searched the rest of the document for an element that carries data-social-links. There
are none. Every byte of the library is downloaded, parsed and compiled, and it draws nothing.
On its own it compresses to 37.5 KB with gzip -9. The whole document compresses to 95.0 KB.
The heaviest response is the HTML
That is the strange shape of this page: the document is the largest single response it loads, at 112.9 KB over the wire, ahead of the 86 KB variable font and the 71 KB hero illustration.
We compressed the stored copy of the HTML ourselves:
| Bytes | Of original | |
|---|---|---|
| Uncompressed HTML | 470,585 | 100% |
| As transferred in the audit | 112,887 | 24.0% |
| gzip −9 | 95,024 | 20.2% |
| brotli −11 | 71,659 | 15.2% |
The transferred size sits within 100 bytes of what the same file gives at gzip’s fastest level (112,789). Tilda answered gzip on all 33 Tilda sites in our compression study, and this size is consistent with that. Taking the compressed HTML down to the brotli figure would save 41 KB on the first round trip, where bytes cost the most.
What we changed, and what we did not
| Metric (mobile) | Original | Through WebSpeed |
|---|---|---|
| PageSpeed score | 62 | 68 |
| First Contentful Paint | 2.31 s | 2.43 s |
| Speed Index | 2.92 s | 2.43 s |
| Largest Contentful Paint | 5.24 s | 4.48 s |
| Total Blocking Time | 33 ms | 0 ms |
| Cumulative Layout Shift | 0.309 | 0.251 |
Through the proxy the document arrives as 56.0 KB of brotli instead of 112.9 KB, six small stylesheets are inlined instead of fetched, connection and preload hints go to the top of the head, and the analytics and widget scripts wait for the page. That moves LCP by three quarters of a second and Speed Index by half a second.
It does not fix the two things this teardown is mostly about. The seven heavy previews arrive through the proxy byte for byte, and the icon library is still in the HTML. Layout shift improves but stays in the poor band, and first paint is 0.11 s later than without us. The score moves by six points, and the three rounds behind each median overlap; the limits below say how much.
Why this is not a Tilda problem
Most of what decides speed on this page Tilda gets right. Scripts are split into small files per feature, 24 of them, and together they block the main thread for 33 ms. Below-the-fold images load as tiny previews by default, so a page with 62 images downloads 392 KB of them. One variable font file covers the whole page.
The two odd costs come from content, not code. A preview inherits whatever the uploaded file carried, and a designer’s PNG exported with its metadata looks exactly like one exported without it until you open the bytes. The icon library ships because the reviews block supports social links, whether or not anybody filled them in. Both are invisible from the editor, which is the general shape of builder performance problems: each choice looks free where it is made.
Fix it yourself
None of this needs us. It needs someone to do it, test that nothing broke, and do it again after the next template change — which is the part we sell.
- Strip metadata before you upload, not after The 20-pixel previews on this page are generated from the uploaded files, and the heavy ones carry a 26.6 KB Adobe XMP packet and a 2.6 KB colour profile with them. Export with metadata off, or run the file through exiftool -all= or oxipng --strip all before it goes into the editor. Nothing about the image changes visually; the seven heavy previews on this page should drop to the 1.4 KB their neighbours weigh.
- Hand the hero to the preload scanner yourself The first-screen image here is a CSS background on a div, and a background is only requested once the stylesheet and the element are both known. A single line in the site's head code, <link rel="preload" as="image" href="…/main_cover4_4.svg" fetchpriority="high">, lets the browser start that download with the first bytes of HTML. Use the exact URL from the cover's background-image, or the hint is a wasted request.
- Open the largest response before the largest image On a page this light, the HTML itself is the biggest single download. In DevTools → Network, sort by size and look at the document row first. If inline code you never added is a fifth of it, that is a question for the block that ships it, and often the answer is a block you can replace with a simpler one.
What we measured, and what got worse
PageSpeed Insights (Lighthouse, mobile and desktop) run against the live site
and against the same page served through the WebSpeed proxy, on
2 Oct 2026. Audit d63342d4b49177 — the numbers
on this page are frozen at that run and are not restated later.
Proxy response re-checked on 5 Oct 2026: the proxied URL returns the page itself, not a redirect back to the origin. That check exists because a redirect makes both halves of a before/after the same page, and the improvement pure noise.
What the page still loaded
The accelerated run made 93 requests against the original's 100, and transferred 0.6 MB against 0.7 MB. We print this because a score can rise for two very different reasons — the page got faster, or the page got less of itself — and across our audit base the second is common enough to be worth ruling out in the open.
What got worse or stayed the same
- The mobile win is small and it sits inside the noise of a single sitting. We measure three rounds per side: the original scored 72, 62 and 62, the proxy 80, 67 and 68. The medians move by six points, but the original's best round beats the proxy's median. We publish the median because that is the rule for every audit, not because six points is a settled difference.
- Layout shift stays poor. Mobile CLS moves from 0.309 to 0.251, which is still past the 0.25 line, and we cannot tell you which element moves: the stored run records the total, not the culprit. On desktop the same page shifts by 0.02, so this is a phone-layout problem, and it is the one finding on this page we have not explained.
- We did not touch either of the page's two oddest costs. The seven metadata-heavy previews load through the proxy exactly as they do without it (the 40 previews weigh 250,644 bytes before and 250,631 after), and the 100 KB icon library is still in the HTML we serve. We checked the second one by fetching the proxied page on 5 October.
- First contentful paint on mobile got slightly worse, 2.31 s to 2.43 s. Speed Index and LCP improved, so the visible load finishes sooner, but the first pixel does not arrive sooner.
- Desktop moved from 97 to 98. There was no room on a desktop connection, and this whole story is about phones.
- One page, one audit, one day. Nothing here generalises to Tilda sites as a class; for that, see the platform page linked below.