Web page optimization, also known as website optimization, is the process of making changes to improve a website's performance in terms of speed, user experience, search engine ranking, and conversion rates. It involves various techniques aimed at enhancing different aspects of a web page to ensure it loads quickly, is user-friendly, and achieves its intended goals efficiently. Here are some key areas of web page optimization:
Overall, web page optimization is an ongoing process that requires attention to detail, continuous monitoring, and adaptation to changing technology and user preferences. By optimizing various aspects of a website, businesses can improve their online presence, attract more visitors, and achieve their goals more effectively.
Less code, loaded better, helps everyone
Google has to fetch dozens and sometimes hundreds of various resources all across your website and these can add up to many megabytes of data. Google's dream is for websites to load near-instantaneously and we've seen them push for that quest through projects such as AMP, but instantaneous load isn't just great for SEO, it's great for the user too so it's incredibly important that you invest the necessary time and energy to optimise the efficiency of your site. Now, speed optimisation is a robust topic.
We could easily spend a few hours detailing all of the approaches, but we're not going to get into that level of detail today. Instead, I'm going to point you to the right resources and give you the high-level overview of how to go about getting your site loading faster. Now, I often get asked, "How am I doing in relation to the rest of the web?" And to give you a sense of how you stack up, you can look at benchmarks from HTTP Archive. I'm here at httparchive.org/reports/state-of-the-web and here they've got some great statistics on trends from around the web.
We can see the average bytes per page by content type, the average individual response size, so if you're trying to decide if that JPEG or PNG are too big, you can look at what the average size is across the web. You can even see the HTML document size so what should you expect, the number of DOM elements per page and so on. This is a great resource. This information goes on and on. So, if you're getting very deep into your optimisation, here's a good place to come and see how you stack up with the rest of the web.
Now, all that said, you want to prioritise your effort towards your mobile experience. And here's where it gets crazy. Research has shown that any delay longer than a second will cause the user to interrupt their flow of thought which creates a poor experience and subsequently a poor SEO experience. Your goal is to keep the user engaged and deliver your site as fast as possible regardless of device or type of network. Now, the one-second time budget is a bit overstated.
You fortunately aren't trying to render the entire page in one second. Your aim is to deliver all the above-the-fold content in under one second so the user can start interacting with the page right away. You can then continue to build the rest of the page progressively with little negative impact to your user or SEO. But this still poses a significant challenge. Mobile devices aren't always on WiFi and they may be accessing your site over 2G, 3G, or 4G networks.
So, Google uses the following example within their developer documentation. You have a thousand milliseconds to deliver the above-the-fold content, so your first issue that you need to contend with is network latency. 200 to 300 milliseconds will be used up for 3G networks just to pass the information through the system and 50 to 100 milliseconds round-trip for the 4G networks. 3G is the dominant network type around the world. And while 4G is growing significantly, you should still expect that the majority of users will be accessing your page on a 3G network.
For this reason, we have to assume that each network request will take on average 200 milliseconds. With that in mind, let's work backwards. If we look at a typical sequence of communication between a browser and a server, 600 milliseconds of that time has already been used up by network overhead, a DNS lookup, a network round-trip to perform the handshake, all of the HTTP requests, that leaves you with 400 milliseconds. In 400 milliseconds, the server must render the response, the client-side code must execute, and the browser must display the content.
So, how do we do that? The first goal is to get the server to render the response in under 200 milliseconds. The server response time is how long it takes for the server to return the initial HTML. And because we only have so little time, you've really got to keep this below 200 milliseconds. The next piece is to minimise the number of redirects. Additional redirects can add one or two network round trips and that can incur lots of extra latency on a 3G network.
So, I strongly encourage you to minimise your redirects and if possible eliminate them entirely. The third thing to pay attention to is the number of round trips necessary to render that first piece of content, that above-the-fold content. You really want to eliminate how many resources have to be rendered because you can only have so many simultaneous connections. The server can send 10 packets on a connection so you get 10 resources in that one connection.
The more that you add to that, the more round trips that have to happen, the longer the load is going to be. The fourth piece is to avoid any external-blocking JavaScript and CSS in your above-the-fold content. Before the browser can render the page, it has to parse it. And if it encounters a script that blocks that parsing, it has to stop and download that resource and then interpret that information. Every time it does that, it adds a network round trip which delays the first time that the page is rendered.
So, an ideal best practice is for your JavaScript and CSS that is needed to render the region of the site above the fold should be in line. And any JavaScript or CSS that is adding functionality should be loaded after the above-the-fold content has been delivered. The fifth technique is to reserve time for that browser layout and rendering. You need to set aside about 200 milliseconds for browser overhead. The process of taking that HTML, the CSS, and executing the JavaScript is going to take time.
And depending on the speed of that mobile device and the complexity of the page, that can take up to 200 to 300 milliseconds. And the final piece of this puzzle is to really optimise that JavaScript execution and rendering. Complicated scripts and really inefficient code take a lot of extra time so you want to really optimise the code, eliminate the errors, clean it up, compress it, and pay great attention to having it be incredibly efficient so you can maximise those mobile speeds.
I highly recommend that you use the page speed tools provided by Google. You'll find those at developers.google.com/speed/. Here you can run insights on your page. It's going to show you all of the various issues that you need to fix and you've likely already seen this. What's most important is to read through their docs. The documentation has tons of great best practices. And if these are a little over your head, it's still important to read them and understand them so that you can communicate to your developer exactly what needs to happen and point them to these resources so that they understand the expectations for how you need your site to be fully optimised.