When we work on a site from scratch we try to make sure what features are requested, how are we going to implement them and what could be the impact they could have on the site’s performance.
Be it the number of requests to the database, images optimization, minifying files or lowering as much as possible the extra file requests. It’s important to add that most of the techniques below require some custom development work and are not fully covered by the use of WordPress plugins.
Optimize the WordPress Theme.
Here is a list of basic techniques and steps to be taken while developing a site:
- Keep all stylings in one style sheet. If you have more than one stylesheet, it’s possible to run into problems with maintenance as well as loading the different files. Through build tools, file size is lowered thanks to compression. We keep out source files in separate Sass files which are way easier to maintain and we don’t think much about prefixing.Read more: WordPress CSS: Basic Guide for Beginners
- Make sure the right size of images is used. There are just too many sites where 4000×3000 images are being loaded in the content with width no more than 600px. An image that should be no larger than 200kb weighs over 2MB — a nightmare for mobile users.
- Keep heavy plugins usage to the minimum. We try to use only the base plugins required to run the features a client demands. By researching the best solution and weighing the pros and cons we evaluate which of the thousands of solutions will fit the project at best.
- Use SVG, sprites and font icons. Thanks to now popular icon fonts, we make one or two requests giving to your disposal over 400 unique icons, perfectly looking in any site and resolution, making them look crisp on all varieties high-density screen. Of course, some optimizations can be done there as well.
- Test the site’s performance at any stage of development. To make sure everything runs smoothly we need to check if there are any extra resources that might be slowing down load time thanks to tools like GTmetrix and Google PageSpeed Insights.
- Outlining critical CSS for quick renders. Thanks to that, stylings can be applied before loading anything else. Users come to read. Therefore the priority is to we show them properly styled article way before anything else loads, lowering the time you wait for the white screen to reveal what’s behind.
- Reduce fonts in use – there is rarely a need for more than 4-5 typefaces on a page. In that number, you can fit headline + body font and bold/italic variations. But if speed is more important and there are no strict branding guidelines, you can use native fonts that load on each system by default.
It’s not only about load time.
On the CSS side, we can also do some optimizations. Animation is one of them. Be it drop down, sliders, loaders, panels, scroll-triggered animations or anything related. All of this can get real slow real fast while the browser tries to deal with it using software rendering by default which is not as effective as the GPU.
Tricks to forcing the GPU rendering are using the translate3D property, which we try to utilize only when really needed as they can backfire at your site with glitches or even low performance in specific cases.
Images are one of the heaviest elements on a webpage if we look at bandwidth. Add a larger images like 300-400kb four-five places on the site and you already reach 1.2-1.5mb just on these images. And there are many cases where users add more than 2-3mb photos. On slow 3G, especially on limited paid connection it’s a nightmare.
There are three very simple optimizations that can be done without any special functionality or new tech:
- Load the dimensions you show – If you show a photo in 200x300px space, then there is no need to load 1200x800px photo.
- Use the correct file format – One simple way to know when to use PNG vs JPG is this: If it’s a photo (complex graphics) -> JPG. Then you won’t worry too much about compression. For smoother graphics, solid colors or transparent images – PNG.
- Run basic optimization on each photo – there are free resources like TinyPNG that will show up to 90% reduction of file size.
Cleanup 404 errors.
Often there are assets that the server tries to load but the request returns a 404 error. Handling this error takes time and this can easily be seen on the page.
Easiest way to track such errors is through the browser’s network tab on it’s developer tools. For such resources we first try to find the correct URL – sometimes third party tools change their work, so the request has to change as well. Other times it’s an old photo that has been deleted for one reason or another.
If we can’t find the right URL and replace it, we just remove the request as in both cases it loads nothing, but in the second one it loads nothing faster.
When you open a page for the first time, you load all resources that page requires in order to render and function as desired. When you click on a link on that page, you load again everything that is needed. Of course, we are simplifying here, but that is the general case.
So how can we speed up this process? Well for one, if you are certain that your visitors will load an external page (not on your domain), then you can do a dns-prefetch to it. For bonus points it can be paired with preconnect as suggested by MDN.
Another good way is to load resources for the next page you are about to open as soon as you hover onto a link to it. InstantClick is a nice library that does that.
If you want an even better performance, prerender is a good choice. It’s important to know however that you need to be quite certain where your users will go. If your users don’t go to the page you pre-render, then you make them needlessly load resources they won’t need. But as good as it sounds, pre-render’s support is rather poor.
It is always a good practice to watch out for memory leaks, unnecessary loops, redundant function calls and etc.
Another trick you can have in your slieve is to know how and when to load third-party scripts, assuming that you are loading them in the “<head>” of your HTML:
- asynchronously (default) – adding “async=true” to the script tag you are trying to load, will tell the browser to fetch the script asynchronously, and when it’s ready, the HTML parsing is paused to execute the script, then it’s resumed. So, if we have several async scripts, they may execute in any order. Whatever loads first, runs first.
- non-asynchronously – using “async=false” will tell the browser to fetch and execute the scripts one by one. This could be a bad practice in some scenarios because this could block the content rendering of your page.
- defer – using “defer” will tell the browser to fetch the script while parsing the HTML and execute the script after the HTML is done. This could help you reduce the time for the first paint of your page, but in the meantime will increase the time to interactive.
Avoid animating heavy elements.
In general, the goal is to keep 60 or more frames per second — the standard refresh rate of your monitor. With this FPS you will get the smoothest animations creating a nice fluid experience for the site/application.
Caption – Animating heavy properties will result in drop of frames. Easily noticeable, it will be a hindrance in smooth performance.
Good example of properties that can have a noticeable effect on animating is box-shadow. A very good tutorial and explanation on this can be found on tobiasahlin.com’s article about How to animate box-shadow.
Load heavy resources only when needed.
One way we reduced the time to load for a site by half a second was to remove one of the heavy scripts for chat messaging. Of course, it’s a required feature, so here is what we did: We’ve implemented the same view of the chat button in the lower right corner as the third party tool.
Only difference was that we began loading and parsing the JS responsible for everything inside once the cursor hovers the button. Between hovering and clicking there are roughly 500 to 750ms time. That + light animation we’ve used, we have extended the time for the script to load to about one second. The user saw 300ms animation.
There are countless other ways to improve performance.
We’ve seen sites where performance issues come from bad development practise – wrong way of using Sass, bad backend queries and ineffective operations inside loops.
- Large CSS file is generated (and has to be downloaded) if there are many extends in the Sass files. This creates huge chains of selectors which can increase the weight of the CSS file a few times
- Remove scripts that add little to no value – sometimes a site owner tests new plugin or third party integration by injecting a script that tracks some metrics. This then becomes forgotten or is rarely used. Sometimes, it’s best to remove it in order to provide a better use experience
- Loading assets that are not yet required – for this often there is lazyloading available. Just showcase images or use scripts and forms when needed.
Keeping organized style sheets, minifying all files, caching, optimizing DB requests and limiting the plugins usage to the minimum can boost site’s load time and general usage experience noticeably. Having all these properly implemented will rank your site better and keep the readers longer.
There are many small tricks that constantly take place and all of them must be well thought out to give the best maintainable and extendable code base to ease future development — a thing everyone can benefit from.
If you want to learn more on why optimizing your site can drive more viewers and rank you better in search engines please check out the “Marketing side of speed optimizing your site” for better overview of how a page is being ranked and to what extent extra 1-2 seconds of faster load time can change your visitor’s experience.
Further reading: The Complete Action Plan for Building and Growing a Professional WordPress Website