Day 27 - Page Speed Optimization

Ryuzaki

女性以上のお金
Staff member
BuSo Pro
Digital Strategist
Joined
Sep 3, 2014
Messages
3,378
Likes
6,140
Degree
7


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 True Goal
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.
That is the most basic version of the concept and goal. There's a few new tricks of the trade that we'll discuss too, but if you grasp that idea, you can push your optimization to the top 10% of the internet, without question.

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.


Users Want it, and They Want it Now!
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


Every single metric a search engine can measure in regards to your site, they do. And they use these metrics to determine which site is the most high quality and least likely to be a spammer, SEO, or MFA site in camouflage. Guess what crappy sites who don't care about their users have? Really bad, super slow page load times.

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:


That's a real world example of a popular website's homepage. Don't worry about the performance grade as some of it will be out of your control. You want to reduce the Requests, Load Time, and Page Size as low as possible.

Here's one of my homepages for comparison:


That's more like it. You almost run out of fingers counting the seconds waiting on the first site to load. Mine loads before your finger finishes clicking the mouse button.

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
Theme designers are often just that. They know what looks pretty and know how to get it there and that's all they care about. They don't know about this stuff any more than the average webmaster does, and that's why you're about to gain a competitive advantage.


• Fixing Resolutions
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:


TinyPng will compress PNG's and JPG's! Another option is Kraken, but I prefer TinyPng's algorithm. Notice that both images were compressed by an average of 63.5%. Imagine doing that to every single image on your website. You can likely cut your loading time by a third if not by a half, depending on the number of images you use, just by compressing them.

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.


Plugins
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
If the plugin falls under any of those four categories, then it's not crucial to your website. Deactivate it and delete it. No mercy, no remorse. Now go re-measure your homepage and inner page. I can guarantee you dropped requests and it's faster.

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.


Edit the .htaccess file found in the root level of your public_html, Wordpress install folder, or where ever it is exists based on how you installed your site on Day 4.

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.)


Intermediate & Advanced Methods
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.

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 Database
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
That's it. With a system font for OSX, Linux, Windows, etc., the font can pop on screen immediately without waiting on Google Fonts or Adobe TypeKit, etc. With the CSS for sitewide elements inlined into the HTML, they can load before the CSS stylesheet is loaded. And finally, if your JS files are in the footer, everything else can happen before they are encountered linearly by the browser. That means the server will send them last.

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:

 
Joined
Sep 17, 2014
Messages
418
Likes
262
Degree
1
I just discovered while trying to do this that Kraken will maintain your folder structure. So you can zip and download your entire wp-contents, run it through Kraken unzipped, get the result, re-zip it, and re-upload it. Now you've got a backup too in case your upload messes up.

I'm torn because I do see that TinyPng is shaving off more of the file size without any visible difference. I didn't want to drag and drop 25 images at a time in there. I eventually found their plugin for Wordpress, where I can run through my media part of the dashboard and click to compress the old images (and it automatically compresses the new ones!). The developer API key is free but there's a 500 limit per month. If you want to bulk compress, you'll have to pay $0.009 per image until you hit 10,000 and it drops to $0.002. So you could bulk run 5,000 images for $40.50. Totally worth it to just crunch your whole site, especially if your resolutions are already correct.

On a big site, I can imagine this change alone could alter your life money wise with the extra traffic you'll bring in...

I'm trying to find the easiest, quickest wins from your list to do first (I can't do all the coding stuff yet).

Seems like just the following could make a big difference for anyone's sites:
  1. Compress pictures
  2. Set up Browser caching
  3. Set up a Server caching plugin
  4. Use a CDN
Those are all almost entirely plugin based and easy to do and can all be done for free.
 

Ryuzaki

女性以上のお金
Staff member
BuSo Pro
Digital Strategist
Joined
Sep 3, 2014
Messages
3,378
Likes
6,140
Degree
7
Totally worth it to just crunch your whole site, especially if your resolutions are already correct.
The only potential issue I see with this is with anyone using pre-built themes that generate as few as 3 or as many as 10 different image sizes per image you upload. Wordpress literally creates that many versions of your file, even if they aren't used within your theme. This is something theme developers set up, often sloppily with no regards to page speed.

Just be aware that you may be paying to compress 100,000 images when you only needed 20,000. It's still going to be worth the money to not spend the time trying to sort it out. But you'll continue to pay for it as you hit your 500 images a month limit with all the unused duplicates. The plugin will compress all versions, used or not.

Correction: @Vert pointed out that you can browse in the Dashboard to Settings > Media >
PNG and JPEG compression... and use the checkboxes to choose which sizes you want to automatically compress or not.

I'm trying to find the easiest, quickest wins from your list to do first
These are definitely the quickest and easiest wins, but remember the two core principals of page speed optimization:

1) Cut down how much data you're sending to the browser from the server (what you're doing)
2) Cut down the number of sequential connections (HTTP Requests) you're making by combining data into less files or getting rid of them.

The second point offers just as many benefits if not more because it helps you achieve the first point as you go. But yes, it's a little more technical.

I agree with your list, and that's the order that I'd go after it as well, if my skill set was limited. I'd also use this minifying plugin I mentioned. It's a crutch, but if you need one, you need one. It gets the job done okay. Make sure it plays with your server-side caching properly though.
 

RomesFall

so po qwo ro
BuSo Pro
Joined
Oct 7, 2014
Messages
467
Likes
678
Degree
2
What would you recommend doing about admin-ajax.php on WordPress? I swear I've tried everything and it continues to kill my load times.
 

Ryuzaki

女性以上のお金
Staff member
BuSo Pro
Digital Strategist
Joined
Sep 3, 2014
Messages
3,378
Likes
6,140
Degree
7
@RomesFall, I've never encountered a problem regarding this because I shy away from Ajax on the front-end. Sounds like it's a specific plugin you're using that's abusing the Heartbeat API. It shoots data back to the browser so it can load data in specific sections through jQuery without having to refresh the entire page.

You can use this plugin Query Monitor to determine exactly what is the culprit, or use GTMetrix to look at the Post headers to determine what's hitting it, like here:



In this case a guy had a plugin called WPTouch that was screwy from the developer's side.

I'd identify the problem and get rid of the plugin or whatever code you added, but if you must keep it, you can control the frequency at which the Heartbeat API can be pinged. It can be done through a plugin such as Heartbeat Control or you can write a manual function to do it.

Constant pinging of this API can eat up CPU resources and continually hold data in RAM and possibly attempt to refresh it on each ping. It's also additional requests and waiting on the server to load things that aren't even being displayed the first time around.
 

turbin3

BuSo Pro
Joined
Oct 9, 2014
Messages
611
Likes
1,253
Degree
3
Unfortunately, it would seem a lot of themes and plugins are now starting to utilize admin-ajax.php to an increasing degree. They usually utilize them to perform real time functions, to parse and save or return things in real time, for data logging, and a number of other things. For example, Thrive Themes' plugin, Thrive Leads, offers a lot of lead gen features, including impression tracking of users' activity around and with your lead gen forms. It accomplishes this through using admin-ajax.php to monitor those lead gen forms and users' activities with them, then saving that data on the backend, so you can see the insights in your dashboard.

The Heartbeat Control plugin helped a little bit. I usually set it to 60 seconds, which is the current maximum. That being said, admin-ajax.php is unfortunately an example of the increasing bloat present in Wordpress by default.
 

CCarter

If they cease to believe in u, do u even exist?
Staff member
BuSo Pro
Boot Camp
Digital Strategist
Joined
Sep 15, 2014
Messages
2,177
Likes
4,969
Degree
6
Checking Caching of Webpage Elements

When doing PageSpeed optimization at times you have to setup caching settings through .htaccess (apache) or your site's conf file on NGINX in order to leverage browser caching correctly.

What is caching? Basically if a user visits your homepage and your website has your logo for example, then they visit multiple other pages, as the user your browser does not need to keep asking for the same logo file over and over, therefore making the experience faster.

I found this tool to help you see your webpage's caching elements, what type of caching and most importantly the length the cache for that element is set to: Cache Checker: https://www.giftofspeed.com/cache-checker/

I ran it on one of my web pages I'm developing and it spit out this detailed info:



^^ When you have elements which are not cached they are separated for you so you can deal with them and then recheck with the tool. It's pretty neat.
 

JasonSc

BuSo Pro
Joined
Mar 30, 2016
Messages
86
Likes
124
Degree
0
@Ryuzaki First off thanks for the great guide. I have had some great success getting my pages to load faster. While work on this, I ran some test on Google PageSpeed insights and one of the suggestions was to enable Gzip compression.
After some searching I found some code to add to .htaccess. After running a test on Google as well as pingdom I did see a huge gain in speed and reduction in file size. The WP theme is really bloated. I used a couple of different browsers and did not notice anything funky going on.

My question: Is there a reason to use or not use Gzip when working with a stock WP theme? If you recommend using it, are there any known issues I should look out for?

I would prefer to use a theme which was written well, but in this instance I am handcuffed to my client's needs/wants.
 

Ryuzaki

女性以上のお金
Staff member
BuSo Pro
Digital Strategist
Joined
Sep 3, 2014
Messages
3,378
Likes
6,140
Degree
7
I didn't specifically mention Gzip, because in my mind it was implied in the portion on server caching. I just re-read it and it's definitely not obvious to the reader, so thanks for bringing it up.

When it comes to Wordpress sever-side caching, I recommend WP Super Cache, a plugin developed and maintained by the Automattic team themselves (official Wordpress stuff). If you use that, it will automatically apply the proper .htaccess code to enable Gzipping only in relation to the cached files.

If you aren't using Wordpress, you can find simple copy and paste material for Apache and Nginx servers online that will Gzip all of the appropriate file types.

Gzip Explained
For those who aren't aware, Gzip is exactly what it sounds like. It's a compression method to reduce the amount of data being sent from the server to the user's browser. This saves you on bandwidth costs and increases your page speed. Every modern browser is equipped to decompress Gzip content.

The browser sends an HTTP Header saying that it can Accept-Encoding: gzip and if your server is set up and has it ready, it will respond with Content-Encoding: gzip.

The basic conceptual idea is that it will take redundant expressions in HTML for example, and reduce them to variables. So something like:
HTML:
<div>Once upon a time...</div>
<div>Once I had gone to the store on time...</div>
Might be reduced to:
HTML:
1xt upon a 9cR
1xt I had gone to the store on 9cR
Conceptually it's a simple replacement process, cramming longer repeated items into smaller variables. I'm not sure how many times it runs through either but I assume more than once, packing variables into variables. This is different than minifying HTML & CSS but similar to Javascript.

Here's an example of one of my own pages I just ran:



That's a substantial savings, as @JasonSc pointed out. 81%... I'll take it! You can run this same test at: http://www.gidnetwork.com/tools/gzip-test.php

If you're using Wordpress, let WP Super Cache do this for you along with other caching work. It will set up pre-compression and expiry dates and more to save you a ton of server load. If you embark upon doing this yourself, make sure you really take the time to understand your options. A wrong configuration can save you in one area at a trade off in another...
 

CCarter

If they cease to believe in u, do u even exist?
Staff member
BuSo Pro
Boot Camp
Digital Strategist
Joined
Sep 15, 2014
Messages
2,177
Likes
4,969
Degree
6
Just tested out this new code that allows you to load CSS without blocking rendering:

Code:
<link rel="stylesheet" href="css.css" media="none" onload="if(media!='all')media='all'">
<noscript><link rel="stylesheet" href="css.css"></noscript>
Source: http://keithclark.co.uk/articles/loading-css-without-blocking-render/

Allowed me to get 100/100 with Desktop. Mobile is so full of it, it's like come on dudes...

 
Joined
Jul 12, 2017
Messages
23
Likes
6
Degree
0
Question @Ryuzaki , If I'm using a theme and initially start with an import that includes dozens of pages. Does reducing the amount of dummy pages speed up my site? I currently have countless pages that were included in the import, and I was wondering if I got rid of them, whether or not that would impact my site/page speed.
 

Ryuzaki

女性以上のお金
Staff member
BuSo Pro
Digital Strategist
Joined
Sep 3, 2014
Messages
3,378
Likes
6,140
Degree
7
@Richard, initially I'd say no, in the grand scheme of things. Those are pages set up in the database. And even with dozens... let's say 36, that's not going to bloat your database too much, relatively speaking. If you want to cover all of your bases then I see no reason not to delete them. But 36 dummy pages in a database of 1000+ posts is a drop in the bucket.

In my case, being anal retentive, I'd definitely delete them and any images uploaded to their posts associated only with those posts, partially for speed and mainly for database and server organization and future storage considerations. The gain to speed would be negligible but I have to keep a clean house.

To get a real world idea of how much this would impact your site, check out WP-Optimize, mentioned above and assuming you're talking about Wordpress. Use it to clear out post auto-saves, post revisions, trashed comments & spam, and anything else you see floating about. Do 3 before measurements and 3 after measurements and average them out and you'll get an idea of the savings. Of course it depends on how much you delete out of the database. It can definitely add up, especially if you're not using server caching.