Monday 22 July 2013

Using a content delivery network

A content delivery network (CDN) stores your Web site data within different points on a network and can deliver that data to Web site visitors with a decreased amount of bandwidth. A CDN can choose to deliver this data from the nearest geographical location, making the transfer faster. Because of this, visitors don’t access the data from the same place at the same time, which lightens the load on your server significantly.

To use a CDN, you need to sign up for a service that provides a network
and a series of computers to store and serve your data on your Web site.
The CDN can include items like images and CSS, JavaScript, and media files.
Using a CDN reduces the load on your server because the files are delivered
through the CDN, not through your Web server. This is especially helpful if
you use a significant amount of bandwidth on your current hosting account.

CDN services are relatively inexpensive, particularly if you don’t have a lot of media files, images, and data to store on their servers. A few popular CDN providers include

✦ Amazon Web Services: http://aws.amazon.com
✦ Akamai: www.akamai.com

Minifying JavaScript, CSS, and HTML files reduces the overall file size,



Minifying JavaScript, CSS, and HTML files reduces the overall file size,

making them load faster on your Web site. Obviously, adjusting each of the
existing files on your site to make them smaller would take quite a lot of time
and programming skills that you may or may not possess. Therefore, you
may prefer to use a plugin or program to adjust these files. A good plugin or
program used to minify files can reduce the file to 30-40 percent of its origi-


nal size, which greatly improves the response time of your Web site.


 The HTML source code from Lisa’s Web site in its regular state, and Figure 5-3 displays it in a minified state. You can see how minifying shrinks the size of the overall file by removing spaces and line breaks, and shortening the characters used.


Use a WordPress plugin (such as W3 Total Cache (http://wordpress.org/
extend/plugins/w3-total-cache) that has a feature that minifies files,
such as JavaScript, CSS, and HTML, by caching the minified files. This leaves
the original files intact so they are easily readable and editable by you.

Minifying JavaScript, CSS, and HTML

 

You can also improve the speed of your Web site through minifying
making some of the files, like JavaScript, CSS, and HTML, smaller. This
involves taking all the files of your Web site and reducing the size by
doing things like

✦ Removing all line breaks and spaces in the file.
✦ Removing all code comments in the file.
✦ Removing unnecessary characters in the file.

✦ Using code shorthand, where possible, to decrease the amount of
characters in the file.

✦ Combining the files into one file, wherever possible; therefore, instead of
having ten JavaScript files, you could reduce the number to four or five.

 

Using a Caching System for Speed and Performance

✦ Page: Builds and stores (in your Web server memory) all the pages

on your Web site. Page caches generally have an expiration date. In

case you update content on your Web pages, the cache will eventually rebuild itself to capture changes you make.

✦ Database: Reduces Web server overhead by storing and remembering
database tables and queries made by WordPress.

✦ Browser: Stores Web pages on the visitor’s local storage so when she

revisits your site, her browser displays the page from her hard drive

memory, instead of rebuilding it and calling it from your server. Browser
caches have an expiration date, so any changes you make can be cap-
tured again in the future (your site visitors can also set their browser
settings to disable cache — so this may not work for everyone who
visits your site).

✦ Object: Stores data objects or HTML structures, which can increase

server load because, without a caching system, they need to be rebuilt each time the site is loaded in a visitor’s Web browser. Object caching helps the overall caching system by storing complete Web pages and saving them for future loads of your site.

Using a Caching System for Speed and Performance

A good way to improve the speed of your Web site is through caching differ-

ent types of content. Caching content means to store it transparently so that it
can be used for future loads of your Web site. A good caching system for your
Web site collects all the Web pages on your site and copies, stores, and deliv-
ers the files to visitors of your Web site. This significantly reduces the server
load because without it, WordPress creates pages on your Web site dynami-
cally
— each time a visitor loads your Web site, calls are made to the data-

base and code is complied and executed each time to create the page in her
browser. If you use a good caching program, those files are already built and
displayed, so your Web server doesn’t need to rebuild those pages each time.

The following are the different types of caching that can improve your site performance:

Sunday 21 July 2013

Increasing PHP memory limits

To help resolve the PHP memory limit errors, within the wp-config.php,
define the maximum amount of memory that PHP can use by writing one of
these three lines of code, depending on how much memory you allow PHP to
use on your site, and adding it to the wp-config.php file on its own line:

define (‘WP_MEMORY_LIMIT’, ‘64m’); // increase limit to 64M

define (‘WP_MEMORY_LIMIT’, ‘96M’); // increase limit to 96M
define (‘WP_MEMORY_LIMIT’, ‘128M’); // increase limit to 128M

Some hosting providers disable the ability to increase PHP memory limits on

your Web hosting account, so depending on your hosting environment, your
attempts to increase the memory limit may not work. If you discover this is
the case for your particular hosting account, you can contact your host and
ask him to increase the PHP memory limit for your account or switch to a
different hosting provider.

Increasing PHP memory limits

 

Most Web hosting providers limit the amount of memory any one PHP

script or program file can use on the Web server at any given time. PHP is at the core of WordPress (see Book II, Chapter 3), and by default, WordPress attempts to set the PHP memory limit to 32MB. However, if you see PHP memory limit errors on your Web site, such as

 

PHP Fatal error: Allowed memory size of 33554432 bytes exhausted
(tried to allocate 6233929 bytes) …

 

The PHP memory limit needs to be increased to run the PHP script or file. That memory limit error tells you that the PHP script was attempting to allocate 64MB of memory; however, the allowed memory size set by the server is limited to 32MB, which is the reason for the error.

Template and stylesheet path

Once again, you can significantly reduce the number of calls to the database
for the template and stylesheet directories by directly defining them in your
wp-config.php file. To do so, add these two lines of code (replace absolute/
path/ with your own server path and replace /themefolder with the name
of the theme folder you use currently) on their own separate lines:

 

define(‘TEMPLATEPATH’, ‘/absolute/path/to/wp-content/themes/themefolder’);
define(‘STYLESHEETPATH, ‘/absolute/path/to/wp-content/themes/themefolder’);

 

As with the site URL in the preceding section, having these two lines of code
in your wp-config.php file defines the file path within the file structure
in the wp-config.php file, so that WordPress doesn’t need to make an

additional call to the database to discover what the absolute and stylesheet             Book II

paths are.

Template and stylesheet path

 

Just as with the site URL from the preceding section, many themes and
the WordPress core code look for your WordPress theme template and
stylesheet directory through the following WordPress template tags:

 

<?php bloginfo(‘template_directory’); ?> // template directory

<?php bloginfo(‘stylesheet_directory’); ?> // stylesheet directory

Site and WordPress installation Web address

 

As we discuss in Book VI, one of the most common template tags for use in
a theme is the bloginfo(); tag, which has several parameters you can use
to call different bits of information about your site (like the site name and
description, for example). You then can call in different theme template files
and graphics (or images) into your theme. For example, the URL of your Web
site can be defined in your template files with the following template tag:

 

<?php bloginfo(‘url’); ?> // Site URL

 

In Book VI, we cover template tags and parameters in detail.

 

That template tag tells WordPress to communicate with the site database,
locate the site URL, and return it back to the template or plugin file that’s
making that database call. You can greatly reduce the number of database calls
(thereby, speeding up your site) by defining the site URL in the wp-config.
php file by inserting the following two lines on their own lines (replacing
yourdomain.com with your actual domain name, of course):

 

define (‘WP_HOME’, ‘http://yourdomain.com’); // site address

define (‘WP_SITEURL’, ‘http://yourdomain.com’); // wordpress address

 

With these two lines in place in the wp-config.php file, whenever

WordPress comes across a template tag that requests your site URL, it won’t
need to reach out to your database to discover what that URL is because it’s
defined in the file structure within the wp-config.php file. This reduces
the number of calls to the database, which, in turn, reduces the resources
your site uses on the Web server to display your Web site to your visitors.

 

Post revisions, autosave, and trash handling



The Trash feature in WordPress gives you a safeguard against permanently
deleting posts by mistake. In Book IV, you find that you can send a post or a
page to the trash and that this action doesn’t permanently delete it; instead,
WordPress stores it in a virtual trash can. (Windows users can think of it
as the Recycle Bin.) You can visit the trash can any time and permanently


delete the post or page, or you can leave it there and WordPress automati-

cally empties the trash can every 30 days. If you want to adjust this time
interval, you can add the first line of code to force WordPress to empty the
trash weekly, or the second line to disable the trash feature, completely, as
follows (on its own line):

define(‘EMPTY_TRASH_DAYS’, 7); // empty trash weekly

define(‘EMPTY_TRASH_DAYS’, 0); // disable trash

 

Post revisions, autosave, and trash handling

You can also completely disable the default revision feature by adding this line to the wp-config.php file, on its own line:

define (‘WP_POST_REVISIONS’, false); // disable post revisions

WordPress creates these revisions through the Autosave feature. By default,

WordPress automatically saves a post revision every minute. If you take a
long time to write a post, you could rack up dozens of post revisions, which
are stored in the database and take up room. You can change the autosave
interval by adding this code to the wp-config.php file on its own line (this
code changes the autosave interval to 160 seconds, specifically — you can
choose any time interval you want):

define (‘AUTOSAVE_INTERVAL’, 160); // in seconds

Post revisions, autosave, and trash handling

WordPress autosaves revisions of your posts and pages, and you can send

posts and pages to the trash can, instead of completely deleting them. You

visit the trash can and permanently delete your posts or pages. This extra

step is a safeguard in case of mistakes.

In terms of the post revisions, by default, WordPress saves unlimited revi-

sions and sometimes, depending on how often you edit and reedit posts and
pages, the saved revision list can get pretty long. You can limit the number
of revisions that WordPress will save by adding the following line to the
wp-config.php file:

define (‘WP_POST_REVISIONS’, 3); // limit number of revisions to 3

 

Tweaking the configuration file for optimization

Adding a few bits of code to your wp-config.php file can change some of WordPress’s default behaviors and improve the speed at which your site loads. In this section, I describe a few of the most popular configuration tweaks.

 

Moving the wp-content directory



When you move the /wp-content folder, you need to define the new location in the wp-config.php file so that WordPress knows where to find those necessary files. You can define the new path to the /wp-content folder by adding these lines of code to the wp-config.php file (replacing newfolder with the name of the folder you just created):


define (‘WP_CONTENT_DIR’, $_SERVER[‘DOCUMENT_ROOT’].’ /newfolder/wp-content’);

define (‘WP_CONTENT_URL’, ‘http://yourdomain.com/newfolder/wp-content’);