Publish what the browser actually needs
A static site should contain its intended HTML, CSS, scripts, and assets. A framework project should use the correct build output and supported deployment mode. Shipping development files or the wrong output folder can create a slow or broken experience even when the upload succeeds.
Start with the assets visible on the first screen. Reserve image dimensions, serve appropriately sized files, and avoid loading every interactive demo in a gallery at once. On build.host’s template library, static preview images keep browsing lighter while full demos open on detail pages.
Make loading and interaction deliberate
Use readable text before optional decoration. Load below-the-fold images when needed, avoid unnecessary client-side code, and keep fonts predictable. A video should have a useful poster, a user control, and behavior that respects reduced motion.
An application may also be waiting on its own APIs or third-party services. Separate browser rendering delays from slow API responses. Hosting a frontend does not automatically make an external database query or integration fast.
Measure a real visitor’s experience
Inspect the deployed URL at realistic desktop and mobile sizes. Look for slow first content, layout movement as media arrives, and delayed responses to controls. Compare measurements under the same conditions after a change instead of celebrating a score from a different device or network.
Core Web Vitals and field data help identify real user problems, but no hosting page can promise a score for every app. Your application code, assets, integrations, device, and network all affect the outcome.