Load Time
A website's load time refers to the time span from the first network request to the moment the page is fully loaded and interactive. It is not a single value but a bundle of metrics – above all Largest Contentful Paint , First Contentful Paint , and Time to Interactive (TTI). Poor load time costs users, rankings, and revenue simultaneously.
Why is load time business-critical?
Studies by Google and Amazon show: every additional second of load time reduces the conversion rate by 7–20%. Users on mobile devices bounce at over 50% when waiting more than 3 seconds. Google uses PageSpeed as a direct ranking factor in the Core Web Vitals update – slow pages lose organic visibility. For SMEs, this means: a poorly performing website loses potential customers before they have read a single line of content.
How is load time measured technically?
The most important metrics are Largest Contentful Paint (time to the largest visible element, target: under 2.5 seconds), First Contentful Paint (first rendered element, target: under 1.8 seconds), and Time to Interactive (full interactivity, target: under 3.8 seconds). Lab data from Lighthouse or PageSpeed Insights simulates conditions, while Field Data (CrUX) reflects real user behavior. Both data sources provide different perspectives and should be considered together.
Load time in practice: what is good?
An LCP under 2.5 seconds is considered good, between 2.5 and 4 seconds needs improvement, and above that is poor. Concrete levers: image compression with WebP/AVIF, Lazy Loading for below-the-fold content, Caching at server and browser level, and eliminating render-blocking resources. A statically prerendered HTML response (SSG) fundamentally delivers better TTFB than purely client-side applications.
Common mistakes in load time optimization
The most widespread mistake: optimizing exclusively in the lab (Lighthouse) while ignoring mobile field data. A Lighthouse score of 100 in the desktop lab can still mean a poor user experience on real mobile devices. Further mistakes: treating a single measurement as representative instead of the median over time, loading CSS and JavaScript for all pages wholesale instead of code-split, and embedding hero images without explicit size attributes, which causes Cumulative Layout Shift .
Practical perspective
Load time is not an afterthought for us but an architectural decision: Angular Static Site Generation delivers fully rendered HTML without server wait time, Critical CSS is inlined during the build, and images use WebP with responsive srcset attributes. Per route, the JavaScript bundle stays under 50 KB thanks to code splitting. On btech-solutions.eu, this yields an LCP under 1.5 seconds and an FCP under 1.0 second – mobile and desktop alike.