THE SHORT ANSWER
Only 5 of 126 independent pool service websites listed on Google Maps in four Florida metros showed their main content within 2.5 seconds, Google’s “good” line, in a Lighthouse phone test on Oct 30, 2026 (4%, 95% CI 2%–9%). The median site needed 8.1 seconds. Photo weight predicted the wait about twice as well as the website platform did.
Key findings
8.1 s
The median site needs 8.1 s before its largest element, usually the top photo, appears. 83% take longer than 4 seconds, Google’s “poor” line, and 40% longer than 10 seconds.
5 of 126
5 of 126 sites show their main content within 2.5 seconds (4%, 95% CI 2%–9%).
79%
Load time is the one test most sites fail: 87% pass the layout-shift check and 91% the blocking-time check, while 79% of sites fail on load time alone.
28% vs. 14%
Image weight accounts for 28% of the spread in load time, the platform for 14% (n = 110). Sites in the lightest quarter for image weight show their main content in a median 5.2 s; the heaviest quarter in 15.1 s.
ρ = 0.03
Fast sites are not better set up to get the call: between load time and the conversion-readiness score from Report No. 01 we find no detectable link (Spearman ρ = 0.03, n = 110).
Method: Google’s own lab test, run three times per site
We ran Lighthouse, the open-source test behind Google’s PageSpeed Insights, on the homepage of every site in the frame. Each site was tested three times in a fresh browser; we report the median run for the performance score and the median of each metric across runs. The settings are the Lighthouse mobile defaults, which PageSpeed Insights also uses [5]: a simulated mid-range Android phone, a slow 4G-class connection and a four-times slower processor. Because the slowdown is simulated rather than imposed, results are comparable across sites and repeatable, but they are lab data, not the experience of real visitors.
| Setting | Value |
|---|---|
| Tool | Lighthouse 12.8.2 (Node), mobile form factor, performance + accessibility + best practices + SEO |
| Browser | Chrome for Testing 153.0.8010.12, headless |
| Throttling | Simulated: 150 ms round trip, ≈1.6 Mbps down / 750 Kbps up, 4× CPU slowdown |
| Screen | 412 × 823 CSS px, device scale 1.75 (Lighthouse default phone) |
| Runs | 3 per site, median; 126 of 126 measured sites had all three runs succeed |
| When, where | Oct 30, 2026, between 20:25 and 22:11 UTC, from the Netherlands |
We use Google’s published thresholds. LCP (Largest Contentful Paint) is when the biggest thing on the first screen appears; “good” is 2.5 seconds or less, “poor” more than 4 seconds [1][2]. CLS measures how much the page jumps while it loads; good is 0.1 or less [1]. INP, Google’s responsiveness metric, can only be measured with real visitors tapping the page, so it is not measured here [1]. In its place we report TBT (Total Blocking Time), the lab metric Google calls a reasonable proxy for INP but not a substitute; good is under 200 ms [3][4]. We do not lean on server response time (TTFB): measured from Europe it is inflated for US-hosted sites.
Platform comes from the Report No. 01 crawl (page signatures); groups under eight sites are pooled. 16 measured sites whose homepage the crawl did not load (robots.txt rules, blocks, errors) have no platform; they count in every Lighthouse figure but are left out of the platform comparison, which uses the other 110. Which factor explains more = share of variance in ranked LCP per factor on those 110 sites (rank-based R²), with 2,000 bootstrap resamples. Conversion link uses Report No. 01’s index without its “Mobile & speed” pillar (which contains LCP, TBT and CLS): reach, trust, answers and price, weights 25/20/20/15.
Sample and coverage
The frame is the same as in Report No. 01: 167 independent pool service businesses with their own website, listed on Google Maps in the Tampa Bay, Orlando, Fort Lauderdale and Fort Myers areas (collected Oct 27, 2026). National chains, franchises and directories are excluded. We tested the web address exactly as it appears in the listing. 126 sites (75%) produced a valid result in all three runs; the other 41 failed every run.
| Outcome (frame: 167 sites) | Sites | Share |
|---|---|---|
| Measured (3 of 3 runs) | 126 | 75% |
| Refused our test (HTTP 403 or bot wall) | 18 | 11% |
| Address does not resolve, 404 or server error | 16 | 10% |
| Security certificate invalid or expired | 3 | 2% |
| Loaded, but nothing painted in the test | 4 | 2% |
The 18 refusals are most likely firewalls that block visitors from outside the US; a Florida homeowner would probably see these sites, so they are missing from our figures, not broken. The 19 sites that do not resolve, return an error or show a certificate warning (11% of the frame) would fail for anyone. The frame leans toward Tampa Bay (79 of 126 measured sites) because of how the listings were collected; Orlando 24, Fort Lauderdale 16, Fort Myers 7. A second frame of sites found through state registries is shown for comparison in section 04.
Layout and code mostly pass; the main picture is late
Share of 126 sites meeting each lab threshold. LCP = largest element on the first screen; FCP = first anything on screen; TBT = lab stand-in for responsiveness.
Source: Ruberio Lighthouse census, Oct 30, 2026; thresholds web.dev [1][2][4].
Number of sites by time until the main content appears (median of 3 runs); blue = within 4 s. Values above 30 s are counted in the last bar.
Source: Ruberio Lighthouse census.
The first thing on screen arrives in a median 3.1 s; the main content follows a median 4.6 s later. For that stretch a visitor looks at a page that has started but has not shown what it is about.
The spread is wide: the middle half of sites lands between 4.8 s and 13.8 s. The Lighthouse performance score, a 0–100 summary of five lab metrics, has a median of 68; 11 sites reach the green band of 90 or more.
| Metric (median of 3 runs) | 25th pct. | Median | 75th pct. | Median, 95% CI |
|---|---|---|---|---|
| Main content appears (LCP) | 4.8 s | 8.1 s | 13.8 s | 7.0–9.7 s |
| First paint (FCP) | 2.0 s | 3.1 s | 4.0 s | 2.7–3.3 s |
| Blocking time (TBT, INP proxy) | 0 ms | 34 ms | 91 ms | 12–43 ms |
| Layout shift (CLS) | 0.000 | 0.001 | 0.029 | 0.000–0.003 |
| Page weight | 1.3 MB | 2.6 MB | 4.7 MB | 2.1–3.1 MB |
| Performance score (0–100) | 60 | 68 | 76 | 64–69 |
| Lab result | Google Maps frame (n = 126) | Registry frame (n = 75) |
|---|---|---|
| Main content (LCP), median | 8.1 s | 6.5 s |
| LCP ≤ 2.5 s | 5 (4%) | 12 (16%) |
| LCP ≤ 4.0 s | 21 (17%) | 21 (28%) |
| CLS ≤ 0.1 | 87% | 92% |
| TBT ≤ 200 ms | 91% | 92% |
| Page weight, median | 2.6 MB | 2.1 MB |
Registry frame: websites of businesses with a Florida pool/spa contractor license or a pool-related company name, found without Google (75 of 82 measured). LCP ≤ 2.5 s, 95% CI 9%–26%. Comparison only; all other figures are the Google Maps frame.
Photo weight tracks the wait more closely than the platform does
If the platform decided speed, an owner could only fix a slow site by rebuilding it. The data point the other way. We asked how much of the spread in load time each factor accounts for on its own. Page weight, and image weight in particular, comes out ahead of the platform a site is built on in the point estimates, though the bootstrap interval for the difference touches zero; adding the platform to image weight explains only 4 points more, while adding image weight to the platform explains 18 points more.
Rank-based R²: share of the variance in ranked LCP explained by each factor alone (n = 110 sites with platform data). Bootstrap 95% intervals (2,000 draws): image weight 15–47%, platform 7–30%; image weight comes out ahead in 95% of 2,000 bootstrap resamples (difference −2 to +29 points; the interval touches zero). Factors overlap and do not add up.
Source: Ruberio Lighthouse census and crawl, Oct 30, 2026.
Median LCP by quarter of image weight (about 32 sites each); line = 2.5 s. Within 4 s: 10, 6, 3, 2 sites; within 2.5 s: 3, 2, 0, 0.
Source: Ruberio Lighthouse census.
Each dot is one site (n = 126); values beyond the axes sit at the edge. Light pages are not automatically fast; heavy pages almost never are.
Source: Ruberio Lighthouse census.
Every platform group misses the line on its typical site
Dot = median LCP; bar = middle half of sites (25th to 75th percentile). Groups with fewer than 8 measured sites are pooled; 16 sites without crawl data are not shown.
Source: Ruberio Lighthouse census; platform detection from the Report No. 01 crawl.
| Platform | n | LCP | LCP 95% CI | Weight | Images | JS | 3rd party | Req. | TBT ms | ≤ 4 s |
|---|---|---|---|---|---|---|---|---|---|---|
| WordPress | 40 | 10.8 s | 7.6–14.1 | 3.6 MB | 1.5 MB | 0.6 MB | 0.4 MB | 72 | 20 | 6/40 |
| Wix | 12 | 7.9 s | 4.9–9.8 | 3.7 MB | 0.3 MB | 1.5 MB | 3.4 MB | 235 | 93 | 1/12 |
| GoDaddy builder | 9 | 6.1 s | 4.4–7.0 | 1.0 MB | 0.2 MB | 0.7 MB | 1.0 MB | 78 | 76 | 1/9 |
| Custom code (Vercel) | 8 | 3.5 s | 2.7–6.0 | 1.5 MB | 0.2 MB | 0.5 MB | 0.3 MB | 34 | 37 | 6/8 |
| Other platforms | 22 | 11.4 s | 5.8–13.9 | 2.7 MB | 0.9 MB | 0.7 MB | 0.9 MB | 61 | 56 | 1/22 |
| Not identified | 19 | 7.7 s | 5.9–13.0 | 2.3 MB | 1.2 MB | 0.4 MB | 1.2 MB | 37 | 3 | 1/19 |
WordPress is the largest group and among the slowest: its pages carry the most image weight (1.5 MB median), and 24 of its 40 sites put the top photo in as a section background (a common page-builder layout); those load in a median 13.3 s. Wix pages carry little image weight (0.3 MB) but the most JavaScript and requests (1.5 MB, 235), and the highest blocking time. GoDaddy builder pages are the lightest (1.0 MB) and remarkably uniform, yet only 1 of 9 gets under 4 s; their median is 6.1 s, so on this builder the page weight an owner controls is already small and most of the bytes come from the builder’s own code. Custom-coded sites hosted on Vercel are the fastest group, but there are only 8, so the interval is wide. “Other platforms”: GoHighLevel 4, custom code on Netlify 4, Duda 3, Squarespace 3, Hostinger builder 2, Drupal 2, Hibu 1, Shopify 1, Google Sites 1, Webflow 1.
Where the weight comes from, and what Lighthouse flags first
Share of all bytes downloaded for the first view, summed per group.
Source: Ruberio Lighthouse census.
Across all sites, images make up 42% of the bytes, JavaScript 14% and fonts 3%. Code and files from other companies (chat widgets, maps, review badges, analytics, the builder’s own servers) account for 49% of all bytes. 43% of sites download more than 1 MB of images for the first view; 23% weigh more than 5 MB in total.
Median LCP (dot) and middle half (bar) by what the largest element is, and by whether Lighthouse’s modern-format check passes.
Source: Ruberio Lighthouse census.
On 78% of sites the main content is a picture. When that picture is placed as a CSS background of a section, the browser finds it only after it has read the styles, and the median wait is 11.8 s; as a regular image element it is 7.5 s, and where the largest element is text, 6.6 s. Sites whose images pass the modern-format check carry a median of 0.3 MB of images, against 1.5 MB for those that fail it.
Share of 126 sites where Lighthouse estimates a saving on the main content (median run). Estimates overlap and do not add up. Median estimate where flagged: images 0.75 s, unused JavaScript 0.85 s, redirect 0.75 s. “Main image found late” = Lighthouse’s LCP request discovery check failed.
Source: Lighthouse audits “Improve image delivery”, “LCP request discovery”, “Reduce unused JavaScript”, “Avoid multiple page redirects”, “Document request latency”, “Render blocking requests”, “Legacy JavaScript”.
Share of sites in each group flagged; n in brackets. Image = image delivery; Late = main image found late; JS = unused JavaScript; Redir. = redirect; Block = render-blocking requests.
Source: Ruberio Lighthouse census.
The redirect is the cheapest fix in this report. We tested the address as it appears in each business’s Google Maps listing.
For 56% of sites that address is not the final one: 59 still list
http:// while the site runs on https, 33 add or drop “www”, and
6 send the visitor to another domain. In the lab test this hop costs a median
0.75 s; browsers that upgrade to https on their own skip part of it.
Server response is flagged on 49 sites, but from Europe that check overstates the delay for US-hosted sites, so we do not rank it.
Fast sites are not better set up to get the call
Each dot is one site (n = 110). Score = Report No. 01 index without its speed pillar.
Source: Ruberio Lighthouse census; Report No. 01 scores (reach, trust, answers, price).
A fast site might be expected to come from an owner who also gets the rest right. We see no sign of that. We measured conversion-readiness features, not calls. Between load time and the four non-speed pillars of Report No. 01 the rank correlation is ρ = 0.03 (95% CI -0.16 to 0.21). The pillar closest to a link is price: sites that show a price load slightly faster (ρ = -0.16 between LCP and the price pillar), which is small and could be chance.
Split at Google’s 4-second line, 10 of the 16 sites under 4 s score above the median on conversion readiness (62%), against 48% of the slower sites (Fisher exact p = 0.42). With a median split on speed the picture is the same (p = 0.70).
| Above-median conversion score | Below median | |
|---|---|---|
| Main content within 4 s | 10 | 6 |
| Slower than 4 s | 45 | 49 |
| Feature (Report No. 01 crawl) | Sites within 4 s | Slower sites |
|---|---|---|
| Tap-to-call link on first screen | 50% (8/16) | 55% (52/94) |
| Quote, contact or book button on first screen | 69% (11/16) | 55% (52/94) |
| Call button that stays on screen | 38% (6/16) | 32% (30/94) |
| Any price shown | 38% (6/16) | 29% (27/94) |
| Reviews or testimonials on site | 75% (12/16) | 55% (52/94) |
| License number shown | 31% (5/16) | 34% (32/94) |
Correlation only. A fast, empty page and a slow page with every answer on it are both common; an owner has to work on both.
Limitations
- Lab data, not visitors. Lighthouse simulates one phone on one connection. Real visitors on fast home Wi-Fi will see faster pages, visitors on weak signal slower ones. Google’s field data (Chrome UX Report) is published only for sites with enough Chrome traffic; we did not use it.
- INP is not measured. TBT is a lab stand-in. A page can pass TBT and still respond slowly to a tap.
- Measured from the Netherlands. Server response times are inflated for US-hosted sites, which is why we do not rank them; the simulation models the network, so the effect on LCP is smaller but not zero. 18 sites refused our test, probably because of non-US blocking; if those are systematically faster or slower, the medians shift.
- One moment, one page. Homepages only, tested on Oct 30, 2026. Sites change, and inner pages can be slower or faster.
- Simulation on a fast machine. The 4× CPU slowdown is applied to a fast desktop processor (benchmark index around 4131), so blocking times may be lower than on PageSpeed Insights’ servers. Load-time ranks are stable across runs (median spread in performance score 3 points). The same fast processor likely makes our LCP values somewhat lower than PageSpeed Insights would report, so the headline share is, if anything, generous.
- The lab model favors the image result. Under simulated throttling (about 1.6 Mbps), bytes on the critical path translate almost linearly into LCP, and the largest element is an image on 78% of sites. Part of the image-weight finding is therefore built into how the test works; with real visitors on faster connections, image weight may matter less.
- Platform detection is automated and leaves 19 crawled sites unidentified, plus 16 measured sites the crawl could not load; groups are small (8 to 40 sites), so per-platform medians carry wide intervals.
- Explained variance is correlation. Image weight and platform overlap (builders shape how images are delivered). We show that photo weight predicts the wait better; we do not prove that shrinking photos alone brings a site under 2.5 s.
- Frame. Google Maps listings in four metros, skewed toward Tampa Bay; not a statewide random sample.
- The comparison frame looks faster. Of 75 registry-found sites tested, 16% meet 2.5 s (95% CI 9%–26%), against 4% in the Maps frame. That frame is statewide and includes pool builders (licensed contractors), so it is not a like-for-like group; but if the gap holds, the share of fast sites in the wider market is higher than our headline figure.
- What would change the conclusion: field data from real Florida visitors showing a different ranking, or a larger sample in which platform explains as much as image weight.
What an owner can do with this
You can check your own site in about fifteen minutes with Google’s PageSpeed Insights, which runs the same test we did [5]. It costs nothing and needs no account.
Worksheet · a 15-minute speed check
| Step | What to write down | Your result | This study |
|---|---|---|---|
| 1. Go to pagespeed.web.dev, enter your address exactly as it is in your Google listing, open the Mobile tab. | Does the address end up somewhere else (http → https, www)? | 56% redirect | |
| 2. Top of the report: “Discover what your real users are experiencing”. | Field data shown, or “no data”? | Small sites often have none | |
| 3. Lab section: Largest Contentful Paint. | LCP in seconds | median 8.1 s; good ≤ 2.5 s | |
| 4. Same section: Total Blocking Time and Cumulative Layout Shift. | TBT ms / CLS | 91% / 87% pass | |
| 5. Diagnostics: “Largest Contentful Paint element”. | Photo, background or text? | 78% a photo | |
| 6. Insights: “Improve image delivery” and “LCP request discovery”. | Flagged? Estimated saving | 65% / 61% flagged | |
| 7. Run it twice more and take the middle LCP. | Middle of 3 runs | We used the median of 3 |
PageSpeed Insights runs the test from Google’s servers, so your numbers will differ somewhat from ours. Google defines its “good” (2.5 s) and “poor” (over 4 s) lines for real-visitor data at the 75th percentile, not for one lab run; use the lab number to compare and to find the cause. If step 5 says photo and step 6 flags image delivery, the photo is the first thing to fix.
The three fixes that matter most, by platform
Chosen from what Lighthouse flagged most often on each platform in this study (see the flags chart in section 07).
| Platform | Start here |
|---|---|
| WordPress |
|
| Wix |
|
| GoDaddy builder |
|
| Any other platform |
|
- Update the web address in your Google Business Profile to the exact final URL your site lands on.
- Make the top photo light: phone-width, WebP or AVIF, as a regular image rather than a background. The lightest quarter of sites in this study load less than 0.24 MB of images in total for the first view, and still have a median of 5.2 s: lighter photos help most, but rarely reach 2.5 s on their own.
- Count your widgets: chat, reviews, maps and social feeds each add other companies’ code. Keep the ones that earn their place.
- Do not stop at speed. In this study fast sites were no more likely to have a tap-to-call link or a price on the first screen; Report No. 01 has that checklist.
Sources
- web.dev, “Web Vitals” (good thresholds at the 75th percentile: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1; Lighthouse cannot measure INP). https://web.dev/articles/vitals (accessed Oct 30, 2026)
- web.dev, “Largest Contentful Paint (LCP)” (good ≤ 2.5 s, poor > 4.0 s). https://web.dev/articles/lcp (accessed Oct 30, 2026)
- web.dev, “Total Blocking Time (TBT)” (“a reasonable proxy metric for INP for the lab but … not a substitute”; good under 200 ms). https://web.dev/articles/tbt (accessed Oct 30, 2026)
- Chrome for Developers, “Total Blocking Time” Lighthouse audit (0–200 ms green on mobile) and “Lighthouse performance scoring” (metric weights, score bands). https://developer.chrome.com/docs/lighthouse/performance/lighthouse-total-blocking-time and https://developer.chrome.com/docs/lighthouse/performance/performance-scoring (accessed Oct 30, 2026)
- Lighthouse documentation, “Network throttling and CPU throttling” (mobile defaults 150 ms, 1.6 Mbps / 750 Kbps, 4× CPU; simulated throttling matches PageSpeed Insights). https://github.com/GoogleChrome/lighthouse/blob/main/docs/throttling.md (accessed Oct 30, 2026)
- Ruberio Research No. 01, Florida Pool Website Conversion Index (Oct 2026): frame, crawl, platform detection and pillar scores.
- Ruberio Lighthouse census (this study): Lighthouse 12.8.2, Chrome for Testing 153.0.8010.12, mobile defaults, 3 runs per site, Oct 30, 2026. Frame: Google Maps listings collected Oct 27, 2026 (web address, metro and category only).
About this research
Who made this
Ruberio is a Dutch design studio: Ruben designs, Sven answers every email. We’re focused on websites for pool service companies and fence contractors in Florida. We ran this study because we build sites that have to load fast on a phone, and we wanted to know where pool service sites actually stand and what slows them down, instead of repeating general claims. The data and scripts are available on request. If you spot an error, email hello@ruberio.com and we’ll correct it and note the change.
If you want to see your own site rebuilt to show its main content fast on a phone, we build a preview for $49 at us.ruberio.com. The $49 comes off the price if you keep it.
Cite this study
Ruberio Research (2026). Only 1 in 25 pool service websites on Google Maps in four Florida metros shows its main content within 2.5 seconds in a phone test (No. 02). Data as of Oct 30, 2026. us.ruberio.com/research/pool-service-website-speed/
Questions
Is this what real visitors see?
No. Lighthouse simulates one mid-range phone on one slow connection in a lab, and we ran it from the Netherlands. Visitors on fast home Wi-Fi will see faster pages, visitors on weak signal slower ones. We did not use Google’s field data (Chrome UX Report), and INP was not measured.
Will smaller photos alone get a site under 2.5 seconds?
The study doesn’t show that. Even the lightest quarter of sites by image weight misses 2.5 s on its typical site (3 of 32 make it). Photo weight predicts the wait better than the platform does, but that is a correlation, not proof that shrinking photos alone is enough.
Which website platform is fastest?
Every platform group misses the line on its median site. Medians run from 3.5 s (Custom code (Vercel), n = 8) to 11.4 s (Other platforms, n = 22). The groups are small, so per-platform medians carry wide intervals.
How can I test my own site?
Google’s PageSpeed Insights runs the same lab test from Google’s servers and needs no account. Open the Mobile tab, write down Largest Contentful Paint, and take the middle of three runs. Your numbers will differ somewhat from ours.
