Hello I have been trying to optimize static sites for speed and best practices. I have been using the following online tools to generate reports then try to resolve any issues.
I have had some conflicting results with Netlify post processing “asset optimization” (set to off by default).
When I have this issue turned off Googles page speed score is higher than the others, and when I have the netlify post processing asset optimization turned on googles page speed score is very low, but the other sites score 95+.
I know page speed reports don’t tell the whole story. Is there a better way to go about fine tuning website performance? I am looking for something quantifiable that I can show people the difference between website A and website B.
I’ve had the same experience of mediocre scores from Google and good scores from everyone else.
The advice to talk to your users is good, assuming that they are able to tell you what pain points they have with your site being slow. At the very least, it gives you a place to start. My own recommendations, based on a lot of research and tinkering.
Defer the loading of all unnecessary JavaScript until after the HTML loads
Load all CSS before the page loads. The exception is any CSS whose rules are guaranteed not to be used on the page until after everything loads. For example, the CSS specific to HTML that is dynamically generated by a button click.
Almost all modern browsers support HTTP/2, with the exceptions of IE on Windows before 10 and some non-standard mobile browsers. Some benchmarks have shown that switching from HTTP/1.1 to HTTP/2 can give speed benefits, even without changing the site.
You can increase the benefits of HTTP/2 by splitting your CSS and JavaScript into more files (within reason), each of which can be cached separately. This means, e.g., that a change to the CSS for <table> doesn’t force a redownload of the CSS for a generic page.
You can get even higher benefits by intelligently using HTTP/2’s Server Push. Server Push sends certain assets (usually CSS and maybe font files) with the HTML for a request, thus ensuring the assets are in the browser cache when they are needed. I said “intelligently” because Server Push will push assets that the browser already has cached, so it needs to be combined with some method of “knowing” the cache exists. For Nginx, you can set a cookie on the first connection, then push the assets only if the cookie doesn’t exist. Apache has its own method. Netlify does not, sadly, so you’ll have to decide if the extra bandwidth usage is worth it.
Keep in mind that a site optimized for HTTP/2 is less optimized for HTTP/1.1, so keep that in mind if your target audience is at all likely to use IE on Windows XP/7/8/8.1. In that case, I would tell the server to use HTTP/2 but keep the site files optimized for HTTP/1.1: combined CSS or JavaScript files, using CDNs, etc.
Remove any unnecessary requests from the site. If a resource isn’t needed, don’t request it. If you use a small portion of a framework but download the entire thing, see if there’s a way to download only the pieces you use. Examples:
jQuery Slim instead of the normal build
Foundation (Bootstrap competitor) offers multiple download options labeled Complete, Essential, Custom, and Sass. The first three allow you to download only the things you need for your site, no more.
If you use CDNs, make sure they also support HTTP/2 and caching files in the browser. If they don’t, consider finding a new one or hosting the files in the site itself.
Make sure all images are optimized for the web. What that means differs for each format: for JPEG, it means a quality setting of about 70 looks the same as 100, but is a much smaller file size.
As a side note, SVGs are great for images that will be scaled up and down. I use SVGs for site logos on my sites, since they will always look nice and are technically just text files describing how to draw the image. Realistic images do not convert well to SVG, though, so take that into consideration.
Test your site using the network throttling tool in your web browser’s developer console. A simulated 3G network connection is realistic for users on mobile devices and can help you see what is making your site take a long time to load. A simulated 2G connection makes it even more visible, though at that point the network speed itself is also making your site slow.
This doesn’t directly relate to performance, but an important practice even for static sites is to implement various HTTP security headers. This is important if you load untrusted content, such as comments on a blog. You can test your site(s) using this tool, which I used to get my sites up to an “A” grade (a dependency on the sites uses inline JavaScript, or else they would all have “A+”).
There may be more recommendations, but these are the ones that I could come up with on the spot.
Quick edit: I’ve also learned that site speed testers are at best recommendations, and nothing replaces real life use for figuring out what’s slowing your site down.
Moving forward I think I will just use those page speed tools as a rough guide to point out some of the low hanging fruit of page optimization. I think it is easy to tunnel vision here, and realistically a user will never notice a difference between a 400ms load and a 430ms. Instead I will spend time optimizing the user experience - “perceived speed”. @Shadow53 - I will have to look more into those security headers for static sites, I wasn’t aware of all those issues. Thanks.
Any advice for this site? http://ezeeslim.ca/
It loads fairly fast - but I notice it appears in chunks. Should I be lazy loading images? There is a bit of javascript that loads below the fold - should I be code splitting? Any other advice?
At first glance, see if you can set it up to use HTTP/2 instead of HTTP/1.1 and get yourself an SSL/TLS certificate from Let’s Encrypt. If you’re planning on hosting on Netlify, it’s a one-click process. That should also help with downloading images, since HTTP/2 basically allows for downloading files in parallel, while HTTP/1.1 does not.
Lazy loading images may or may not help. I’m not tool familiar with the practice, since my own sites are primarily textual. If there is JavaScript loading below the fold, you can probably get away with adding the defer or async attributes to the script so it doesn’t block the rest of the page from loading.
If/when you move to HTTP/2 (you really should), look at Server Pushing that main.css file. It may help improve loading times a little bit.
One other tip I forgot, which I’m also going to add to the list in my previous post: be sure to test your site with a throttled network speed - something that is built into the developer tools in modern browsers. It makes pain points incredibly clear and, while you can only reduce loading times so much, it can help you optimize the experience for mobile users with a poor network connection.
