SWING homepage performance
I examined how rendering and downloaded assets affected the initial page load.
Work context
The SWING homepage was slow to show its first screen and transferred a large amount of data initially. Its rendering structure, media, fonts, and external content all contributed to initial load time.
While migrating the Next.js structure, I reduced initial costs by resource type. I compared before and after results with local mobile Lighthouse runs under the same conditions, then addressed a first-image-conversion delay observed in production.
The work aimed to improve initial rendering while preserving the customer-facing design. I compared font transfer cost alongside the original weight styling instead of choosing by score alone.
Decisions and implementation
- 01
Initial display path
The previous page combined a wait for client rendering with large initial resources.
I moved from Pages Router to a server-first App Router structure and prerendered the Korean and English routes.
I checked Korean and English routes and responsive layouts in a local production build.
- 02
Initial resource loading
The hero GIF, external content, and multiple font files increased initial transfer size.
I replaced the GIF with an MP4 and WebP poster and loaded external content as it approached the viewport.
- 03
Font transfer and design weights
Using only a regular font sometimes scored better, but could lose the original design’s weight distinctions.
After comparing options, I chose a variable WOFF2 subset that preserved weight styling while reducing requests.
In a separate local font comparison, requests fell from 4 to 1.
- 04
Build-time image conversion
After the initial improvement, a delay appeared when images were converted for the first time in production.
Instead of converting on request, I generated 106 responsive WebP assets from 34 originals at build time and served them as static assets.
In follow-up local checks, I inspected image conversion requests and broken images across Korean and English routes.
Local production build · Lighthouse mobile simulation
Medians of 3 runs before / 5 after · Measured in July 2026
Implementation details
I examined rendering, browser resources, and per-request server work separately. I prepared what the first screen needed early, leaving interaction and external content where they were needed.
- 01Build
Generate pages by language and image variants
- 02First response
Serve prepared HTML and video poster
- 03Interaction
Load client code for menu and carousel
- 04Scroll
Load external content near the viewport
Client component boundary
I generated language routes with generateStaticParams and read translation dictionaries on the server. Pages and layouts used Server Components; parts requiring state and events, such as the menu, became separate Client Components.
Iframe loading near the viewport
IntersectionObserver created the iframe when the news section came within 300px of the viewport, then stopped observing. Space of the same height was reserved before loading. A fallback load path kept the content available when the browser did not support the observation API.
Build-time image conversion
At build time, sharp corrected rotation, resized images to target widths, and generated WebP files. The custom next/image loader chose a variant at least as wide as requested and returned a static file URL. Unregistered images used their original path, and generated files were separated by versioned paths.
Font weights and request priority
One variable WOFF2 subset covered the weights in use and was connected through next/font/local. To account for the hero poster’s initial priority, I disabled font preload and used display: swap. I checked the effect of this choice in a separate font comparison.
Verification and results
- Before and after under the same conditions
For a local production build with Lighthouse mobile simulation, I compared the medians of 3 runs before and 5 after. Performance rose from 54 to 95 points, and initial transfer fell from 19.805 to 0.488 MB.
- Font choice
In a separate font comparison measured 5 times under the same local conditions, requests fell from 4 and 186.9 KB to 1 and 109.6 KB. This was separate from the full-homepage measurement.
- Image follow-up
After moving image generation to build time, local production checks recorded 0 image conversion requests and 0 broken images across 10 Korean and English routes.
Recorded a Performance score change from 54 to 95 and initial transfer size from 19.805 to 0.488 MB (a 97.5% reduction).
These are local simulation results, not real-user performance or conversion metrics. Several changes were applied together.
Reflections
I followed local measurements with observations from production, moved the newly identified image cost to build time, and checked the result again.
Based on career records and implementation evidence. Diagrams reconstruct the work for explanation; private product screens and data are excluded.