Websites that load slowly cost retailers $2.6 billion U.S. dollars in sales each year.
47% of users won’t wait longer than two seconds for a website to load.
40% of users will leave a site if it takes more than 3 seconds to load.
Websites that load slowly cost retailers $2.6 billion in sales each year.
SOURCE: Forbes’ Top Website Statistics for 2024.
How do we make an ecommerce site like this one, with lots of large high resolution images and videos, consistently load so fast?
Just like building an exceptional house, it all comes down to quality engineering and good teamwork. Plenty of people can follow a blueprint, but do they have the experience and skill to build something that will meet the clients needs, exceed their expectations, and provide a home for many years to come?
The Blueprint:
- Media Optimization
- Static versus Dynamic rendering
- Clean output at the Presentation layer
Let’s break this down further, step-by-step:
Media Optimization
Far too often, the optimization of images is left to the website administrator or content manager. We build our websites in such a manner that the images uploaded are automatically optimized based on their display requirements. Our requirement is that the image be large enough and high enough resolution to deliver a quality media file to the largest version needed (large desktop monitors), rather than putting the onus on the content manager. Taking it one step further, we also optimize for each break point, so the image is optimized for mobile, tablet, laptop, or large desktop monitors. All media assets use the latest technology formats for images and videos, WebP and WebM. If needed, we can load WebP, but allow a download of JPG.
Static Versus Dynamic Rendering
The fastest page you can possibly load is a static HTML rendered to a CDN. We look at your requirements and find creative ways to make this the final outcome, whenever possible. If your site has to dynamically render, that means you have a database call and response in the mix. This is your bottleneck.
I could go on, but this is where you begin to separate professional development shops from hobbyists and marketers who rely on code they didn’t write themselves or don’t understand.
Clean Output at the Presentation Layer
Most low code and no code applications having very ‘dirty’ output. Trying to make a fast site built in these environments, with a purchased template, where the front end is built directly into the same application as the back end, can be a frustrating experience.
This is why everyone from WordPress to Shopify is moving to a headless architecture. Headless means the front end is a separate application communicating with the back end via API. The only thing in your front end application is front end code: Javascript, API calls, and HTML Markup. If you look at the source code for a front end built directly into the same application as the back end, you’ll notice a ton of ‘extra’ code. Search engines don’t like this and neither does your browser.