Fern & Fir: Performance and Checkout Under a Holiday Deadline
Fern & Fir is an online plant shop with 1,800 SKUs and roughly $2.1M in annual revenue. Mobile accounts for 64% of sessions but only 38% of revenue. Product images average 1.4 MB each, and the product-detail page records a Largest Contentful Paint of 6.2 seconds on a throttled 4G connection. Checkout is a four-step flow; analytics show 71% abandonment, with the largest drop at the step where shipping cost first appears. Free shipping applies above $75. The holiday season is eight weeks away and traffic is expected to reach five times the current peak. The lead developer proposes building a separate m.fernandfir.com site for phones and keeping the desktop site as is. The merchandising team wants to add a 20-second autoplay video to every product page.
1. Should the team build a separate mobile subdomain? Recommend an approach and defend it against the alternatives.
Read the worked answer
Recommendation: one responsive site on one URL, with performance work done at the image and template layer.
Why the m. subdomain is the wrong tool here: the actual complaint is speed, not layout. A separate mobile site doubles templates, navigation, and QA work across 1,800 product pages, and every future feature must be built twice - a serious risk with holiday traffic eight weeks out. It also fragments analytics, so the 64%-mobile versus 38%-revenue gap becomes harder to diagnose, not easier.
SEO consequences: a separate URL set means maintaining a device-detection redirect layer, which is a common source of misrouting and crawl errors, and it splits link equity between two versions of each product page. Search engines index the mobile version primarily, so any thin mobile page becomes the canonical experience. Responsive design keeps one URL, one set of signals, and one canonical tag per product.
Alternative considered: dynamic serving from the same CMS would avoid duplicated content but still requires two template families and carries the same maintenance cost, with the added fragility of user-agent detection.
Caveat: responsive design does not automatically make a page fast - the 1.4 MB images would still be 1.4 MB. Treat performance as a separate workstream with its own budget, and if a stopgap is genuinely needed, ship optimized images and a trimmed product template rather than a second site.
2. Set a performance budget and an image strategy that would bring LCP under 2.5 seconds, and explain which single change delivers the most benefit.
Read the worked answer
Budget: LCP under 2.5 s on throttled 4G, total page weight under 1.5 MB, JavaScript under 200 KB compressed, and Cumulative Layout Shift under 0.1. Publish the budget so that template changes get rejected when they blow it.
Image strategy, in order of impact:
- Serve the product image at its display size using srcset and sizes, so a phone downloads a 400px asset rather than a 2000px one. This is the biggest single win, because the current 1.4 MB files are almost certainly being scaled down by CSS after download.
- Compress to roughly 100–150 KB per product image at display dimensions, using AVIF or WebP with a fallback for older browsers.
- Preload the hero or first product image so it is discovered early, and never lazy-load the LCP element.
- Lazy-load only below-the-fold images, and set explicit width and height attributes to prevent layout shift.
- Put images behind a CDN with correct cache headers.
The single biggest change: right-sized responsive images. It targets the largest element on the page and the largest byte source at the same time.
Also relevant: the proposed 20-second autoplay video on every product page directly contradicts this budget and should be refused; it would add megabytes and motion to the exact page type that needs to get faster. Measure with field data plus lab testing on a throttled connection, and re-check after the holiday peak.
3. What changes would you make to reduce the 71% checkout abandonment, and how would you validate them in eight weeks without a full checkout rebuild?
Read the worked answer
Diagnosis first: the biggest drop is at the shipping-cost reveal, which is a trust problem, not a design problem. Users have invested three steps and then meet an unexpected number. The fix is disclosure, not decoration.
Changes, cheap to expensive:
- Show a shipping estimate on the cart page, before checkout begins, including a progress message toward the $75 free-shipping threshold.
- Add a step indicator so users know how many steps remain.
- Offer guest checkout and keep entered data if a user navigates back; re-typing is a common silent killer.
- Use inline, specific validation rather than a single error block after submission.
- Keep the four steps if rebuilding is out of scope, but reduce the fields on the payment step to what is actually required.
Validation in eight weeks: instrument the funnel per step and segment by device, since mobile converts at roughly half its session share. Run a five-to-eight person moderated mobile usability test on the cart and first checkout step to catch confusion the analytics cannot show. Then release the cart-page shipping estimator as a controlled A/B test or a staged rollout to a percentage of traffic, watching abandonment rate, revenue per session, and order error rate as a guardrail. Avoid testing several changes at once, or you will not know which one worked before the peak arrives.