Old code. Ugly code. Complicated code. Spaghetti code. Jibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it.

In an ideal world, you would write only new code. You would write it beautiful and perfect. You would never have to revisit your code and you will never have to maintain projects ten years old. In an ideal world...

Unfortunately, we live in a reality that is not ideal. We have to understand, modify and enhance ages-old code. We have to work with legacy code. So what are you waiting for? Let's get our heads into this first tutorial, get the code, understand it a little bit and create a safety net for our future modifications.

Definition of Legacy Code

Legacy code was defined in so many ways it is impossible to find a single, commonly accepted definition for it. The few examples at the start of this tutorial are just the tip of the iceberg. So I won't give you any official definition. Instead, I will quote you my favorite one.

To me, legacy code is simply code without tests. ~ Michael Feathers

Well, that is the first formal definition of the expression legacy code, published by Michael Feathers in his book Working Effectively with Legacy Code. Of course, the industry used the expression for ages, basically for any code that is difficult to change. However this definition has something different to tell. It explains the problem very clearly, so that the solution becomes obvious. "Difficult to change" is so vague. What should we do to make it easy to change? We have no idea! "Code without tests" on the other hand is very concrete. And the answer to our previous question is simple, make code testable and test it. So let's get started.

Getting Our Legacy Code

This series will be based on the exceptional Trivia Game by J.B. Rainsberger designed for Legacy Code Retreat events. It is made to be like real legacy code and to also offer opportunities for a wide variety of refactoring, at a decent level of difficulty.

Check Out the Source Code

The Trivia Game is hosted on GitHub and it is GPLv3 licensed, so you can play around with it freely. We will start this series by checking out the official repository. The code is also attached to this tutorial with all the modifications we will make, so if you get confused at some point, you can take a sneak peek at the end result.

 $ git clone https://github.com/jbrains/trivia.git
    Cloning into 'trivia'...
    remote: Counting objects: 429, done.
    remote: Compressing objects: 100% (262/262), done.
    remote: Total 429 (delta 100), reused 419 (delta 93)
    Receiving objects: 100% (429/429), 848.33 KiB | 305.00 KiB/s, done.
    Resolving deltas: 100% (100/100), done.
    Checking connectivity... done.

When you open the trivia directory you will see our code in several programming languages. We will work in PHP, but you are free to choose your favorite one and apply the techniques presented here.

Understanding the Code

By definition, legacy code is difficult to understand, especially if we don't even know what it's supposed to do. So the first step is to run the code and make some kind of reasoning, what it is about.

We have two files in our directory.

$ cd php/
    $ ls -al
    total 20
    drwxr-xr-x  2 csaba csaba 4096 Mar 10 21:05 .
    drwxr-xr-x 26 csaba csaba 4096 Mar 10 21:05 ..
    -rw-r--r--  1 csaba csaba 5568 Mar 10 21:05 Game.php
    -rw-r--r--  1 csaba csaba  410 Mar 10 21:05 GameRunner.php

GameRunner.php seems to be a good candidate for our attempt to run the code.

$ php ./GameRunner.php
    Chet was added
    They are player number 1
    Pat was added
    They are player number 2
    Sue was added
    They are player number 3
    Chet is the current player
    They have rolled a 4
    Chet's new location is 4
    The category is Pop
    Pop Question 0
    Answer was corrent!!!!
    Chet now has 1 Gold Coins.
    Pat is the current player
    They have rolled a 2
    Pat's new location is 2
    The category is Sports
    Sports Question 0
    Answer was corrent!!!!
    Pat now has 1 Gold Coins.
    Sue is the current player
    They have rolled a 1
    Sue's new location is 1
    The category is Science
    Science Question 0
    Answer was corrent!!!!
    Sue now has 1 Gold Coins.
    Chet is the current player
    They have rolled a 4
    
    ## Some lines removed to keep
    ## the tutorial at a reasonable size
    
    Answer was corrent!!!!
    Sue now has 5 Gold Coins.
    Chet is the current player
    They have rolled a 3
    Chet is getting out of the penalty box
    Chet's new location is 11
    The category is Rock
    Rock Question 5
    Answer was correct!!!!
    Chet now has 5 Gold Coins.
    Pat is the current player
    They have rolled a 1
    Pat's new location is 10
    The category is Sports
    Sports Question 1
    Answer was corrent!!!!
    Pat now has 6 Gold Coins.

OK. Our guess was correct. Our code ran and produced some output. Analyzing this output will help us deduce some basic idea about what the code does.

1. We know it's a Trivia game. We knew it when we checked out the source code.
2. Our example has three players: Chet, Pat and Sue.
3. There is some kind of rolling of a dice or similar concept.
4. There is a current location for a player. Possibly on some kind of board?
5. There are various categories from which questions are asked.
6. Users answer questions.
7. Correct answers give players gold.
8. Wrong answers send players to the penalty box.
9. Players can get out of penalty box, based on some not quite clear logic.
10. It seems like the user that first reaches six gold coins wins.

Now that is a lot of knowledge. We could figure out most of the basic behavior of the application by just looking at the output. In real life applications, the output may not be text on the screen, but it can be a web page, an error log, a database, a network communication, a dump file and so on. In other cases, the module you need to modify can not be run isolated. If so, you will need to run it through other modules of the bigger application. Just try to add the minimum, to get some reasonable output from your legacy code.

Scanning the Code

Now that we have an idea about what the code outputs, we can start looking at it. We will start with the runner.

The Game Runner

I like to start with running all the code through the formatter of my IDE. This greatly improves readability by making the code's form familiar with what I am used to. So this:

... will become this:

... which is somewhat better. It may not be a huge difference with this small amount of code, but it will be on our next file.

Looking at our GameRunner.php file, we can easily identify some key aspects we observed in the output. We can see the lines that add the users (9-11), that a roll() method is called and a winner is selected. Of course, these are far from the inner secrets of the logic of the game, but at least we could start by identifying key methods that will help us discover the rest of the code.

The Game File

We should do the same formatting on the Game.php file also.

This file is much larger; About 200 lines of code. Most of the methods are appropriately sized, but some of them are quite large and after the formatting, we can see that in two places the code indentation goes beyond four levels. High levels of indentation usually means lots of complex decisions, so for now, we can assume that those points in our code will be more complex and more sensible to change.

The Golden Master

And the thought of change leads us to our lack of tests. The methods we saw in Game.php are quite complex. Don't worry if you don't understand them. At this point, they are a mystery for me also. Legacy code is a mystery that we need to solve and understand. We made our first step to understand it and it is now time for our second one.

So What Is This Golden Master?

When working with legacy code, it is almost impossible to understand it and to write code that will surely exercise all the logical paths through the code. For that kind of testing, we would need to understand the code, but we do not yet. So we need to take another approach.

Instead of trying to figure out what to test, we can test everything, a lot of times, so that we end up with a huge amount of output, about which we can almost certainly assume that it was produced by exercising all parts of our legacy code. It is recommended to run the code at least 10,000 (ten thousand) times. We will write a test to run it twice as much and save the output.

Writing the Golden Master Generator

We can think ahead and start by creating a generator and a test as separate files for future testing, but is it really necessary? We don't know that yet for certain. So why not just start with a basic test file that will run our code once and build our logic up from there.

You will find in the attached code archive, inside the source folder but outside the trivia folder our Test folder. In this folder, we create a file: GoldenMasterTest.php.

class GoldenMasterTest extends PHPUnit_Framework_TestCase {
    
    	function testGenerateOutput() {
    		ob_start();
    		require_once __DIR__ . '/../trivia/php/GameRunner.php';
    		$output = ob_get_contents();
    		ob_end_clean();
    
    		var_dump($output);
    	}
    
    }

We could do this in many ways. We could, for example, run our code from the console and redirect its output to a file. However, having it in a test that is easily run inside our IDE is an advantage we should not ignore.

The code is quite simple, it buffers the output and puts it into the $output variable. The require_once() will also run all the code inside the the included file. In our var dump we will see some already familiar output.

However on a second run, we can observe something odd:

... the outputs differ. Even though we ran the same code, the output is different. The rolled numbers are different, the players' positions are different.

Seeding the Random Generator

do {
    
    	$aGame->roll(rand(0, 5) + 1);
    
    	if (rand(0, 9) == 7) {
    		$notAWinner = $aGame->wrongAnswer();
    	} else {
    		$notAWinner = $aGame->wasCorrectlyAnswered();
    	}
    
    } while ($notAWinner);

By analyzing the essential code from the runner, we can see that it uses a the function rand() to generate random numbers. Our next stop is the official PHP documentation to research this rand() function.

The random number generator is seeded automatically.

The documentation tells us that seeding happens automatically. Now we have another task. We need to find a way to control the seed. The srand() function can help with that. Here is its definition from the documentation.

Seeds the random number generator with seed or with a random value if no seed is given.

It tells us, that if we run this before any call to rand(), we should always end up with the same results.

function testGenerateOutput() {
    	ob_start();
    	srand(1);
    	require_once __DIR__ . '/../trivia/php/GameRunner.php';
    	$output = ob_get_contents();
    	ob_end_clean();
    
    	var_dump($output);
    }

We put srand(1) before our require_once(). Now the output is always the same.

Put the Output in a File

class GoldenMasterTest extends PHPUnit_Framework_TestCase {
    
    	function testGenerateOutput() {
    		file_put_contents('/tmp/gm.txt', $this->generateOutput());
    		$file_content = file_get_contents('/tmp/gm.txt');
    		$this->assertEquals($file_content, $this->generateOutput());
    	}
    
    	private function generateOutput() {
    		ob_start();
    		srand(1);
    		require_once __DIR__ . '/../trivia/php/GameRunner.php';
    		$output = ob_get_contents();
    		ob_end_clean();
    		return $output;
    	}
    
    }

This change looks reasonable. Right? We extracted the code generation into a method, run it twice, and expected the output to be equal. However they won't be.

The reason is that require_once() will not require the same file twice. The second call to the generateOutput() method will produce an empty string. So, what could we do? What if we simply require()? That should be run each time.

Well, that leads to another problem: "Cannot redeclare echoln()". But where is that coming from? It is right at the beginning of the Game.php file. The reason why this error is occurring is because in GameRunner.php we have include __DIR__ . '/Game.php';, which tries to include the Game file twice, each time when we call the generateOutput() method.

include_once __DIR__ . '/Game.php';

Using include_once in GameRunner.php will solve our problem. Yes, we needed to modify GameRunner.php without having tests for it, yet! However, we can be 99% sure that our change will not break the code itself. It is a small and simple enough change to not scare us very much. And most importantly, it makes the tests pass.

Run It Several Times

Now that we have code we can run many times, it's time to generate some output.

function testGenerateOutput() {
    	$this->generateMany(20, '/tmp/gm.txt');
    	$this->generateMany(20, '/tmp/gm2.txt');
    	$file_content_gm = file_get_contents('/tmp/gm.txt');
    	$file_content_gm2 = file_get_contents('/tmp/gm2.txt');
    	$this->assertEquals($file_content_gm, $file_content_gm2);
    }
    
    private function generateMany($times, $fileName) {
    	$first = true;
    	while ($times) {
    		if ($first) {
    			file_put_contents($fileName, $this->generateOutput());
    			$first = false;
    		} else {
    			file_put_contents($fileName, $this->generateOutput(), FILE_APPEND);
    		}
    		$times--;
    	}
    }

We extracted another method here: generateMany(). It has two parameters. One for the number of times we want to run our generator, the other is a destination file. It will put the generated output in the files. On the first run it empties the files, and for the rest of the iterations, it appends the data. You can look into the file to see the generated output 20 times.

But wait! The same player wins every time? Is that possible?

cat /tmp/gm.txt | grep "has 6 Gold Coins."
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.

Yes! It is possible! It is more than possible. It is a sure thing. We have the same seed for our random function. We play the same game over and over again.

Run It Differently Each Time

We need to play different games, otherwise it is almost certain that only a small part of our legacy code is actually exercised over and over again. The scope of the golden master is to exercise as much as possible. We need to re-seed the random generator each time, but in a controlled way. One option is to use our counter as the seed value.

private function generateMany($times, $fileName) {
    	$first = true;
    	while ($times) {
    		if ($first) {
    			file_put_contents($fileName, $this->generateOutput($times));
    			$first = false;
    		} else {
    			file_put_contents($fileName, $this->generateOutput($times), FILE_APPEND);
    		}
    		$times--;
    	}
    }
    
    private function generateOutput($seed) {
    	ob_start();
    	srand($seed);
    	require __DIR__ . '/../trivia/php/GameRunner.php';
    	$output = ob_get_contents();
    	ob_end_clean();
    	return $output;
    }

This still keeps our test passing, so we are sure we generate the same complete output each time, while the output plays a different game for each iteration.

cat /tmp/gm.txt | grep "has 6 Gold Coins."
    Sue now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Pat now has 6 Gold Coins.
    Pat now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Sue now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Sue now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Sue now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Pat now has 6 Gold Coins.
    Chet now has 6 Gold Coins.
    Chet now has 6 Gold Coins.

There are various winners for the game in a random fashion. This looks good.

Getting to 20,000

The first thing you may try is to run our code for 20,000 game iterations.

function testGenerateOutput() {
    	$times = 20000;
    	$this->generateMany($times, '/tmp/gm.txt');
    	$this->generateMany($times, '/tmp/gm2.txt');
    	$file_content_gm = file_get_contents('/tmp/gm.txt');
    	$file_content_gm2 = file_get_contents('/tmp/gm2.txt');
    	$this->assertEquals($file_content_gm, $file_content_gm2);
    }

This will almost work. Two 55MB files will be generated.

ls -alh /tmp/gm*
    -rw-r--r-- 1 csaba csaba 55M Mar 14 20:38 /tmp/gm2.txt
    -rw-r--r-- 1 csaba csaba 55M Mar 14 20:38 /tmp/gm.txt

On the other hand, the test will fail with an insufficient memory error. It doesn't matter how much RAM you have, this will fail. I have 8GB plus a 4GB swap and it fails. The two strings are just too big to be compared in our assertion.

In other words, we generate good files, but PHPUnit cannot compare them. We need a work-around.

$this->assertFileEquals('/tmp/gm.txt', '/tmp/gm2.txt');

That seems to be a good candidate, but it still fails. What a shame. We need to research the situation further.

$this->assertTrue($file_content_gm == $file_content_gm2);

This however, is working.

Underwater Acoustic Communication and
Networking for Ocean Sampling

Dr. Aijun Song

Assistant Research Professor
College of Earth, Ocean, and Environment
University of Delaware, Newark, DE 19716

11:45am – 12:45pm Thursday, 27 March 2014, ITE325b, UMBC

On our planet Earth, the marine ecosystem is undergoing significant changes due to human activities and natural processes. These changes call for enhanced capabilities to sample and communicate in the oceans. With this background, underwater acoustic communication has attracted much attention across multiple disciplines, as a means to access oceanographic data in real-time and to support navigation of underwater vehicles. This talk will focus on my recent efforts in 1) characterization and modeling of the ocean environment as a communication medium, 2) development of high data rate acoustic modems, both software and hardware, and 3) application of underwater acoustic communication networks in ocean sampling.

Dr. Aijun Song received his Ph.D. degree in the Department of Electrical Engineering, University of Delaware, Newark, Delaware in 2005. From 2005 to 2008, he was a postdoctoral research associate at the College of Earth, Ocean, and Environment (CEOE), University of Delaware. During this period, he was also an Office of Naval Research (ONR) postdoctoral fellow, supported by the special research award in the Ocean Acoustics program. Since 2008, he has been an Assistant Research Professor of the CEOE, University of Delaware. His research interests include advanced signal processing and communication techniques for mobile radio frequencies as well as for underwater acoustic environments, underwater acoustic signal propagation, and the general area of ocean sampling.

If you’ve searched recently for tips on optimizing WordPress’ performance, then you have definitely come across various techniques that people recommend. These include all sorts of caching mechanisms, such as reverse proxies, object caching and cache plugins, CSS minification, using sprites for images, and so on. All of them are viable and effective ways to speed up a WordPress website’s performance. However, be careful when implementing any of these techniques, and always test their effect on your particular website.

In this article, we’ll cover some of the most common issues with various speed boosters that I have encountered and share solutions to help you fix those problems or find ways around them.

Possible Problems When Using Reverse Proxies Such As Varnish And Nginx

I will start with the reverse proxies because, when used correctly, they can give you the biggest speed boost and, when used improperly, can cause serious problems, such as making your website inaccessible or showing the wrong information to the wrong visitors.

How Do Reverse Proxies Work?

Reverse proxies, like Varnish and Nginx, stand between your visitors and your Web server. When a request for one of your pages is made, your Web server usually has to execute the PHP service that makes calls to the database and then provides the page output and the static resources needed to visualize the page. With a reverse proxy enabled, this result is cached, and the next time someone requests that page, the ready output will be delivered by the reverse proxy, which is much faster and causes no load on your server.

This is great, but to operate correctly, the cache must be purged every time something on the page has changed. This is where things can go wrong, mostly because WordPress does not natively support reverse proxies and requires additional tweaks for the cache to be cleared correctly. Usually, such tweaks rely on WordPress’ default core hooks (think of them as events) to purge the cache when necessary — when a post is updated, when a comment is added, when a post is created, etc. However, if an important hook is missed in the implementation of the reverse proxy that you’re using, then you might have a problem. Additionally, numerous events — ones not a part of WordPress’ core hooks but rather performed through plugins — could change the content on your website.

Possible Problems During WordPress Updates

When updating, WordPress puts your website in maintenance mode, updates its files and then disables maintenance mode. The reverse proxy could possibly cache some of your pages while your website is in maintenance mode. This means that if the cache is not purged, then this maintenance page would continue being served to visitors, actively preventing them from reaching your website even when it is operational on the Web server.

When you update a plugin, WordPress disables it, deletes its entire folder and then adds the new files. During that time, the plugin does not actually work. If it’s a big plugin that adds a lot of functionality, such as a gallery or online store, then your reverse proxy could cache pages with errors on them, instead of the actual content.

When you update manually, the easy fix is either to disable the cache during the update or to purge the cache manually once you are ready with the update. However, when you use WordPress’ native automatic update, these solutions are not very practical. What a good reverse proxy should do instead is automatically purge the cache on each update event. Because both core and plugin updates have hooks in the core, this is easily achievable and should be done by you (if you are implementing the reverse proxy yourself) or by your hosting provider (if you rely on the host’s implementation).

Problems With Online Store Plugins for WordPress

No matter which WordPress plugin you use for your online store, you should be very, very careful when implementing reverse proxy caching.

For example, you could create a lovely mess with a shopping-cart widget that displays the products that a customer has selected to buy. If that content is cached by the reverse proxies, then all of your visitors would see the products that the first customer has selected for purchase. Things could get even worse if pages containing personal information, such as thank-you pages, are cached and displayed incorrectly to the wrong visitor. Needless to say, this should be avoided at all costs.

The safest way to avoid such problems is to exclude the entire e-commerce part of your website from the cache. Usually, reverse proxies implemented by hosting companies exclude the most common WordPress e-commerce plugins from the cache by default.

If excluding the whole e-commerce part of your website does not sound to you like an elegant solution — because you would obviously lose the speed benefits — then, theoretically, there is a more intricate way around: using Edge Side Includes (ESI) to specify that parts of your pages should not be cached. In theory, you would simply surround your HTML with ESI tags:

    <esi:include> Dynamic content <esi:remove>
    

Then, the content between those tags would be dynamically retrieved every time this page is requested.

Unfortunately, implementing ESI with WordPress is not straightforward at all, due to WordPress’ lack of native support for reverse proxies. Thus, ESI is usually not a viable option with hosts that support reverse proxies. But it is worth considering if you have an online store built with WordPress and you are implementing the reverse proxy yourself.

Problems With Rating Plugins

When you use a rating plugin on a WordPress website that is cached by a reverse proxy, chances are that visitors will often see an incorrect cached rating, instead of the real up-to-date rating. The reason is that a visitor’s vote given through such a plugin is not part of WordPress’ default hooks and will not trigger a cache purge.

Similar to the e-commerce issues, you could either exclude pages that you collect rankings for from the cache or implement the ESI model for those pages, if feasible.

Issues With Full-Page Caching Plugins

In case your hosting provider doesn’t provide you with a reverse proxy caching service, you could rely on one of the so-called full-page caching plugins for WordPress. When a visitor requests a page, the plugin would save the actual HTML output in a physical file on your server. The next time someone requests that page, it would be served as a static HTML file, which is much slower than a reverse proxy but still faster than not caching at all.

Unfortunately, due to the caching technique being used, all of the possible problems I’ve explained for reverse proxies hold true for the full-page caching plugins, plus some new ones.

Be careful using such caching on a website with many posts or pages. When you create content on a WordPress website, more pages are automatically created than just the one you’re working on directly: category pages that list all posts in that category, tag pages, archives, author pages, pages for uploaded images, etc. All of these add up to a big number of URLs that your website serves. Now, imagine all of those URLs being turned into HTML files in some folder (usually the uploads folder) on your Web server. When thousands of files are in a single directory, even listing those files is difficult, and we’re talking about the Linux OS here. The result for a big website is usually a huge number of files, a heavy I/O load on the server and, eventually, a slower website and problems with the hosting provider.

There is no exact number of posts above which you should not incorporate this method, and it also depends on the particular way the plugin stores the cache — using multiple folders instead of one, for example, would be more efficient, but still might not be enough for a really large website. Just bear in mind that if you use such a caching technique and your website starts slowing down, then this might be the reason.

Object Caching (Memcached) And How To Break It

Object caching is great for a website that gets a lot of requests to its database, and it can really speed up some websites. Memcached stores the result of the most commonly executed queries to your database in the server’s RAM and serves the cached results instead of querying the MySQL server each time. Unfortunately, in some scenarios, you could actually decrease your website’s performance, and here is why.

Some WordPress plugins are coded (badly) to store a huge amount of data in the application database. The Memcached service has a limited amount of memory for caching. Imagine what happens when a plugin stores huge images in the database. Memcached will try to store the result of this query in its buffer but will run out of space. Then, it will start to delete previously cached content on a first-in, first-out basis. If the query’s results are big enough, then no actual content would be cached because it would be removed before being served a second time. In this case, your website would actually slow down because not only would you fail to spare this load on the MySQL service, but you would add another service in the process that requires its own computing time.

If you find your website is working more slowly after enabling Memcached, then unfortunately your only solution is either to disable all plugins that store a huge amount of data in the database or to disable the Memcached service itself.

Sprites: Yes, You Can Go Wrong With Them, Too

I love sprites for the performance boost they give to a website when used correctly. This is why, when we redesigned SiteGround recently, we moved all navigation and UI elements and many other page elements to sprites. Our website became much faster, and we were quite happy with the result. Then, we continued adding elements to the sprite image, until at some point we noticed problems when some pages loaded on iOS devices.

This happened because we hit mobile Safari’s limit on the maximum number of decoded pixels that can be displayed. This limit is different for different devices. You could easily generate a sprite with a lot of pixels, and if it reaches the size limit, then the browser won’t load it, which will leave your website without all of the elements contained in that sprite. Of course, you don’t want this to happen.

A good man by the name of William Malone has crafted a nifty tool to check whether a sprite image will display correctly on all iOS devices. Enter the dimensions of your sprite image in the calculator, and the answer will appear.

If your sprite is too big, a possible solution is to split it into two images. If you have to do this, my advice is to relegate only the newest elements to a new image; otherwise you would have to adjust all of the CSS code that uses the sprite, a task that you’d want to avoid if possible.

Risks With CSS And JavaScript Minification

CSS and JavaScript minification is another of the most common techniques for speeding up a website. Generally, minifying these files entails removing all unnecessary symbols (new lines, semicolons after the final CSS property, comments, etc.), thus reducing the size of the files. This technique applies not only to WordPress but to any page that uses CSS and JavaScript.

Many tools and plugins will automatically minify files. However, some minify more aggressively than simply removing empty symbols. Some tools will rearrange CSS selectors, for example, grouping them by property, etc. In some cases, this could break the entire logic of a CSS file and turn your website into something that merely resembles the original.

To avoid such problems, use basic non-aggressive minification tools that remove only unnecessary data from JavaScript and CSS files, without reordering properties. In addition, always keep a copy of your unminified files because, after minification, they will become practically unreadable, making any further changes much harder. I use either a plugin or the online FreeFormatter.

Gzip: Can’t Go Wrong Here, But We Can Do It Better

Enabling Gzip for WordPress will greatly improve loading speed. Gzip compresses a page’s output and transfers it to the visitor’s browser, like a regular ZIP file, whereupon the browser decompresses and renders it. It’s great because the time a browser takes to decompress archived content is many times less than the time needed to physically transfer the uncompressed content from the server to the browser.

Most WordPress users rely on plugins when they can — at least the ones who can’t or don’t want to code — including for Gzip. Unfortunately, Gzip plugins run through PHP, which, although fast, is not as fast as running directly from the Apache server. All you need to do is install mod_deflate (ask your hosting provider if it is available — it should be because it is pretty much an industry standard) and add a few lines to your .htaccess file:

    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/xhtml+xml
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
    

Conclusion

Knowing all of the risks involved in optimizing the speed of your WordPress website should not stop you from experimenting. To achieve the best results, just follow few simple principles: don’t change too many things at once, benchmark your loading speeds, use staging copies when possible, and test the website’s functionality after applying each new technique. In doing so, you will speed up your website without breaking any functionality or causing problems for visitors.

(dp, al, il)

© Hristo Pandjarov for Smashing Magazine, 2014.