Every visitor a growth hire brings in, from ads, directories or YouTube, lands on a page that scores 13/100 on phones. The cause is specific: the homepage loads one roughly 11 MB JavaScript file holding the entire signed-in app (dashboard, billing, profile, schedules) and a worldwide list of place names, and the largest element on screen is a "Manufacturing Engineer" card in the scrolling job ticker, which also shifts the layout. Real visitors fail Core Web Vitals, with the main content at 5.45s and slow taps at 299 ms. A job seeker on a phone is gone before "Start Applying" appears.
First action
Move the hero and call to action above the ticker and set fixed card sizes.
How to measure it
Field LCP at the 75th percentile
- Now
- –
- Target
- under 2.5s
- By
- 60 days
Steps
Measure
Sign-up rate by device today.
Growth Lead 1 day
Split bundles
Marketing pages separate from the app.
Lead Engineer 3 days
Lazy-load
App code and the place list after sign-up.
Lead Engineer 2 days
Hero first
Headline and "Start Applying" before the ticker.
Lead Engineer 1 day
Fix the ticker
Static or delayed, fixed sizes, labelled as examples.
Lead Engineer 1 day
Budget
Bundle-size limit in the build.
Lead Engineer 1 day
Retest
PageSpeed phone and desktop.
Lead Engineer 1 hour
Compare
Sign-up rate before and after.
Growth Lead 2 weeks
Why it works
Split the marketing pages from the app so the homepage loads only its own code; lazy-load the signed-in app and the location list after sign-up. Render the hero text and "Start Applying" first, and make the ticker a static row (or start it after load) with fixed card sizes so nothing shifts. Label the ticker as example roles. Put a performance budget in the build and recheck PageSpeed and field data.
Speed is the cheapest conversion lift for paid and social traffic, and a fast page makes every growth experiment that follows easier to read.
Ready to use
ChecklistHomepage speed fix list
[ ] Marketing pages built separately from the app [ ] App code and worldwide place list load only after sign-up [ ] Headline and "Start Applying" render first [ ] Ticker static or delayed, fixed card sizes, "example roles" label [ ] Bundle-size budget in the build [ ] PageSpeed phone score 70+, field LCP under 2.5s [ ] Sign-up rate compared by device
Risks and how to handle them
Routing breaks for signed-in users
Keep app routes on the app bundle and test each.
A static ticker feels less alive
Animate it only after the page has loaded.
Evidence
- Google PageSpeedHomepage phone test: performance 13/100 (desktop 37); the largest element is a "Manufacturing Engineer" card in the scrolling job ticker, appearing at 18.8s; layout shift 2.0 (target under 0.1), caused by the ticker; 3.8s of blocking time; 13.6 MB page weight, 3.3 MB of JavaScript (647 KB unused). Real Chrome visitors fail Core Web Vitals: LCP 5.45s and INP 299 ms at the 75th percentile (targets 2.5s and 200 ms).Source
- Your websiteThe homepage loads one JavaScript file of about 11 MB (uncompressed) that holds the whole signed-in app (dashboard, billing plans, profile, schedules, recruiters, memory files, delete-account screens) and a worldwide list of place names for location search, before a visitor has signed up.Source
- Your websiteHomepage: H1 (screen-reader only) "BuildG: Everything you need to get hired"; a scrolling ticker of about 25 job cards with big-brand names (Figma, Stripe, Netflix, Spotify, Apple, Google, OpenAI, NVIDIA and others), each with an "Apply" label and no note that they are examples; stats "1M+ Applications submitted", "96% Success rate", "10× More interview calls", "5/5 User satisfaction" with no definition or source; "Our goal is to reverse the outrageous rise in unemployment"; "Jobs are applied within minutes of getting posted".Source