Case study
Why your website is slow on mobile when the pages are light
Our own site scored slow on phones in Google's speed test, even though the pages are light and mostly text. The opening screen was waiting for things it did not show.
Key takeaways
- The speed test waits for the largest element on the opening screen, so a late cookie banner can make a light page score slow on phones.
- A page should load only the fonts and words of the language it is in; other languages can arrive when a visitor switches.
- Scripts from other companies, chats and messaging tools can wait until after the page is drawn.
- Hidden menus and unused code still cost a phone time, because the browser may lay them out or fetch their files.
- Find the largest element before you change anything; that is what the test is measuring.
When your website is slow on mobile, the delay is often not in the words or pictures you put there. It can be something the opening screen is waiting for that it never shows. We saw this on our own website: Google's speed test rated it slow on phones, on every page, in every language, although the pages are light and mostly text.
What a slow opening screen costs a business like yours
How quickly the main content appears on a phone is one of the measures Google reads when it ranks pages. A visitor on a phone does not wait for a half-drawn page. On a site whose job is to bring in enquiries, six or seven seconds of waiting is when people leave. That was the situation we were looking at: not a heavy site, but one that kept people waiting.
The symptom: a page that sits half-drawn
On a slow mobile connection, our opening screen sat half-drawn. The box asking about cookies arrived seconds after everything else. The text beside the app store badges jumped when the badges loaded. Google's speed test put the largest piece of content at six to seven seconds on a phone, on every page, in every language.
What our engineer found
The largest piece of content was not a picture or a heading. On a phone it was the cookie box, the biggest block of text on the opening screen. Google's speed test calls the largest piece of content the largest contentful paint: the element it waits for before calling the page drawn.
- The browser added the cookie box only after every script had run, five to seven seconds in on a slow connection. The whole page was judged by its slowest arrival.
- Nine font files (242 KB) loaded ahead on every page, although the Cyrillic letters are used only by the Russian page and the extended Latin letters by two words on the Arabic page. That is fonts slowing down a website for alphabets the reader may never see.
- A closed phone menu held the names of the five languages, each in its own alphabet. It was hidden, but laid out, so the browser fetched 170 KB of fonts for alphabets nobody had opened.
- The script every page shared carried the words of all five languages, 80 of its 95 KB, and used one of them. That is a multilingual website loading all languages on every page.
- A messaging app's script (25 KB, fetched from another company) sat in front of our own scripts for every visitor, although almost nobody opens our site inside that app.
- A notification library nobody called and a request library rode along on every page. Every page carried all forty of the site's building blocks when it uses about a dozen. The store badges had no size of their own until their pictures arrived.
- On fast computers, such as the ones speed tests run on, the fonts for the hidden menu and the chat could start before the opening screen was drawn, and a test counted them against the page one time in two.
The turning point was seeing that none of this was content. The opening screen was waiting for things it did not show.
Why your website is slow on mobile when the pages are light
This is not a mistake only we made. When a site is built over time, each tool arrives with its own scripts, fonts and settings. A cookie banner is added for privacy, a chat button for sales, a map for directions. Each one is useful, and each one can put something in front of the opening screen. A cookie banner slowing down a website is a clear example: because it can be the biggest block of text on a phone, it can become the element the test waits for, even though it is not your content. Any element that arrives late and is large enough can become that benchmark.
What we changed and what the site has now
We moved everything the opening screen does not show to after the page is drawn. The cookie box now comes inside the page itself and is drawn with the opening screen. A visitor who already answered never sees it flash, because their answer is read before anything is drawn. A page loads ahead only the three font files of the Latin alphabet; the others arrive only when a page has a letter that needs them. The language row of the phone menu is added once the page can respond, the moment anyone can open the menu. Each language's words are a file of their own, fetched only by a page in that language; switching language fetches the new words before the page changes, so no page ever shows in the wrong words. The messaging app's script and the site chat load after the page, when the browser is idle. The unused notification library is gone, requests use what the browser already has, and each page carries only the building blocks it shows. The store badges carry their own sizes, so nothing moves when they arrive, and the hidden menu's fonts and the chat now wait until the page has actually been drawn.
The changes went live on 10 October 2026 on every page, in all five languages. When we checked on 14 October, a page loaded ahead three font files, about 102 KB, where it had loaded nine (242 KB). The script every page shares is about 22 KB compressed, where it was 95 KB, and the home page's style sheet went from 27 to 22 KB. The cookie box is part of the page as it arrives, drawn with the opening screen instead of after every script. We have not yet taken a new speed-test figure for the opening screen, so we are not claiming one.
What you can check yourself
- Run your home page through Google's free speed test on the mobile setting and read which element it names as the largest. If it is your cookie banner, start there.
- Open your site on a phone on a slow connection and watch what appears last. That is often what the page is waiting for.
- In the test's list of downloads, look for font files in alphabets your page does not use.
- Ask whether every page of your site loads the text of every language or only its own.
- List the other companies' scripts on your site, such as chat, messaging and trackers, and check that none loads before your own content.
What to do next
Start with the largest element in the speed test. If it is the cookie banner, or anything else the opening screen does not show, ask whoever looks after your site to move it so it arrives with the page or after the page is drawn. Do not change DNS records, plugins, payment or email settings yourself. Finding what the opening screen waits for is the kind of tracing our engineers do for clients; the checks above are where it starts.
Questions people ask
Why does Google's speed test say my site is slow when my pages are light and mostly text?
Because the test waits for the largest element on the opening screen, not for the words alone. If a script draws a large element late, such as a cookie banner, the whole page is judged by that slowest arrival. Light text does not help if something else arrives after it.
Can a cookie banner really make my whole page look slow?
Yes, if it is drawn by a script after the rest of the page. On a phone it can be the biggest block of text on the opening screen, so the speed test can treat it as the element to wait for. Putting it inside the page, or drawing it with the opening screen, removes that delay.
My site is in several languages. Should every page load every language?
No. Each page can load only the words and fonts of its own language, and fetch another language only when a visitor switches. That keeps fonts for alphabets nobody opened from arriving in front of the opening screen. If your site is in five languages, that is five sets of files, not one page carrying all of them.
Do chat and messaging scripts slow my site down for visitors who never use them?
They can, if they load before your own content. A script from another company can sit in front of everything and make the page wait for it. Loading it after the page is drawn, when the browser is idle, means visitors who never open the chat are not held by it.
How do I find out what my opening screen is waiting for?
Run your home page through Google's free speed test on the mobile setting and read which element it names as the largest. Then open the site on a phone on a slow connection and watch what appears last. The test's list of downloads also shows the files that arrive first.