Why I Stopped Using Lighthouse Scores for Croatian Performance Audits

A few years ago, I stopped chasing "green" Lighthouse scores for Croatian websites. It wasn’t because the metrics are useless—it’s because they were actively misleading my clients and my process. When you audit a site in Zagreb, Split, or Osijek, you are not auditing a site in San Francisco or London, and the tool doesn’t know that.

The Server Location Problem

Lighthouse runs from a Google server, and for most Croatian audits, that server is in Frankfurt or Milan. It’s fast, but it’s not local. The tool measures how quickly a site loads from that distant node, not how quickly it loads for someone sitting in a café on Ilica.

The TTFB Trap

Time to First Byte is one of the most heavily weighted metrics in a Lighthouse performance score. If you host a Croatian business website on a shared server in Zagreb, the TTFB for a local user might be 50ms. But Lighthouse sees 350ms because of the round trip to Frankfurt. I once spent two weeks optimizing a client’s server config just to shave 100ms off that Frankfurt TTFB. The client’s actual users never noticed a difference because they were already getting sub-100ms locally.

I have a client in Rijeka who runs a regional tourism portal. Their Lighthouse score was a 48. We moved their hosting to a local provider with a POP in Zagreb, and the score jumped to 72. Nothing else changed—no code, no images, no caching. The site was performing well for its actual audience the entire time. I was optimizing for a test, not for people.

The Mobile Network Reality

Croatia has excellent 4G and growing 5G coverage, but the user behavior is different. Lighthouse assumes a mobile device with a mid-tier CPU and a simulated 4G connection at 1.6 Mbps downlink. That’s a reasonable baseline for global testing, but it doesn’t match the Croatian mobile reality.

Croatian Users Don't Wait for 3G

Most Croatian mobile users are on high-speed LTE. They don’t experience the same throttling that Lighthouse simulates. I have seen pages score a 35 on Lighthouse mobile but load in under two seconds on a real Croatian 4G network. The tool punished the site for a large hero image that took 400ms to decode on the simulated CPU. A real iPhone or Samsung device in Zagreb decoded it in under 100ms.

Conversely, Lighthouse sometimes gives a pass to sites that use huge JavaScript bundles because the simulated network is slow enough that the bundle loads in the background while the user waits. In Croatia, where real download speeds are often higher, that bundle loads instantly and then locks the main thread for three seconds. Lighthouse says it’s fine. The user says it’s broken.

The Third-Party Problem

Lighthouse aggressively penalizes third-party scripts. Analytics, chat widgets, and marketing pixels all drag down the score. For a small business in Croatia, these tools are often essential. You cannot tell a local bakery in Dubrovnik to remove their Facebook pixel because it drops their performance score by 15 points. They need that pixel to run ads to tourists.

The Real Cost of Blocking

I had a client who ran a WordPress site for a law firm in Zagreb. They had a live chat widget that was critical for client inquiries. Lighthouse gave them a 62 and flagged the chat script as a “render-blocking resource.” We deferred the script to load after interaction. The Lighthouse score jumped to 88. The client’s actual conversion rate dropped by 30% because the chat script was failing to initialize on slower connections. The tool told me to fix something that broke the business.

The Croatian web ecosystem relies heavily on local payment gateways, booking engines, and communication tools. Many of these are not built for maximum performance. They are built for reliability and compliance. Optimizing for Lighthouse often means fighting against your own business requirements.

The Real Metrics That Matter for Croatian Sites

I have replaced Lighthouse as my primary audit tool with a combination of real user monitoring and practical timing tests. I care about three things now.

Real User Monitoring (RUM)

I install a lightweight RUM script on client sites. It collects actual load times from real visitors in Croatia. This gives me data on what a user in Split on a T-Mobile connection actually experiences. That data is worth more than a hundred Lighthouse runs from Frankfurt. The difference is often dramatic. A site that scores 55 on Lighthouse might have a median load time of 1.8 seconds for Croatian users.

Largest Contentful Paint for the Actual Audience

I measure Largest Contentful Paint from the user’s perspective, not the test server’s. I use tools like WebPageTest with a node in Zagreb or use synthetic monitoring from a Croatian cloud provider. The LCP for a local user is often 40% faster than what Lighthouse reports because the server response is faster and the CDN edge is closer.

Interaction to Next Paint on Real Devices

I test interactivity on actual devices available in Croatia. I use a mid-range Xiaomi or a Samsung A series—the phones most people here use. Lighthouse simulates a Moto G4, which is ancient. The difference in JavaScript execution time between a Moto G4 and a Samsung A52 is enormous. A site that feels sluggish on the simulated device feels snappy on a real 2023 phone.

A Practical Approach for Croatian Web Developers

I still run Lighthouse, but I do not treat it as a target. I treat it as a diagnostic tool for specific issues. If the score is low, I look at the specific recommendations, but I don’t chase the number. I ask myself: “Does this fix benefit a real user in Croatia, or does it just make the test happy?”

Run Lighthouse from the Right Location

You can change the location in Chrome DevTools or use a third-party service that lets you set the server location. Run it from a node that is geographically closer to your target audience. The difference in results will shock you. A site hosted on a Croatian server will look completely different when tested from a nearby node versus one in the US.

Set Your Own Baselines

Stop using the global benchmark of 90+ as a success metric. If your site loads in under two seconds for real Croatian users, and the LCP is under 2.5 seconds, you are doing fine. A Lighthouse score of 70 with fast real-world performance is infinitely better than a score of 95 that required removing a critical business feature.

Use the Budget Feature

Chrome DevTools has a performance budget feature. Set your own budgets based on real user data. For example, set a budget of 1.5MB total page weight and under 200KB of JavaScript. These are practical limits that will keep your site fast regardless of what Lighthouse says.

The Forward-Looking Note

The next major update to Lighthouse will likely include more field data and adjust its scoring based on real-world conditions. That is a good step. But until then, stop optimizing for a synthetic test that runs from a server 1,000 kilometers away. Start optimizing for the person sitting at a desk in Zagreb or on a ferry in Split. Their experience is the only score that matters. Build for them, not for the tool.