Posts Tagged ‘wordpress’

Yet more website tweaks

Improve server response time

In my original post about hosting my own blog, I mentioned that Google PageSpeed Insights was complaining about server response time. After some research, I realized that my home page was quite large. It was over 1 MB, mainly because of a particular post which contained some large images. (I was complaining about the way graphics are configured on Windows, and included some large screenshots.) The fix was two parts. First, I cropped two of the screenshots to bring the size down a bit more. Second, I added the “More” tag, which makes users click a “Continue reading” link from the home page if they want to see the whole post.

If you want to measure the page load size on your own blog, clear your browser cache, then open up developer tools. Reload the page. On the “Network” tab (“Net” in Firebug), there is a summary of the number of HTTP requests, the amount of data downloaded, and the time it took.

Add LaTeX and YouTube to WordPress

Recently I found another post that needed some special care. In 2012 I posted about my computer animation project and included a YouTube video and some math equations. These used features unique to WordPress.com: by simply pasting the link, it will embed a YouTube video, and by using a special tag, you can include math equations using the popular typesetting language LaTeX. One way to bring these into my WordPress.org blog would be to use WordPress.com’s plugin Jetpack. Jetpack brings a lot of WordPress.com features to WordPress.org, but I didn’t want all of them. Instead, I opted for two small plugins, WP-Latex and YouTube Embed Plus.

For people setting up their own blog, I’d recommend either Jetpack or a combination of smaller plugins to enable these features.

Website maintenance and tweaks

Keeping WordPress up to date

I originally installed WordPress using Subversion. This provides a really easy way for me to update WordPress:

svn switch http://core.svn.wordpress.org/tags/3.4.1

Replace 3.4.1 with the latest version number. Then I visit the admin panel of the blog and it will redirects me to perform any necessary database upgrades.

Use .htaccess to prevent access to the .svn directory:

# Prevent access to .svn directory
# From http://codex.wordpress.org/Installing/Updating_WordPress_with_Subversion
RewriteEngine On
RewriteRule ^(.*/)?\.svn/ - [F,L]
ErrorDocument 403 "Access Forbidden"

Compression

I’ve learned that content can be categorized into static content and dynamic content. There is an Apache module, mod_deflate, that can compress both types of content seamlessly. It only requires a configuration change in .htaccess, and no changes will need to be made to the application. However, it is inefficient because it recompresses the same content every time someone requests it. For this reason, my web host does not support mod_deflate. Instead, they recommend different tactics for each type of content.

On my blog, an example of dynamic content is the home page, http://www.rratliff.com/. This test or this test can test whether the home page is compressed. At time of writing, I have not found a good way to compress dynamic content.

On my blog, there are several static content files that are typically requested. For example, the CSS and JS files that WordPress includes in every page. Google Page Speed Insights is the a tool that tests compression of every resource needed for loading my blog’s home page, both the dynamic and static pages. I’m looking for a reliable way to compress the static content files that Google Page Speed Insights finds.

Deploying static content

I now have two sections of static content on my website, my Post Voting App and my Portfolio. I’ve adopted a simple solution to keep these sections up to date. Each section is maintained in a github repository. I have a matching repository on my own computer where I make changes, commit, and then push to the github repository. Then, to update the content on my website, I SSH to the host, cd to the directory, and do a git pull.

I reuse the .htaccess code above in order to prevent access to the .git subdirectory. See the .htaccess file for an example.

Backups

I created two scripts to backup the files and the database in my NearlyFreeSpeech site. The scripts aren’t fancy, they just contain one command each.

For the database, I created a non-privileged backup user who has permissions necessary to do a mysqldump on all the tables in my database. Here’s the gist of it. (It should be all one line. Lines wrapped for display purposes.)

ssh user@host mysqldump --user=nonprivilegeduser 
    --password=password --host=mysql_host 
    --all-databases | gzip > backup-file-name-$(date +%Y%m%d).sql.gz

Just change the underlined parts. The $(date) thing creates a filename like this:

backup-file-name-20131029.sql.gz

For the files, I use rsync with the options -aAXE --delete.

Moving a WordPress blog to Nearly Free Speech

Up till recently, this blog has lived on WordPress.com. Now I’ve moved it to http://www.rratliff.com/, where I have control over more of the configuration. I’ve had some experience with WordPress before, but I wanted to update my knowledge. Also, with all this recent talk about privacy on the web, I wanted to set up my own server and see how I could eavesdrop on my visitors learn about it.

For my non-tech friends, here is some quick background. WordPress is two things. It is a blogging software, which anyone can install on a web server that they control. It is also a company who has installed this blogging software on WordPress.com. They control it, but they give it away as a free service (and also have a paid service for those who want more advanced features.) I’ve chosen to move from the free service to the service that I can control. Now I pay NearlyFreeSpeech.net some money to host my blog on their site, but again, it gives me more control over the configuration, and more opportunities to learn.

Things I learned

  • How to list all the tags in Subversion. (I used this to make sure I was downloading the most recent version of WordPress.)
  • An SQL process can have multiple databases in it.
  • WordPress can use a single database to host multiple sites by using a table prefix.
  • In the world of web servers, file permissions matter. For most of my life up till now, I’ve been working on single user systems. Therefore I have not needed to worry about the group and other sections of the unix permission modes.
  • The ability to export and import a blog from WordPress.com to self-hosted WordPress is pretty cool.
  • How to install a WordPress plugin manually. The fastest way is to SSH into the host and wget the zip file. Then unzip it there.
  • My hosted site does not utilize HTTPS right now. Therefore several passwords that I use to administer WordPress are transmitted in the clear. Say hello to my government surveillance friends, and hackers too? Hopefully not.
  • Piwik is a really cool way to do web analytics. There’s two pieces.
    • One is the Piwik tracking Javascript, which is added to all pages on my website. This can be done by the WP-Piwik plugin.
    • The other is the Piwik web server, which handles the requests from the tracking Javascript and then stores the information in the database. It also provides a Dashboard for admins who log in to view the analytics data.
    • Also, Piwik can anonymize part of visitors’ IP addresses to reduce the amount of personal information that is collected.
    • Google Analytics provides a free (as in price) service, but my analytics data is being aggregated with the analytics of a lot of other website, thus contributing to Google’s database. They use this for marketing, which I view as a form of corporate surveillance.
  • WordPress by default does not generate valid HTML. I fixed it on my site by modifying functions.php. See WordPress category tag validation error fix for more information.
  • I installed the Use Google Libraries plugin to change the jQuery to use Google hosting. This has a small speed benefit for users.

Still to learn

  • How to get Apache to do what I want. I really want a good rating in Google Page Speed. Two sticking points right now are leveraging browser caching and enabling gzip compression. There are WordPress plugins that will manage my .htaccess for me, but I think it would serve me well (pun intended) to learn how to configure it myself. Another tool for testing blogs is ismyblogworking.com
  • It would be cool to set up a staging environment, where I can work on plugins and WordPress tweaks without worrying about disabling my production website.
  • It would be nice to have blog posts and pages stored as files instead of in a database. That way I could put them under version control.
  • Either WordPress or my web host has poor performance, because I’m getting the “Reduce server response time” suggestion pretty consistently from Google Page Speed. I know a static site would help immensely in this area, but at the cost of some convenience of administration.
  • Even cooler would be to tie the version control and the staging environment together. When I am happy with the way my blog looks in the staging environment, I can commit the changes, then push (deploy) them to the production blog.
  • My host supports some sort of HTTPS/SSL. I’d like to learn more about this and then consider asking them to enable it.
  • Another suggestion from Google Page Speed is “Eliminate render-blocking JavaScript and CSS in above-the-fold content.” To fix this will require diving into WordPress themes, which I am not looking forward to.
  • There are more recently popular blogging frameworks, such as Jekyll or Octopress.

Keep WordPress speedy by resizing images

When you upload an image to WordPress, it is stored in its original size on the web server. WordPress allows you to specify an image size. WordPress will create an additional copy of the image at that size and insert that in the page instead.

Here is an example:
Original size: 1858×1233 (652 kB)
Wordpress copy: 1024×679 (336 kB)

This means that when people view your page, they have to download 0.5 times the original file size. This is a smaller file download, and it will help your page load faster.

Point to remember: If you choose a size when you insert an image, it tells WordPress to create a smaller file download. This will help your page load faster.

Resizing images

After inserting an image and viewing the page in a web browser, usually you’ll find that your image is too large. So then you go in the Edit Image window and set a smaller size, e.g. 70%:

This presents a problem: If you use the Edit Image window, WordPress will not automatically resize your image file a second time. It will only display the image smaller. This means that the web browser is still downloading the full size file, but it is just viewing it smaller.

I tried resizing the cabbage image above to 70%. Here is what happened:

WordPress size: 1024×679 (336 kB) — Recall that this is due to our choice of size in the Insert Image box.
New size at 70%: 717×475 (336 kB) — But this image could be 186 kB if I resized the actual file.

See the difference? If you resize an image with the Insert Image box, it will actually save space, but if you resize an image with the Edit Image box, it will not actually save space.

Conclusion

Correctly scaling your images before inserting them into a post will solve this problem. If you are going to be inserting a lot of images, use a test image. Insert a single image and use the Edit Image box to find out what size looks right. Then on your computer, resize all your images to this size before inserting them into the post.

Misc notes

Another thing you have to take into account when viewing images is the maximum width of the content in your theme. For example, this blog (bobbyratliff.wordpress.com) uses the Twenty Eleven theme, where the maximum width is 585. Even if I choose the 1024×769 option, the image width is limited to 585. In other words, it will show the cabbage image as 570×377.

Another solution is to add image sizes to the insert image dialog. If you have hosted WordPress, you can use the Additional image sizes plugin to do it.

Google Page Speed is a great tool for troubleshooting slow sites. It has a list of rules that it evaluates your website against. When your page breaks a rule, it will tell you why and give some clues on how to fix it. The information in this post applies to the suggestion “Serve scaled images.”