What a week of speed work did
I did not notice that Flickloot was slow. That has to come first, because the rest of this is about a number, 18 seconds to first paint on a phone, and I never waited 18 seconds for anything. It was not slower on my phone. It was not slower on my desktop. I opened the casino the way I open it every day and it opened.
The number arrived sideways. On 14 September I was working on the shops, the other websites in the portfolio, and those had speed problems I could see. So I said check all of them. That was the whole order, a general pass over every site we run, nothing aimed at the casino, and the casino is what it caught: a technical check which said the website is slow. Lighthouse on its mobile setting put first paint on play.flickloot.com at 18.2 seconds, the mobile score at 25 out of 100 and the page at just over three megabytes before the first game showed. The order then sat two days before anyone acted on it.
Why I could not feel it stops being strange once you know what the instrument does. The mobile preset throttles the network and the processor down to a mid-range phone on a slow connection. The test imitates a phone I do not own on a connection I do not have.
What 18 seconds is
Not a wait. Nobody has sat through 18 seconds of Flickloot, because nobody sits through 18 seconds of any website. It was clear by the fourth second that the website was not working, and that is how a person reads a blank screen: they leave. I’m pretty sure someone would have quit in the fourth second. So the headline figure describes a wait that never happens. What happens instead is a visitor who never arrives, and there is no dashboard for those.
The cause was plain once somebody looked. The casino was shipping its own compiler. The games are written in JSX, and every visit sent 2.8 megabytes of Babel so the phone could translate that into JavaScript on its own processor, before a single card was dealt. A laptop does that fast enough that nothing seems wrong. A mid-range phone sits there, and I was never on the mid-range phone.
What the week did
Wednesday 16 September, morning: compress everything on the wire, cache the vendor files for a year, and load the compiler after the page instead of before it. Babel went from 2.8 megabytes to 740 kilobytes and the static shell painted first. First paint dropped from 18.2 seconds to 2.1. Mobile score 25 to 43. Desktop 29 to 39.
Same day, evening: stop shipping the compiler at all. The games are now compiled before deployment, and a new gate checks that the deployable file is exactly the source compiled, so nobody ships a stale build by hand. Page weight went from 3,229 kilobytes to 373. Largest paint on a phone from 22.7 seconds at the start of the day to 6.1 at the end. Desktop score 39 to 77.
Mobile score: 43 to 42. Same number, inside the noise. What is left on a phone is React drawing the lobby, about 2.6 seconds of blocked processor, and no amount of compression touches that. It needs a smaller first render, which is a different job and not yet written.
The marketing site got compression and a page cache the same day: time to first byte from 1.2 seconds to 0.29, mobile score from 64 to 72. It never had the compiler problem. It had a WordPress problem, which is cheaper.
So the table reads desktop 29 to 77, mobile 25 to 42. Desktop took the big win and desktop is the number I care least about. I am pretty sure more people will access the website from the mobile, so mobile is the one I look at, and 42 is still red.
I was not chasing a score and I am still not. I’m focusing on having a good website which is pleasant, which people would like to play on. Speed comes into question naturally when it is the time for it, and this was the time for it. Google’s own test would not run for us this week, a daily quota, three attempts over two hours, so we built our own timer. It reads 4.7 seconds to the largest paint on a throttled phone and 1.5 on a desktop, and it says twice in its own output that it is not a Lighthouse score. The before-and-after table is due on Saturday.
The part I keep coming back to
None of this needed a specialist. With all these AIs that we are paying every day, why would you pay someone to check your website speed? You sort out your own problem, and you sort it a lot better than a lot of specialists who take a lot of money for it. The check found a defect I could not feel from either of my own devices, and the desktop half was fixed by the evening.
Mine sorted most of it in a week. The mobile number is still red, and it is the only one I look at.