Nina.care: LCP on mobile from 4.9 to 1.7 seconds, and the layout shifts gone
A childcare platform on WordPress that failed all three Core Web Vitals. Fixed in two rounds in 2024.
Nina.care, a WordPress site that grew with every country
I got the call while hiking in the Ardennes: "Hey Arjen, can you help us with a nanny site?" I pictured an elderly couple with a small babysitting service. Back home two days later I found a startup in several countries, and a WordPress site that had grown with it. Not quite the couple I had in mind.
Nina.care matches families with childcare workers. Every new feature and every new country added a bit more to the site, until LCP, INP and CLS all failed.
In December 2024 I was on the guest list for their team’s Christmas drinks.
Two rounds: the first screen, then the clicks
First I added CoreDash. Then we went through the home page. I did the scripts, the chat widget, the hero preload and the lazy loading; their developer did the rest.
Round one · early 2024
fetchpriority.fetchpriority="high". The rest waited until they were needed.async or moved to later. CookieYes went, and so did four of the form stylesheets.Round two · autumn 2024
In January the home page requested all 54 images up front, so on a phone the hero shared the connection with 53 photos nobody had scrolled to yet. Six scripts in the head had to download and run before the browser could build the rest of the page. I moved those scripts out of the way and lazy loaded 46 of the images. In round two the form scripts left the home page, and 25 external scripts became 11.
- 6
- blocking scripts
- 0 of 54
- lazy images
- 26
- external scripts
- 0
- blocking scripts
- 46 of 54
- lazy images
- 25
- external scripts
- 0
- blocking scripts
- 46 of 54
- lazy images
- 11
- external scripts
The hero was a plain img between 53 others, so it started at low priority and only got raised after layout, when the other photos were already downloading. I gave it fetchpriority="high" and a preload in the head, so it starts high and goes first.
<div class="hero-section"><div class="top"><img src="…/homepage-2-lyla-jasmijn.jpg" alt="au pairs reading a book" /></div>…<div class="each-services"><img src="…/babysit-image-homepage.png" alt="babysit product image" /><link fetchpriority="high" rel="preload" href="…/homepage-1.png" as="image">…<div class="hero-section"> <div class="top"> <img data-preload loading="eager" decoding="async" fetchpriority="high" src="…/homepage-1.png" alt="au pair and… </div>… <div class="each-services"> <img decoding="async" loading="lazy" src="…/au-pair-service-img.png" alt="Au pair service" />I like this one because both rounds are in it. In the second half of 2023 LCP on phones ran 3 to 3.8 seconds, with 4.9 in December, the month before I started, and CLS peaked at 0.35 in September. After round one LCP dropped to 2.2 seconds in February. It slipped back to orange in March, April and July, then stayed green from August, down to 1.7 seconds by January 2025. CLS was 0 every month from February 2024. Round two shows in INP: 225 ms from July to September, 175 ms from October.
"Thank you so much for all that you have done for me and the boys! You feel like a part of the company and I like it."
Jasmijn, Nina.care
A form nobody fills in still loads for everyone
Nobody decided to make the site slow. The footer had a newsletter form that hardly anyone filled in, and Gravity Forms loaded its own files for it on every visit. Make that call on purpose. Say a form costs every visitor half a second and one in ten thousand signs up. Do you still want it in the footer, or do you link to a page with the form?
Measure first, then fix
CoreDash was on the site before we changed anything, so each change showed up in their field data.
A WordPress site that fails all three?
I work on a copy of your site and measure the result in your real visitor data.
More results on my clients page.
