Generally, 1-2 second loading speeds are pretty good, however these are two different concepts on desktop versus mobile.
Mobile websites have to load much faster, to compensate for the poor quality of wifi networks and mobile data. People still browse websites in the elevator, garage, or subway, where the coverage won’t be the best. While internet packages are getting progressively faster, a lot more people still don’t have the most reliable solution in their pockets. We account for the slower internet by testing loading speeds in a so-called “throttle” state. This simulates how an average visitor on-the-go may experience our websites. Long story short, even if the network connection is bad, our website still loads fast enough to not upset visitors!
Fun fact: Hungary was among the top 10 European countries for the fastest mobile network load speeds. Who knew?
As a rule of thumb, you should focus on the “above the fold” part of your website, to make sure the visitors can interact with it immediately. Above the fold is the part of the website you see upon loading, without scrolling anywhere. This part usually contains a few pictures, your header text, navigation, and other clickable elements. The rest of your website is what’s called below the fold, which has more time to load.
What is awesome about page speeds: you don’t have to take our word for it.
We use two tools – which are super easy to use – and you can see any website’s speeds. The first tool is the web.dev tool, which you can use by copying and pasting the URL of your website in, and clicking on “run audit”. If you want more detailed results, or a slightly different solution, you can also try the PageSpeed Insights. Here you can switch between mobile and desktop views, as well as get a summary of the 6 scored values. You can also use this tool to compare your own website to your competitors’, which can yield interesting results.
Well structured code, and appropriately sized, optimized images can make a huge difference for loading speeds. It’s also important to choose a good host – with a server infrastructure and environment that can guarantee our website is running smoothly.
It’s good practice to optimize images both by maximum pixel, and maximum file size. Pictures can be your biggest enemy when it comes to speed. You can avoid this by sizing them according to their size on the website, and/or putting them through some sort of compression. This can make 3-4 MB images shrink to a few hundred kilobytes. Another good practice is we “lazy load” pictures below the fold, which means they show after a slight delay, and they are visible by the time the visitor gets to them, but they don’t slow down the initial load time.
Content Delivery Networks (CDN-s) can also play a huge role in speed. CDN-s take every asset from your website, such as pictures, CSS and JavaScript files, and distribute them across the world. This guarantees that people can access the assets stored closest to them. This is especially important if you have visitors from all over the globe.
For example: if you’re anywhere in Hungary, you will receive the content from the Berlin network most likely. However, from Japan, you would not access the Budapest network, instead the Tokyo network will provide you with the data.
You also need some sort of caching solution. Caching means that upon a visitor returning on your website, they do not have to load it from the very beginning, instead they will receive the latest saved version of it. You can think of this as an interactive brochure basically. Loading the cached website takes a lot less resources and time, which means your visitor gets to interact with it much sooner, and everybody wins. You can use providers such as Cloudflare for caching.
Plugin usage can slow down a website too, but if you use a caching solution, and plugins that are well setup, and reliable this issue disappears as well. We at Proof have plenty of experience with providing the most efficient solutions, whether it’s plugins or otherwise.
A few years ago, there was a trend where web developer agencies advertised “static websites” as the saving grace of businesses, because they load fast. So how do static websites compare to our cached websites?
Static websites are basically custom sites which are developed and generated once, and are done. They load fast because there are no requests to be made, as they can’t be changed after their initial finish. There can also be no dynamic content displayed, like monitoring and refreshing exchange rates, for example.
Technically, our WordPress solutions also create static websites, but there is an architecture behind it to support any edits. Here you never have to worry about outdated information or pictures, because you can change them any time.
As we established, browsers cache information (such as images, JavaScript files, stylesheets and more) so returning visitors have an easier time loading your page. This saves you the time of hundreds, and thousands of requests for each small detail of the website. This also means a website can handle 10 thousand visitors just fine without a large server behind it, because the website never actually has to make a request to the server, only to the cached version.
So what happens if your content changes? Worry not, caching is smart, so if set up well, the cache will automatically save the most recent, updated content. However, if you’re paranoid, you can purge the cache manually too, forcing it to pick up the latest version.
If you empty the cache, everything will load for you as if you had never visited that page before.
Builders can be awesome solutions that enable countless users to create websites. This is especially useful to test the waters with a new venture, or if there are no resources available for them to hire a freelancer or an agency.
People can make lots of different websites with the help of builders, but at the end of the day you’re always forced into a pre-made structure. It’s quite difficult to make a clean, UX-focused platform with the help of builders.
They are also behemoths of code, because everything is written generally for a hundred different purposes, and people only end up using one or two of them. In our example, making something look good is about 100 lines of CSS, in your average builder it is 2500 because it supports 25 different layouts and 10 integrations you will never use.
If you’re looking for a fast and beautiful web solution, or simply want to know more, get in touch with us.