Fast on desktop, slow on phones because of heavy video
On desktop, nbbj.com performs well: most pages show their main content in about two seconds. On phones the picture is very different. A typical page takes around 10 seconds to show its main content on a mobile connection, and only 3 of the 21 page types meet Google's 2.5-second target.
The underlying hosting is fast. The slowdown comes from what the pages ask visitors to download and from the order in which they load it.
- 73 MB
Video is the main cause. The homepage downloads all six of its slideshow videos as soon as it opens. That's nearly 70 times the size of a simple text page. Several other pages carry a single background video of 6 to 23 MB.
- 0.75–5 s
The cookie banner holds up every page. Nothing appears on screen until the banner has loaded. When its service is slow, it adds several seconds.
- 1.3–2.5 s
Key headlines and images fade in late. On several pages, entrance animations hide the main content until loading has finished.
- 54 of 726
The sitemap given to Google is out of date. It lists broken pages and internal tools, and every page has the same "last updated" date: May 2023.
- 80–93
Accessibility is close to good. Most issues come from a few shared components, including the language switcher in the header, so each fix improves every page.
In short. None of this requires a redesign. The fixes are technical and contained, and most are shared across pages, so each one improves many pages at once. Fixing how videos load, unblocking the cookie banner and showing headlines straight away would address most of the mobile slowdown.
The fixes also don't depend on the choice of content management system. They can be applied to the current Prismic site, and any rebuild should treat them as requirements from day one.
Scores at a glance
Lighthouse scores each page out of 100 in four areas: 90 and above is good, 50 to 89 needs work and below 50 is poor. The figures below are averages across all 21 page types.
Speed
How quickly pages load and become usable.
Accessibility
How well the site works for people using assistive technology.
Best practices
Security and modern web standards. Perfect on every page.
Search (SEO)
Basic signals search engines use to read the site.
Main content shown, phone
Google's target is 2.5 seconds or less. 3 of 21 page types meet it.
Main content shown, desktop
18 of 21 page types meet the 2.5-second target.
Sitemap addresses
A further 34 redirect to a different page. The remaining 638 work as listed.
What's working
Very fast hosting
The server responds in under 30 milliseconds on every page. The foundations are sound, so the gains will come from what each page downloads.
Perfect best-practice scores
All 42 tests scored 100 for security and web standards.
Responsive once loaded
Pages respond to taps and clicks without noticeable lag once they've loaded.
Stable layouts
Content barely moves while pages load. The careers and internships pages show a small shift on desktop. Every other page is steady.
Recommendations
Ordered by expected impact. High has the biggest effect on phone speed, Medium is a clear improvement, and Low is housekeeping.
| # | Recommendation | Priority | Pages affected |
|---|---|---|---|
| 1 | Load videos only when needed, and compress them | High | Home, work & ideas, expertise, careers, projects |
| 2 | Stop the cookie banner from holding up the page | High | Every page |
| 3 | Show headlines and lead images straight away | High | 6 page types |
| 4 | Send phones smaller images | Medium | Most page types |
| 5 | Trim fonts, page data and unused code | Medium | Every page |
| 6 | Fix accessibility issues in shared components | Medium | Every page |
| 7 | Clean up the sitemap and links for search engines | Medium | Sitemap, 5 page types |
| 8 | Review third-party scripts and consent | Low | Every page |
1. Load videos only when needed, and compress them
HighAffects the homepage, the work & ideas listing, expertise, careers, internships and project pages.
What's happening
The homepage slideshow starts downloading all six videos as soon as the page opens, including the ones visitors haven't reached yet. That's 73 MB in total.
Elsewhere, single background videos are much heavier than they need to be: 23 MB on the work & ideas listing, 7 to 9 MB on expertise pages and around 6.5 MB on careers and internships.
Why it matters
On a phone connection all that video competes with the rest of the page, so the homepage takes over 11 seconds to show its main content. It also uses up visitors' mobile data, and some visitors on slower connections will leave before the page appears.
What we'd do
Load only the video on screen, and fetch the next one just before it appears. Re-encode background loops, which are currently close to master quality, to around 1–2 MB each, and send a smaller version to phones. Show a still image until the video is ready.
2. Stop the cookie banner from holding up the page
HighAffects every page.
What's happening
The cookie consent banner (CookieYes) and the font files have to finish loading before anything appears on screen.
Why it matters
Visitors look at a blank screen for longer. Lighthouse estimates at least 0.75 seconds lost on every phone visit, and up to 5 seconds when the banner's service is slow.
That happened during our test of the terms & conditions page, which scored 58. The privacy policy has the same layout and scored 98.
What we'd do
Load the banner alongside the page instead of before it, while still holding back tracking until the visitor consents. Bundle the fonts with the rest of the site's styles.
3. Show headlines and lead images straight away
HighAffects the news listing, the work & ideas listing, expertise, careers and internships pages.
What's happening
On these pages the main headline or lead image starts invisible and fades in once the page has finished loading.
Why it matters
Until the content is visible, browsers and Google treat the page as not yet shown. This adds 1.3 to 2.5 seconds, even on a fast connection.
What we'd do
Show the content at the top of the page immediately, and keep the entrance animations for content further down. The design looks the same once the page has loaded.
4. Send phones smaller images
MediumAffects most page types. The biggest savings are on image-led pages.
What's happening
Phones receive the same large images as desktop screens, much bigger than they can display. The page's main image also isn't marked as the first thing to load, so the browser finds it late.
Why it matters
Some phone pages download far more image data than they need: about 3.3 MB extra on expertise service pages, 2.3 MB on project pages and 1.5 to 1.9 MB on careers, internships, diversity & inclusion and market sector pages.
What we'd do
Tell the browser what size each image is shown at so it picks the right version, and load each page's main image first. Image quality stays the same.
5. Trim fonts, page data and unused code
MediumAffects every page.
What's happening
Each page loads five font files (435 KB) and ships around 200 KB of code it doesn't use. Pages also carry more content data than they display: about 300 KB on the homepage alone.
Why it matters
Each item is small, but together they add download and processing time to every page, especially on phones.
What we'd do
Trim the fonts to the characters the site uses, pass each page only the content it shows, and remove unused code.
6. Fix accessibility issues in shared components
MediumAccessibility scores range from 80 to 93. Almost every issue comes from a component shared across many pages, so each fix improves the whole site. The first two are in the header and affect every page.
| Issue | Where | What it means for visitors |
|---|---|---|
| Language switcher link has no label | Header, every page | Screen readers announce an unnamed link. |
| Current-language button marked up incorrectly | Header, every page | Assistive technology receives conflicting information. |
| Headings out of order | 14 page types | Harder to navigate a page by its headings. |
| Images missing descriptions | Slideshows on 5 page types | Image content isn't described to people who can't see it. This also affects image search. |
| Accordion buttons without names | Careers, internships, diversity & inclusion | Screen readers can't say what the button opens. |
| Lists built incorrectly | News listing, applied research | Screen readers can't announce how many items a list has. |
| Slider dots too small | Home, expertise | Hard to tap accurately on a phone. |
| Low-contrast Send button | Contact form, before it's filled in | Hard to read for people with low vision. |
Automated tools only catch part of what affects real users. Keyboard navigation, screen-reader flow and video captions also need a manual review. See Next steps.
7. Clean up the sitemap and links for search engines
MediumThe sitemap is the list of pages the site gives to Google, and it's out of date. A few pages also contain links that search engines can't follow, which is why their SEO score drops to 85.
What's happening
54 of the 726 sitemap addresses show "page not found". Most are profiles of people who have left (35) and empty filter pages (15). The rest are two closed offices, an old contact page and the search page.
23 removed projects redirect elsewhere, 20 of them to the homepage. Internal pages such as the style guide and a bookmarklet tool are listed too, and every page's "last updated" date is 10 May 2023.
Why it matters
Search engines waste time on broken and internal pages, may treat the redirects to the homepage as errors, and can't tell which pages have changed recently.
On the Our story, People, Careers and Internships pages, some links have no destination that search engines can follow. The homepage and Our story also use vague link text such as "Learn more".
What we'd do
Generate the sitemap automatically from published content, with real update dates, and leave out internal and unpublished pages. Point removed projects to a related project or sector page instead of the homepage. Make every link a real link, with text that says where it leads.
8. Review third-party scripts and consent
LowEvery page loads five outside services: Google Tag Manager, Microsoft Clarity, CookieYes, Leadfeeder and a script from an analytics domain we couldn't identify (insightful-datavisionary.com). Their effect on speed is small next to the video weight.
More importantly, in our tests Clarity and Leadfeeder loaded and sent data before any consent was given. That may be intentional, for example under rules for US visitors, but it's worth confirming with whoever owns privacy compliance. We'd also check that each service is still in use, starting with the unidentified one.
Suggested order of work
First
Quick, site-wide fixes
Unblock the cookie banner (2), show headlines straight away (3), and fix the header accessibility issues and the sitemap (6, 7). These are small changes that each improve every page.
Then
Media
Change how videos load and re-encode them (1), then resize images for phones (4). This is where the largest phone gains are, and it needs input from whoever produces the video content.
Alongside
Measure and confirm
Re-test the key pages several times after each round of changes. Check real-visitor speed data in Google Search Console. Have a person review accessibility by hand, and confirm the third-party and consent setup (5, 8).
A realistic goal is for most page types to show their main content within 2.5 seconds on a phone, and to score 95 or above for accessibility and SEO.
Results by page
Lighthouse scores, plus the time until the main content appears on a phone and on desktop. Only the ideas article, privacy policy and compliance pages meet the 2.5-second target on a phone. Each page type links to the page we tested.
| Page type | Speed, phone | Time, phone | Speed, desktop | Time, desktop | Accessibility | SEO | Download size |
|---|---|---|---|---|---|---|---|
| Home | 63 | 11.6 s | 84 | 2.4 s | 87 | 92 | 74.5 MB |
| News listing | 60 | 10.3 s | 88 | 2.1 s | 85 | 100 | 1.5 MB |
| News article | 76 | 5.9 s | 89 | 2.1 s | 93 | 100 | 1.2 MB |
| Project page | 71 | 10.9 s | 87 | 2.2 s | 86 | 92 | 7.7 MB |
| Ideas article | 97 | 2.2 s | 87 | 2.3 s | 91 | 100 | 1.3 MB |
| Person profile | 59 | 11.2 s | 88 | 2.2 s | 92 | 100 | 1.4 MB |
| Work & ideas listing | 57 | 10.8 s | 94 | 1.5 s | 92 | 100 | 25.7 MB |
| Expertise, service | 56 | 21.8 s | 83 | 2.4 s | 81 | 92 | 13.4 MB |
| Expertise, market sector | 72 | 7.5 s | 89 | 1.6 s | 87 | 100 | 10.0 MB |
| Office location | 61 | 12.1 s | 84 | 2.6 s | 92 | 100 | 1.6 MB |
| Contact | 77 | 5.9 s | 97 | 1.3 s | 88 | 100 | 1.1 MB |
| Our story | 73 | 10.5 s | 87 | 2.1 s | 91 | 85 | 2.4 MB |
| Our story, people | 71 | 12.0 s | 84 | 2.7 s | 91 | 92 | 1.7 MB |
| Diversity & inclusion | 73 | 15.7 s | 80 | 3.4 s | 80 | 92 | 3.1 MB |
| Careers | 55 | 15.5 s | 93 | 0.9 s | 85 | 85 | 9.9 MB |
| Internships | 56 | 15.0 s | 93 | 1.0 s | 85 | 85 | 9.6 MB |
| Open positions | 76 | 6.3 s | 96 | 1.4 s | 92 | 100 | 1.4 MB |
| Applied research | 64 | 10.2 s | 89 | 2.1 s | 83 | 100 | 1.3 MB |
| Privacy policy | 98 | 2.0 s | 100 | 0.6 s | 90 | 100 | 1.1 MB |
| Terms & conditions* | 58 | 9.5 s | 100 | 0.6 s | 90 | 100 | 1.1 MB |
| Compliance | 98 | 2.0 s | 100 | 0.6 s | 90 | 100 | 1.1 MB |
Accessibility, SEO and download size are from the phone test. Sizes above 5 MB are in bold; a simple text page is about 1.1 MB. *The terms & conditions phone result was slowed by the cookie banner during our test (see recommendation 2). Pages with the same layout scored 98.
How we tested
What we tested
We grouped the sitemap's 726 addresses by page type and tested one live page of each of the 21 types, on phone and desktop: 42 tests in total. We also checked that every sitemap address loads.
Test conditions
Google Lighthouse 13.5 simulates a mid-range phone on a slow 4G connection, and a standard desktop. These are lab results, not real-visitor data, so read them as patterns rather than exact figures. Real visitors on fast connections will usually see quicker times.
Run-to-run variation
Each page was tested once per device, and phone results can vary between runs, particularly when an outside service like the cookie banner is slow. Before and after making changes, we'd test the key pages several times and compare the median results.
Terms used
"Main content shown" is what Google calls Largest Contentful Paint (LCP), one of the Core Web Vitals it uses in search ranking. Google's target is 2.5 seconds or less. "Typical page" means the median across the 21 page types.