Improve Page Speed In WordPress
Articles Blog

Improve Page Speed In WordPress

August 17, 2019

Alright. His name is Joe, and he’s got an e-commerce website with
over 2,000 products. And this site runs on WordPress and WooCommerce. But this site is not just a side hobby. This is his main source of revenue. So that means that this site needs to run a hundred percent
efficiency all the time. But lately, Joe’s had a problem. You see, in recent
months he’s noticed that customers aren’t ordering
as much as they used to. They are not spending as much time on his site as they once did. His bounce rate has increased and even Google has even downgraded him in search results. A quick analysis of his site reveals that page speed reveals that page speed is a contributing factor in
some of these conditions. And why page speed? Well, 57 percent consumers will bounce off of a page if it does not load in three seconds or less. And this goes for mobile as well as desktop. Google has said they are a mobile first-company, and that means that your site must perform just as well on mobile as it does on the desktop. Page speed is also a minor ranking factor in Google’s algorithm. But at the same time, in 2012 and 2013 the page weight of the average web page has gone up from 1.4 to 1.8 megabytes, and it will probably go up again in 2014. You can check how fast any page is on the internet by going to Google Page Speed Insights. This web app will do a quick analysis of those pages and it will give you a grade for desktop and mobile. It will also give recommendations on
how to improve your speed. These are things that I tell each person who wants to increase the performance of their web pages and page speed. Start with hosting. I seen companies that have tens of thousands of dollars going through their website each month. Yet they’re reluctant to upgrade from a
ten dollar shared hosting plan to a $50 or $100 VPS hosting plan. The bad thing about shared hosting is that you get what you pay for. Your website is sharing a server with thousands – if not tens of thousands of other sites. And your hosting company may tell you that you’re getting unlimited resources and bandwidth. But you are sharing resources with all those other sites. Meaning if any those other sites are being
visited, your website is going to lag. With VPS hosting (Virtual Private Servers) you’re still on a server with other sites – but you are given a hollowed out area with dedicated bandwidth and resources. I recommend getting a server-side, oops, a SSD, solid-state drive server These perform very well. If your site is very busy, or if you have a media site with heavy traffic, you can get a dedicated server where it’s one site to one server. It is not
common but that’s a good problem to have. Now, what can site owners do? One simple thing you can do is optimize your images. A lot of times we’re uploading pictures that are this big, when they will only be displayed at a much smaller size on the website. This is a lot of
unnecessary kilobytes that have to be downloaded by the browser. You can either optimize these yourself or have someone do these for you in Photoshop. Realize that when you are uploading photos from your iPhone your iPhone is
taking photos at a resolution that is almost the same as a high-grade camera. What we can do as developers is to make sure that we’re prioritizing
mobile first development. On pages where we have large
background images or large hero images, if we can find a
way to load a smaller image on mobile, and then when the device size or the resolution of the screen increases load the full size image, this will save up to one kilobyte per page. Another thing to realize as developers
sometimes we hide images using display:none in the CSS. If we go using media queries to go from desktop down to mobile. But realize that when we use display: none, the browser is still downloading those resources. If we need to serve large images, we should use Retina.js or similar scripts to look for a replacement image. Retina.js looks for a similarly named photo file, and swaps it out when a retina device is detected. Another thing we can do as
developers is make sure that we’re a using an official theme. I know a lot of WordPress themes are built for customization. Meaning that the browser will go and look for a Google font for the headline text, for the body text. I have seen themes where there is a style sheet for the reset, for the
main styles for responsive styles, and for custom CSS. All of these are HTTP requests that the browser makes to the server. Every time that the Browser has to go to the server for a file, that’s a request that cost milliseconds. If we can consolidate all of our CSS into one file, or not enqueue JavaScript and CSS files that we are not using, we can save unnecessary requests. And shave milliseconds off of the page load time. Also beware of WordPress themes that you might buy on a marketplace and make sure that they are properly coded. I did have one client site where pages were taking 10 to 20 seconds to load. Come to find out, that in the Theme
Options, it was looking for a Google Font style sheet for Arial. Arial is not a a free font, it is not an open source font. It is a proprietary font that is licensed and loaded into every computer. So the browser was looking for a Google Font style sheet that didn’t exist. And after 10 seconds, the browser would finally give up throw a 404 and finally render the page. One more thing we can do is use page caching. Two plugins that I find to be very reliable are W3 Total Cache and WP Super Cache. What a cache does: normally the browser goes to the server, pulls the files from the server and pulls the files straight across the network. But the browser has to look each of these up. With caching, it takes a snapshot of the page and each file it takes to render the page. The next time the browser comes by, it looks in that cache folder, for those files. This saves time looking up files. If you use a Content Delivery Network, this can integrate with these plugins as well. And we’ll talk about that a minute. You can also minify files. Minification is when you remove the white space in a file. Usually this is in CSS, JavaScript or HTML files. You can reduce ten to twenty percent of the file’s weight by minifying. With W3 Total Cache, if you are using a CDN, you can go on the admin screen to these tabs, Performance>Minify>and then if you’re using a CDN, there will be a message that says if you need help adding files manually, there will be a little button that says “Help”. With that, you can add files manually. Put those minified files in your CDN. Be careful not to minify your RSS feed because you can break your feed, and do not minify files that have already been minified. Caching plugins also utilize a little
thing called GZip. And GZip works the same way that a regular Zip file does. Again, normally a browser goes to the server, and pulls the files straight across the network. With GZip and HTTP compression
enabled, the server will compress the files, then they will travel over the network and the browser will uncompress them. This saves milliseconds. You can check and see if your site is already using GZip by going to . CDNs are Content Delivery Networks, and these are useful for two reasons. For one, the browser can only download one file at a time from each domain name. So, it has to pull the HTML, the CSS, the JavaScript and so on down the line. With a CDN you are using an external domain name. So now instead of just pulling one file at a time, you can pull two – twice as fast. Another good thing about CDNs is the images and files that are stored on them – when a person uses their browser, and they come to a site, normally your site is on one server in one location. And if you’re in a city that’s far away from that server, it’s going to take time to travel over the network. With a CDN, it’s going to find the server that’s closest to them, because CDNs have servers that are all over the world. And they will find one close them. Examples of CDNs are Amazon Web Services, Max-CDN and Akamai. The WordPress plugin Jetpack also has a feature called Photon, which acts like a CDN for your images. And it uses as the main domain for the CDN. Here’s the bad part. When people search keywords in Google Image Search, those images are going to be credited to instead of your own website. So you can use that but that’s the trade-off. The last thing I want to talk about is DNS Prefetching. And this something that I read about on Harry Robert’s blog: There’s a link in the video notes. Again, when the browser has to to go to an external server for files… Not your domain, but another domain – say
like Google or Facebook or anywhere else – it has to make sure that the domain name is pointing to the correct nameserver. This is called the Domain Name Server resolution. And it takes a few milliseconds to do. Again, how I talked about when the browser renders the page, it goes down the line downloading assets and files in the order it needs them. With DNS prefetch, the browser looks up the outside domain name and resolves that DNS lookup before the browser comes to the spot in the asset waterfall – where it normally renders in the waterfall. But, this is still a HTTP request so do not overuse this tactic. I will put a link to the article in the slides, anyway. This is the syntax that it uses. And you would put this in theof the document. I would use these primarily for files that are going to be found on every page of your site, like Google Analytics or Facebook JavaScript files Something like that, that’s going to be universal. Now, if you have any questions you can read this follow-up article If you want to follow me on Twitter I am @Lockedown_ on Twitter. My
name is John Locke. Thank you very much. Thanks John.

Only registered users can comment.

  1. Thanks again for letting me give this talk, Jake. Early days.
    If you have a SEO question you'd like us to answer, leave it in the comments below, and we'll answer it in a future video. Peace!

Leave a Reply

Your email address will not be published. Required fields are marked *