Define the need first
A portfolio and a real-time workspace have different technical needs. A mostly static page may not need a large application rebuilt on every visitor’s device. The first decision is what the page must do, not which library to use.
Content, navigation and basic links should work with HTML wherever possible. JavaScript should support an interaction rather than become a prerequisite for seeing the entire page.
Set an image budget
A large hero image can define a page’s personality. Its dimensions, compression and device-specific versions still need planning. Provide an appropriate image size instead of sending a huge desktop asset to a small screen.
Avoid delaying the primary image in the first viewport, and defer images farther down the page until needed. Declaring image width and height also helps prevent content from shifting as assets arrive.
Fonts are files too
Every font family and weight adds a download cost. One display family and one text family are a useful starting point for many projects. Load only the weights you use, check language coverage and provide a readable system fallback.
Self-hosting can reduce dependence on external services, but licensing and file size still matter. Choosing typography only from a screenshot misses its loading behavior.
Measure, change, measure again
A single score cannot describe performance. Initial rendering, interaction delay and layout stability point to different issues. Establish a baseline under consistent conditions, make one change and compare the results.
Do not test only on a powerful computer. Narrow screens, slow connections and less processing power reveal problems real visitors may encounter. The goal is an experience that meets the need quickly and clearly, not merely the smallest file.