Careers Website Speed Report 2026: how fast are 60 large employers' careers websites on mobile?

We tested the careers websites of 60 large employers on mobile settings: the home page and a job page of each, three runs per page, on one day. This report gives the results, the method and what goes with a faster careers website.

• Summary
• How to read this
• Test method
• Results
• Happydance subgroup
• Make it faster
• Limitations
• FAQ

Executive summary

1. We tested the careers websites of 60 large employers across 14 sectors and four regions: the home page and one job page of each, on mobile settings, three runs per page, on 30 October 2026.
2. The median site took 14.2 s to show its largest element on mobile (Largest Contentful Paint, LCP), with the middle half of sites between 10.9 s and 19.5 s. The median Lighthouse mobile performance score was 31 out of 100.
3. 99 of 120 pages scored below 50, which Lighthouse rates as poor. 5 of 120 pages loaded their main content within 4 s, and none within Google's 2.5 s good threshold. Simulated slow 4G is a strict test, so read the results as a comparison between sites rather than as what every candidate sees.
4. Page weight tracked speed: the median page was 4.6 MB with 100 requests, and the lightest quarter of sites by weight had a median score of 47 against 27 to 31 for the rest.
5. Sector and region made less difference than the spread between individual sites: median scores ran from 30 to 34 across five sector groups.
6. Separate subgroup, clearly labelled: 8 Happydance careers websites had a median mobile LCP of 6.8 s and a median performance score of 64, which is 2.1 times faster than the 60-site sample median on LCP.
7. These are lab results from one test location, on a convenience sample of recognisable employers. They are not field data and not a ranking. The method is published so it can be repeated.

Test method

• Tool: Lighthouse 12.8.2 command line with Chrome 156, on a single Linux machine in a data centre. Mobile runs used Lighthouse's default mobile emulation with simulated slow 4G and CPU slowdown. Cold cache.
• Pages: the careers home page and one job page per site, reached from the site's own job listings.
• Runs: three runs per page for 53 sites, run in rounds so that every site was tested at spread-out times. Seven sites that had already been tested the same day with five runs per page reuse those results. 388 runs in total. We report the median of each page's runs.
• Site value: the average of the home page and job page medians, so every site has equal weight. Across sites we report the median, the mean and the quartiles, because a few very slow sites pull the mean up.
• Metrics: performance score, First Contentful Paint, LCP, Speed Index, Total Blocking Time, Cumulative Layout Shift, page weight and request count.
• Machine load: Lighthouse's CPU benchmark index averaged 2566 for the newly tested sites and 2710 for the reused runs, so conditions were similar. Run-to-run spread in LCP was a median of 13% of the median.
• Reliability: one Lighthouse run failed twice in the first pass and was re-run later. No result was excluded or replaced because of its value.

How we chose the sites

We listed 212 large, recognisable employers across sectors and regions before testing. We kept sites whose home page loaded and whose job page we could reach and validate (a working page with an apply action and no block page), which left 107. We removed sites that looked like unconfirmed Happydance builds, balanced the regions by dropping 11 North American technology and banking sites at random, and drew 53 sites at random (25 from North America and 28 from other regions). With seven sites tested earlier the same day, the main sample is 60. It is a convenience sample, not a representative one, and North America is the largest region.

Results: how fast are careers websites on mobile?

Overall results

Across the 60 sites, the median mobile LCP was 14.2 s and the mean 18.3 s. The fastest site averaged 3.7 s and the slowest 109.2 s, so the spread between sites is wide.

Share of pages by load time band

Google rates LCP of 2.5 s or less as good and over 4 s as poor. In this lab test 0 of 120 pages met the good threshold and 5 met 4 s. Lighthouse's slow-4G simulation is stricter than many candidates' connections, so absolute times will read higher than field data for the same pages. The comparison between sites is the useful part.

Home page and job page

Job pages were lighter than home pages at the median but similar on load time and score, so testing only the home page would miss the page where candidates decide to apply.

Sector and region

Sector groups scored between 30 and 34 at the median. With 10 to 14 sites in each group, those gaps are small compared with the spread inside each group, so we do not rank sectors.

Regional medians are shown with the number of sites. Asia-Pacific has five sites and is indicative only. The test machine is in one location, so regional figures say nothing about local network conditions.

What goes with a faster careers website

Lighter pages and fewer requests went with faster loading. The rank correlation between page weight and LCP was 0.65, between request count and LCP 0.58 and between Total Blocking Time and LCP 0.43. This is an association across 60 sites, not proof of cause.

Happydance subgroup (labelled, separate)

Happydance builds careers websites, so we report 8 Happydance careers websites separately, each a confirmed customer or a public case study. These results come from the earlier same-day test with five runs per page on the same method. They are not part of the 60-site figures above. Happydance has an interest in these results.

The subgroup is small and was chosen because the sites are Happydance builds, so it shows what these 8 sites measured, not what every Happydance site will measure.

How to make a careers website faster

1. Test the job page as well as the home page, on mobile settings and more than once.
2. Reduce page weight first: compress and resize images, avoid autoplay video above the fold, and limit font files.
3. Cut third-party scripts and tags that load before the main content.
4. Reduce JavaScript that blocks the main thread, which shows up as Total Blocking Time.
5. Re-test after each change and track the median, not the best run.

Frequently asked questions

Appendix A: sector and region statistics