Building a brand-spanking-new website is a lot of fun and excitement in the beginning. Throwing around awesome ideas for cool features can get out of hand though and optimizing for speed can become an after-though. At all times during development page load speed should be kept as a priority.
By “happen” I mean change, adjust, get thrown out and so on. Come launch time, especially on a single developer project, you may think you’ve cleaned every thing up. Or maybe you know there’s a few smaller items you will adjust later but the site needs to go up yesterday. So you launch.
Launch goes smooth, site seems to be functioning well, then the issues just start popping up: This browser doesn’t render margins correctly, on (insert random tablet) the navigation isn’t showing, the affiliate pixels aren’t loading in woo during checkout and so on and so on.
So you spend days fixing and patching trying to get the site perfect. Finally everything seems “right.” Bug issues are coming in at a snail’s pace and the site is working. Why are sales down…
I noticed our site was pretty slow but I didn’t really count how long pages were taking. I hit up the google speed test, holy s#!t we are failing across the board. It sinks in, this is bad.
Check your analytics, look for numbers that are widely different from prelaunch. For me it was bounce rate and time on site. This pretty much verified that page loading time was killing sales. The key here is to find the big bottle necks. Where are they, why are they there and how do we fix them..
Is it server side: Are our php and/or sql queries taking forever? To debug this in WordPress I downloaded a plugin called Query Monitor. This tool analyzes all calls to your database, how long they took and lays it out in a pretty impressive table. My queries were taking a fraction of a second all in all. So it must be in the php execution.
This was much harder to debug.I started by installing xdebug on a local environment because it was taking just as long to load there as it was on the remote server. Sadly, I couldn’t get it functioning right in VVV so I was at a loss.
I was left with two options: Turn off all plugins (still slow as hell, but turn back on one by one to find the culprit if this fixes your issue). Last, go through all the functions I’ve built and find a way to test each for an issue.
Is it post server response: Though this wasn’t my issue, it’s extremely common. The easiest way to find your bottle neck here is to use chrome’s dev tools. Go to a page in question in your browser, open up dev tools tab Network and refresh the page. You will see something like this:
Look at all that glorious data with lines and numbers and all the wonderful things. You can see the order of network traffic while loading the front end here. Look for long ass lines to see what’s taking forever to load and there’s one of possibly many bottlenecks in your load time.
Cache is like cash in a lot of ways. It buys you users and pays for server speed. Carl Alexander recently wrote a killer article talking about the modern server stack that goes into great depth on caching. Check it out here.
The gist of caching is that you will be sending prebuilt pages to users instead of crunching all that data every time someone visits a page on your site. This lowers page loading time tremendously when implemented correctly. Lower load time = lower bounce rate and new users that hang out and check out what you got going on. It also lowers the processing need of your server so you don’t have to spend as much on a bulkier more powerful setup.
You may be wondering what it was that I did to fix my site. It was loading the homepage around 5 seconds and all other pages around 3.5 seconds. This was all happening server side too.
Looking through my code (I built a custom theme) I cleaned up a ton of my functions, removed fluff I didn’t need anymore (some functions were not needed as site specs had changed) and still saw no change.
Then it hit me: I was using the WP REST API to request some posts, pages and build out some smaller navigation items because I’m not the biggest fan of building out WP_Query queries. Looking back, WP_Query would probably be best but there are arguments for the solution I went with.
I’m fairly new to the REST API and just figured it was lightening fast. This wasn’t the case for me. I removed all calls to the API, it broke pieces of my site but the pages were loading lightening fast. So I needed a solution. Michal Bluma, my favorite person on the planet, suggested using transients. I’d never used them before but it sounded like a killer idea.
Transients are a form of cache. You can store data and access it quickly. So my solution was this. The items I was calling with the REST API were not changing often at all. The only one that changes weekly is our homepage slider. So if I built in a way to reset that transient easily then this could work perfect, so that’s exactly what I did.
These guys are SUPER easy to work with. You set them and you get them with a string key you come up with. Here’s how I built it into my slider on the homepage (hence homepage being 5 seconds compared to 3.5 seconds for other pages) to expire after 12 hours.
Notice the $_REQUEST[‘reset_trans’] == ‘please’ … allows me to slap a query on the url index.php?reset_trans=please and have my API call happen and reset the data to whatever is current.
After patching this guy up our bounce rate dropped 20% almost instantly and sales nearly doubled in the first week. Speed Matters. For more information on speeding up your site before sure to check out our article on Turbo Charging the Loop.