- Joined
- Sep 3, 2014
- Messages
- 6,244
- Likes
- 13,129
- Degree
- 9
We've been discussing the importance of market research. We want to promote our new asset in front of the right people. We want to target the keywords that the right people in the right frame of mind actually use when they search.
Once we have these "right people" on our websites we'll also go through the trouble of split testing our copywriting, our website design, and even tweaking the steps of our entire sales funnel to make sure we're not leaving money on the table.
But what if the money never hits the table at all because your page took way too long to load?
It doesn't matter if page speed optimization is an advanced topic. It is fundamental to the satisfaction of every user and spider that lands on your site. You can't avoid dealing with it. No matter how amazing your VPS or dedicated server is and how much money you throw at upgrading it, it can't fix the absurdity of a bloated website.
If you de-bloat your site, you can likely get faster speeds on a decent shared server than you would on a VPS, all while reducing your overhead. You should only consider upgrading your server after you've dialed in the basics of page speed optimization.
The 'Don't Panic' Preamble
I know that we aren't all front-end and back-end developers and that's definitely not expected, let alone of someone who's new to the game. We're going to discuss the overall concept so you understand the main goals and then lay out some easy wins for everyone and even show you tools to help you achieve these goals. We'll put the intermediate and advanced methods in their own section so you can return at any point in the future when you're ready to tackle them, as well as reference the other resources on the forum listed at the bottom.
The only thing I ask of you is to read today's guide in its entirety. Do as much and understand as much as you can. Consider the rest exposure. As you continue learning, it will all click into place for you eventually. Just don't skip over it. A puzzle can never be complete if you leave the inconvenient pieces in the box.
What is Page Speed and How Can We Affect It?
Definition: Page speed refers to the time it takes for a browser to request a page load from a server until it is completely loaded. All of the way.
Misguidance Around the Web
You'll hear talk about making the user happy by ensuring the screen is painted fast even if the rest isn't loaded yet. You'll hear about not carrying about asynchronous items loading slower as long as the content above the fold is loaded and not jumping around the screen as the rest loads. Bologna.
We're not going for tricks and cheats. Yes, making the user happy is the primary goal but there are long-lasting and far-reaching secondary benefits to doing it right that will save and make you money. A trick doesn't reduce load and strain on your server. A cheat doesn't trick the brain of a search engine spider (because it doesn't have one... yet). It won't reduce your bandwidth and make your CDN allowance last longer either. No shortcuts for Builders!
The overall concept of optimizing your page's loading time is very simple. It can basically be boiled down into these factors:
- Asking for the least amount of items from the server, while...
- Making those items as small as possible, while...
- Telling the browser's to remember what they loaded, so you can...
- Make the best use of your server resources.
Why Do We Care?
"Why should we do all of this? The sites my friends all share on Facebook take 7 seconds to load and crash my browser half of the time, and they don't seem to mind. Aren't they the average internet user?"
Remember our discussion about managing user's mind frames and levels of intent? Facebook AND those crappy sites your friends are sharing don't care about page speed because they don't care about conversions. They want impressions and they know that the clickbait is too strong for users in a zombie state of mind craving a string of quick entertainment fixes.
For any mind state other than that of bottom-barrel entertainment, the user's do not want to delay their gratification, especially when they know 100 other sites can provide the same information, service, or product.
If someone wants to watch Salem and Netflix happens to be very slow that evening, they're going to browse their happy asses right on over to Hulu. And if Hulu is slow or doesn't have it, they'll check their Amazon Prime subscription they forgot about, because they value the speed and quality. But if Amazon doesn't carry it, they are going to end up at Google typing something like "Salem s1 stream."
Yay right? Your super crappy user experience on your ghetto streaming website with 800 pop-ups got a visitor and they accidentally clicked on a pop-under before deciding to drive down the street to the Redbox.
If Netflix had been running well, that entire journey wouldn't have happened. (This is why ISP's are throttling Netflix traffic, because they don't want to upgrade their infrastructure. They want to strong arm Netflix into paying extra fees, which would get pushed off to us, the user). That's a real world example of Page Speed Optimization having a huge affect on the United States with the whole net neutrality fiasco.
If an extremely wealthy person is on your site, zooted out of his gourd, ready to spontaneously buy a $10,000,000 yacht... the last thing you want is for your site to take an extra 600 milliseconds, let alone 6 seconds. If someone wants to know the difference between a princess cut diamond and a marquise diamond and that advertisement on your page will tell them for the low price of $20 per click, do you want them to bounce because you couldn't serve the information fast enough?
Lesson: You may not notice the benefits in the early days of your business' growth, but Amazon calculated that adding one second (one measly second) to their page speed would equal a loss of $1,600,000,000 a year.
Search Engine Spiders are Judgmental Pricks
When it comes to ranking for the big volume, high competition terms, this isn't what's going to make or break your place in the SERPs. But guess what happens to giant, established sites who shave an extra 500 milliseconds off of the page loading time sitewide? They notice an immediate boost in long-tail traffic for terms that they and nobody else is optimized for.
With a huge majority of searches being 100% unique and never typed before ever, and possibly never again, there's no way to do keyword research on them. Yet that's the largest cut of the traffic pie. It's what's left after you take out your meager keyword researched piece. You win that traffic by being better than everyone else in every way you can, and when it comes to long-tails, a lot of that boils down to page speed.
Lesson: "Someone has to rank for them... might as well be the fast site," says the search engine spider as he ventures across the web.
Before We Get Started - Measure Your Site!
If you don't measure your page speed before starting, you won't know what kind of progress you're making. Browse on over to Pingdom's tool: http://tools.pingdom.com/fpt/
I recommend measuring your homepage from the same location twice and keeping the second reading. This means Pingdom's browser will have cached the cacheable contents of your site. Measure against that as you continue to test, simply because you can't tell them to wipe their cache, or any other testing service. Do the same for a random inner page as well, such as a blog post.
Your results might look something like this:
Here's one of my homepages for comparison:
You don't need to aim for the same levels of optimization as the second picture above. My suggestion for your first time around is to make sure your site loads in less than 2 seconds. Anything less than 1 seconds and you're doing great. If you happen to hit a lucky moment on your shared server and load in under 1 second, don't skip out on optimization. Run your tests at various times of the day and you'll see a true average of your loading time, and it won't be pretty.
The Fool-Proof Page Speed Wins
There are some methods you can employ on your website that'll increase your page speed that don't require you to know a single lick of HTML, CSS, PHP, or jQuery. Let's talk about those first. What we do need to assume is that you know how to use an FTP client or at least log into your server through your browser and upload some files. You have a website so I hope that's the case.
I'm also assuming that you're using a theme for your website that you purchased or downloaded somewhere. For some of these changes to persist through updates, you will want to create a child theme that will accept any changes from the parent theme as you update it for security reasons. If you know that this is the theme you'll be sticking with for the long-haul, it's wise to set that up so you can make changes. We discussed how to do this during Day 4. If you didn't do it, this would be a good time if you intend on doing any page speed optimization.
Shrink Your Images
There are three main problems with the images that you uploaded or that came with your theme:
- They have a huge resolution yet are displayed much smaller
- They are the wrong file types
- They aren't compressed to drop out unused colors
Look at some of the images being used on the site. It might be different depending on your operating system, but right click on one and copy the image location. Paste it into the browser. Does it appear as the same size as it does on your website? Or is it five times as large?
There's zero reason to take an image that is 4000 x 3000 pixels and then display it on your site as 400 x 300 pixels. You're forcing the user to load ten times as much data as they need to! Look for and fix every instance of this problem. Some Wordpress themes will tell Wordpress to create various thumbnail sizes for you so that this problem never occurs. Maybe you got lucky. If you didn't, go through and resize these images, compress them, and re-upload them at the exact same location on your server or re-upload and re-associate them in your media organizer and visual text editor.
• File Types
There are three main image file types for the web these days: JPG, PNG, and GIF... This differences are related to how well they print onto paper or show up on the screen. Don't worry about paper. With that being said and with the recent advancements in compression algorithms, JPG and PNG can be considered equal. I prefer to use PNG's because I usually include text and watermarks and they seem to hold up sharper with less jitter. They both display sharp enough on the screen.
GIF, in comparison, is a very lossy file format. It was designed to require the least amount of storage possible by reducing images down to a smaller set of colors. When images are small in resolution, such as icons, or are purposefully blurry such as background images, you can take advantage of converting them into GIFs to save storage and bandwidth.
Go through your theme itself and look at the images included in its design. Are there background textures, small icons (25 x 25 and smaller), or other visually unimportant images that can be converted to GIFs? The savings will be drastic and sitewide. Every page on your site will benefit from these changes. This is also why you need to create a child theme, so that you won't overwrite them if you update your theme in the future.
• Image Compression
With zero exaggeration, this is by far the easiest place to speed up your site and one of the most impactful. If you do nothing but this, you'll notice a strong difference.
You know the two page speed images above? Here's a screenshot from when I optimized them using www.TinyPng.com:
Once you resize all of your images and convert the small ones to GIFs, you can mass-compress them together. Keep the file structure the same and zip the folder when you're done. Reupload it and unzip it and you'll replace all of your images with your new, smaller versions. Be careful if you're unsure of what you're doing. Take a backup of your site first if you aren't sure.
The above methods will reduce the amount of data that your server has to send to the user's browser.
Every single request to your own server is linear with the current structure of the internet, unless you dig into some advanced methods later. The principle holds true even then for the most part. You can only serve one item at a time and until it finishes, the next one can't start. That's why making them as small as possible is a big deal. The faster it flies through the pipes, the sooner the next piece can start.
Shed, Combine, & Minify
Now let me show you how to make some other items smaller, get rid of some requests by combining items, and simply getting rid of some altogether.
We've been assuming that most people are using a CMS of some sort and that means there's a plethora of plugins available to make your life easier. Even as a developer, I still use my preferred CMS and three plugins that I trust will continue to be updated (because the creators make so much money off of it). I build my own themes, but some of those plugins are far too tasty to avoid.
It's even worse for a newcomer or someone who doesn't understand the damage these plugins can do. They are fun to browse and imagine how easy it would be to add new features to your site. Before you know it, you're up to 700+ requests like the site above and loading almost 5 MB of data. And you're probably not even using the plugins.
With extreme prejudice, go look at your list of plugins and determine which:
- I'm not using but it's activated
- I'm not using and it's deactivated
- I could live without
- I can find a better way of doing it's job
That's because plugins have to exist in isolation as self-packaged monsters that eat time. They are like Stephen King's Langoliers. In order to be generalized enough to slide into anyone's website and work their magic, they have to deploy all manner of images, CSS sheets, JS files, and even get into and bloat your database. Get rid of 'em!
Theme Options
Remember when you chose that theme to use because it looked awesome? It had that giant theme options panel where you could tweak every setting without touching the code? You dun goof'd.
Ask yourself again, "is it critical?" as you go through the options. Does the theme let you use as many Google Fonts as you'd like? Use no more than two, preferably one. Does it let you activate carousels, interesting animations, and other things that move around? Kill them off. That's extra jQuery you don't need. Keep going through the list and see what you can disable.
After you do, re-test your site at Pingdom again. Did you drop more requests and page size? If you didn't, then your theme is "calling" these files and options even if you're not using them. I'd change themes just on principal alone, but if you're attached to it, as a developer friend to dig into the PHP files and get rid of those requests. Or figure it out yourself because...
Combine and Minify CSS & JS
Once you're done trimming the fat, you can take the remaining CSS files and combine them all into one file instead of several. You can do the same with the JS files (javascript and jquery). But make sure that all calls to those files get switched over to the new file or you'll have broken aspects of your site.
Once you've done that and confirmed everything is working fine, open up the files and browse on over to: CSSMinifier and Javascript-Minifier .
Here's what's going to happen. You're going to paste your CSS text into the left side of CSSMinifier and it's going to remove every bit of whitespace and most of the comments. All this does is shrink your file size by a decent amount. You're going to do the same with your javascript, and it'll create new variables, cut out white space, and shrink your file size.
Here's an example of CSS minification:
That dropped the file size from 21kb to 16kb. The more CSS you have, the greater the savings. The bigger benefit is that you're now loading one CSS file instead of four.
You see the pattern here? All we want is least amount of files that are as small as possible to the job we need. That's the majority of page speed optimization.
Sometimes you can't combine external resources from plugins with your main resources without the skill set and time to deal with it. And then that reduces a lot of flexibility for the future. If you're on Wordpress, check out the BWP Minify plugin. It will take all of these files, maintain their loading order, and then minify them for you. That includes CSS & JS. As I warned before, don't accept this solution if you can do it otherwise. You're adding operations to remove operations when you could have a higher net gain doing it manually.
Seal the Deal with Caching
You've come a long way. If you were thorough and ruthless in combining the good and shedding the nonsense, your site has made some serious progress. Every page is now loading faster thanks to these sitewide decisions you've made. Now we're going to replace your old two-stroke fossil fuel with plasma ions.
ROM vs. RAM (or as the kids call it these days, storage and memory). Caching tells your server and your user's browser to quit asking it for the same stuff over and over again. It says "Hey, I've sent you style sheet already. Pull it out of your memory, dummy," and "Look, I already trudged through the database to find all comments for that page from this date to that date, I'm not doing it again. Use your short-term memory."
Browser Caching
Every website can have or already has an invisible file called .htaccess, where the period at the front tells your file system to hide it from you so you don't screw it up. You need to become familiar with this file as a webmaster because it controls a lot of the behavior or your site and of your user's browser in regards to your site.
You'll need to tell your FTP client or cPanel or whatever file system you're using to allow you to see hidden files. For cPanel, view the two steps below to enable dotfiles to be viewed in your file manager.
Paste the following chunk of code into it at the top or bottom without changing other information there:
Code:
## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>
## EXPIRES CACHING ##What this does is not only tells the browser to cache the file types listed, but tells them when to expire them as well. That means that as long as the visitor continues to visit your site, whether that be viewing multiple pages in one session or coming back daily to read your blog, it will hold a copy of the files and load them from memory instead of requesting them from your server again.
Beware, if you change the file, the new version won't load if it's still cached. You need to change the file name or tag on a dynamic variable such as... image.png?v2 where ?v2 is the dynamic tag. Double beware, files with dynamic variables can't be cached! What a cruel world.
Server-Side Caching
If you're not using a CMS, don't bother with this unless you have a managed server and can't get the host's support to do it for you. If you're using a CMS such as Wordpress, Drupal, or Joomla, there's going to be a server-side caching plugin available. It will have default settings that I don't suggest you change unless you know what you're doing.
What this does is cache static versions of all of your dynamic pages that your server and send to the browser instead of re-pulling all of the information from the database every time. It will go as far as to store individual objects such as dates, comments, blog posts, meta data, and more. The less time your server spends running through the database to compile pages, the faster your user can start viewing it.
That's it! As a beginner with minimal knowledge of scripting and display languages, server set-ups, and other nuances of the game, you still managed to optimize your site better than everyone who never knew to try and most of those who did try! The adventure doesn't stop there by any means. Return to this guide in the future when you're ready to really push the limit and investigate the intermediate and advanced suggestions below.
One more word before we move into the more complicated methods...
When Do I Need to Upgrade My Server?
Earlier, I was discouraging you from running off and using money as a method to increase your page speed, because that's not how it works at the start. Server resources can only help a bloated website to a degree. However, once you've done all of the beginner methods above and you're not happy, then you might consider an upgrade.
For instance, if you cut the number of requests drastically along with the total page size and you're still loading slower than molasses, then you're in a position to determine if it's a server problem.
You're more than likely on a shared server right now, which is smart. You don't need an entire server dedicated to your site or even portions of one set aside for your site only, unless you're getting a crazy amount of traffic and noticing it bogging down. The problem with shared servers too though, is that unless you're monitoring it all of the time, you don't know if some other successful website is eating up all of the resources just when you need them the most.
First, determine if your TTFB sucks. That's "Time To First Byte." You can check it: ByteCheck.com
For instance, BuilderSociety.com just registered a 0.139s TTFB for me. My own site from the page speed image above showed a 0.105s TTFB. The horribly optimized site above showed a 0.362s TTFB.
This is a solid indication that the site isn't getting the resources it needs, either because of traffic demands or because it's not optimized well or because it's on a crappy shared server with 1000 other sites. Either way, the server isn't getting the job done like it should.
To put it in perspective, the crappy optimized site's server didn't even send a single byte before my entire homepage had loaded.
You can also log into cPanel or WHM or whatever management portal you have and look at the server resources. You'll be looking at RAM in either a percentage or a number 0.00 to 1.00, where the lower is better. That's how much of your available RAM is being used. You can look at the same strain on the CPU.
If you've done all you reasonably can with speed optimization and you're still getting high resource usage with a high TTFB, then I'd consider upgrading to a VPS. BuilderSociety uses Knownhost and I've been using them for my personal sites before I joined this forum. (Use the coupon code BUSO15 on a VPS-2 or higher, or BUSOSSD for an SSD-2 or higher and get 15% off for the lifetime of your rental.)
There's a lot more you can do to make sure your users and the search engine spiders have the fastest, most well-greased experience on your site. But it requires a little more knowledge about front-end development and other technical skills. If you're not ready, don't open the can of worms.
But if you know how to navigate through the ocean of terminology, coding languages, registrars, nameservers, and the rest, then you're in luck. I'm going to introduce you to some more topics briefly and then point you to other resources on the forum where they have explored in much fuller depth. Apply them all and your site can be loading in half a second or less.
Keep Reducing HTTP Requests
You've probably hacked away at unnecessary features on your site like a neckbeard on a jungle exploration seeking the Pyramid of Speed Loading. But you can't get rid of anything else. They are non-negotiable. That doesn't mean you can't trim the number of requests still while keeping these items!
Do It With CSS!
The axiom is "If it can be done with CSS, do it." Don't go overboard and become one of those guys drawing every image with CSS. Look for simple sitewide wins. For instance, did your theme designer use 10 different icon images to display all of the social networking logos? Forget loading 10 images or even just one. Do it with CSS! There are fonts out there where each letter is a social networking logo. Install that, style it, color it, use it. You've trimmed 10 image requests into 1 font request and saved at least 50kb of bandwidth.
The same goes for gradients, shadows, lines, and other small graphics. Don't load a 0.5 kb vertical slice of a gradient and then run it horizontal with an x-repeat... just draw it with CSS. There's an entire school of web designers that start in Photoshop and slice the final product into HTML and CSS. They end up using a ton of images where CSS itself would have sufficed. When all you have is a hammer, everything looks like a nail... your toolbox is bigger. Focus on CSS and get rid of those images.
Okay, so you converted all possible images into CSS and reduced your load size and number of requests some more. Feels good. But there's still a ton of pictures that weren't worth converting into CSS, but load on every single page. Let's fix that.The axiom is "If it can be done with CSS, do it." Don't go overboard and become one of those guys drawing every image with CSS. Look for simple sitewide wins. For instance, did your theme designer use 10 different icon images to display all of the social networking logos? Forget loading 10 images or even just one. Do it with CSS! There are fonts out there where each letter is a social networking logo. Install that, style it, color it, use it. You've trimmed 10 image requests into 1 font request and saved at least 50kb of bandwidth.
The same goes for gradients, shadows, lines, and other small graphics. Don't load a 0.5 kb vertical slice of a gradient and then run it horizontal with an x-repeat... just draw it with CSS. There's an entire school of web designers that start in Photoshop and slice the final product into HTML and CSS. They end up using a ton of images where CSS itself would have sufficed. When all you have is a hammer, everything looks like a nail... your toolbox is bigger. Focus on CSS and get rid of those images.
CSS Sprites
Imagine a scenario where your header contains your logo, two security seal, a magnification glass icon, along with the smaller version of your logo and a picture of your face in the footer. That's six requests that can become one, all through the magic of CSS Sprites.
A sprite is a handful of smaller images all loaded together on one larger image, like you see here:
You might save some some bandwidth or lose some, but you'll replace five images with one, such as this example. Once the connection is open between the server and browser, it's faster to keep it open and load a little more data than it is to keep opening and closing the connection. If you can find sitewide images like this to combine, you can get massive savings for every single page.
At this point, you use CSS to load the images off of the one picture by defining the images size and their starting locations using Cartesian Coordinates. It sounds confusing but it's not. @turbin3 recommended this tool that I found useful myself. It will generate the coordinates for you as you drag and drop your images around.
De-Bloat Your DatabaseImagine a scenario where your header contains your logo, two security seal, a magnification glass icon, along with the smaller version of your logo and a picture of your face in the footer. That's six requests that can become one, all through the magic of CSS Sprites.
A sprite is a handful of smaller images all loaded together on one larger image, like you see here:
You might save some some bandwidth or lose some, but you'll replace five images with one, such as this example. Once the connection is open between the server and browser, it's faster to keep it open and load a little more data than it is to keep opening and closing the connection. If you can find sitewide images like this to combine, you can get massive savings for every single page.
At this point, you use CSS to load the images off of the one picture by defining the images size and their starting locations using Cartesian Coordinates. It sounds confusing but it's not. @turbin3 recommended this tool that I found useful myself. It will generate the coordinates for you as you drag and drop your images around.
If you're using a database, then it's probably bloated if you aren't maintaining it's cleanliness. It's probably chock full of post revisions, spam comments, taxonomies you aren't using, user accounts, and more.
Danger: Never mess with your database unless you've taken a full backup of your site first.
I wouldn't attempt to do this by hand, personally. If you're using a database, chances are 99.9% that you're also using a CMS. If you're using a CMS it's likely a popular one that has a plugin that will do this for you. Still, backup your site first and then make sure it's a plugin that's trusted and does the job correctly. You don't want surprises later on after you've over-written the last good backup.
For Wordpress, I trust and use WP-Optimize (and it's free).
Prioritize the Above-The-Fold Rendering First
Remember how I said doing only this was a trick and a cheat? Well, once you've done the other stuff, there's nothing wrong with changing your user's perception of how fast the page loads! If above-the-fold is fully painted and the rest is loading while they are getting their bearings, then all the more power to you.
To pull this off, do the following three things:
- Set up a fallback system font that can pre-load before your webfonts
- Inline the CSS of sitewide above-the-fold elements into the HTML of your header
- Move render-blocking javascript to the footer
Use a Content Delivery Network
CDN's serve one main purpose. They load up stuff like your CSS file, JS files, and all of your images and distribute them to their servers around the world. This reduces strain on your main server and shortens the path your data travels to customers.
Imagine that your server is physically located in New York and you don't use a CDN. Even though this data travels at the speed of light, it's not a straight shot anywhere. It has to jump through different nodes and be re-routed and all kinds of technical details I don't know about. Without a CDN, the guy in Texas is going to experience a faster page load on your site than the guy in California.
However, your CDN supplier might have a server in New York, Texas, California, England, China, Japan, Australia, and South Africa. And when someone from Russia lands on your site, they aren't going to wait for your data to crawl all the way across the ocean from New York. They're going to get it from the server in China, incredibly fast.
That's what a CDN does. Of course, others try to offer you more features like DDOS protection and other things you don't need to worry about. What you want is that distribution of servers around the locations that your user's come from.
Conclusion
Sure, this is getting a bit a more technical, but with the tips above even the uninitiated can cut their loading time significantly to produce a direct positive impact on their revenue.
The stakes get higher and higher as does your traffic volume and value. You'd be a fool to not at least reap the benefits of the easy optimization once your site is earning.
Watch out though! This is an addictive game. Get it good enough. Much like redesigning your site over and over, it can become a trap. Good enough is good enough. At a point, it will be out of your control as display ads and other elements force extra resources to load. Everything's a trade off, and the conversation will always come back down to one word...
Optimize!
Additional Day 27 Study Materials:
