To use this website fully, you first need to accept the use of cookies. By agreeing to the use of cookies you consent to the use of functional cookies. For more information read this page.

Personal Blog

I thought I'd share some Linux wisdom with you all. Today I'm talking about symbolic links.

Until recently I have been making my live site a direct duplicate of all content of the development site. This meant that I needed to have two copies of all static files. Uh oh. For instance, my photo gallery on my website is about 400MB in size, so that's 800MB used for the photo gallery between the development site and the live site. 

Overall, the method described is expensive and isn't necessary. I have been for quite a while considering symblinking the two to avoid static content being duplicated. Alas, it has been done. I now have a new section on the web server called user_content - a place where all user content that is identical between the live and development websites will go. This not only simplifies the copying of content by no longer needing a manual copy between the development and live sites, but it also reduces the storage space that was wasted with the old design.

For example:

ln -s /www/user_content/ /www/sites/

simplifies the whole process of the gallery updates on both the development and live sites.

Overall, using symbolic links has made huge differences to my web server.

Posted by J B Balfour in Tech talk

In the last few hours I have brought a ton of new features to the BalfGallery project - features that make this gallery miles better than what I had with my previous gallery.

In essence, BalfGallery is formed of two of my components - a PHP scripts aptly named BalfGallery and a jQuery plugin called BalfPopup. The popup is used in multiple places on my website and replaced MagnificPopup earlier this year on my website. This was a big change and required a lot of my time to make BalfPopup actually useful. In comparison to the previous gallery, BalfGallery is lightweight, fast and it takes advantage of features of my own BalfPopup which make it really powerful.

On top of this, it integrates better into my own website by flowing with the design concepts of it. Although currently available as a jQuery plugin, it is actually written differently to the other plugins I provide and the jQuery plugin is nothing more than a wrapper.

New features to BalfPopup now include left and right arrows for images - it cleverly finds the next images using the PHP script thus saving JavaScript resources. 


ZPE 1.6 will be out by the end of March and it will include a big update. 

The biggest change or addition rather is that of the new FX look and feel for the GUI. Currently, in alpha stages, I am currently looking to bring a better built-in editor that will use the JavaFX package. ZPE has been neglected for some time, and I aim to stop neglecting it over the next few months. 

Version 1.6 will also bring some performance improvements and bug fixes.

You'll be able to get it soon, and now that ZPE has been downloaded over 5,000 times I am happy to continue developing it.


Today I attended the Amazon AWSome conference and today I decided in the next few weeks I will move over to use AWS in more and more of my projects.

The conference was very useful because it gave me an insight into how I would use AWS but it also covered the basics of getting started and how I can migrate to the Amazon cloud service. I found the talk interesting and I found that the presenters were well informed on what they were speaking about and within the first part of the day I decided it's time to move to using it.

So what did I learn? Well, perhaps most crucially, I learned that it's not as daunting as I first imagined and that they have most of the features I currently have available from day one. I also learned that it's not going to be overly expensive to make the shift - perhaps cheaper in the long run too.

Posted by J B Balfour in Tech talk

Java Applets were once cool and they still kind of are, but they're just no longer relevant in today's world of fantastic web applications.

JavaScript has much replaced these old NPAPI based plugins and it's time that ZPE did the same.

So, as of version 1.6.0, the Java applet will no longer be included at all. This reduces the file size a tiny bit and it's not about that. It's about making the ZPE package much more modern.

zpe 1.6

You may know that back before the release of the iPhone and the real mobile web, websites could be as large as 20MB in size. When the iPhone was released, it came with a web browser that could view the full web - not restricted to some WAP-based website. This was a problem for web developers at the time (I for one was not one of these until 2 years later) as it meant that users using their data allowances to view their websites would ultimately pay the price of running out of data in their given packages very quickly and would suffer slow download speeds (remember, the original iPhone didn't even have 3G, shockingly). 

40% of users will leave a website if it has not loaded within three seconds which means that even though my website downloads in less than one second here in the UK, 40% of users not using 3G will leave the website. The iPhone shook it up. The main outcome of it was that websites were redeveloped with Flash removed, image files compressed, CSS and JavaScript files reduced as much as possible, the HTML content split into different files and the server-side processing sped up as much as possible. It was as though things had to go back the way to before broadband became a thing, but in reality, it was just making websites more efficient with what they had.

Pingdom's Year in Review

The main subject of this blog post is to discuss Pingdom's Year in Review for 2017. This article shows some slightly worrying statistics about how the web is becoming, again. 

Perhaps the most worrying statistic is exactly what was described above being reversed - websites are becoming bigger again. See this graph from the report:

While it is true that mobile devices have faster connections thanks to 4G LTE and we now have faster broadband connections, it is still worrying. I say this because there are still many people who don't have faster than a 1Mbps download speed. 

At the start of this year when I relaunched my website my main focus was on client-side performance, both in terms of JavaScript and in terms of download time. I managed to get my Pingdom result from 1.5 seconds to around 400ms making it faster than 98% of websites that Pingdom tests.

My concern was more about the data usage that it costs however for a user on a smartphone. My previous phone contract limited me to 1GB of data, and I would often get through that in a few days. My current phone contract does give me 20GB of data, but I can often see me going through about 5GB of that in a month. 

As well as the amount of data being downloaded, the number of HTTP requests has gone through the roof. The graph before shows both the size of a website (yellow) and the number of requests (black) made by the website. 110 requests?! That's a lot of HTTP requests. I do get that my website is a personal website, but I do believe that the most important improvement to making a website fast and efficient is reducing the number of requests. Older browsers can only send up to 70 odd requests at once, and yes, older browsers like IE8 still have some market share and we do need to try and cater for them too.

Further down the article, and it's clear that the amount of content being downloaded into a website is increasingly getting bigger too. Particularly images and JavaScript. Now, too much of those results in a lot to download but more crucially, it means more processing, particularly in relation to JavaScript. JavaScript needs to be processed immediately when it is received and as a result, puts more strain on the computer. These days this is much less of a problem with things like the incredible V8 Engine in Google Chrome and Safari's Nitro Engine. But all that processing needs to be done anyway. 

The result of all of this labour on the CPU is that we have slower websites but also we drain the battery of mobile devices much faster. Perhaps this is the main reason why websites should consider what they are doing because the batteries in our smartphones aren't all that good after all (


My concluding remarks on this are we are not going the right way about this. Building a website should not be about making it as functional as possible whilst sacrificing speed. There has to be the balance and it appears we are not doing that at the moment. 

You can read more about this in the review at

year of review

A2 Hosting are an amazing bunch of people. I wouldn't have learned half of what I know about setting up a server if it had not been for them so I'm very thankful to them. They offered a very good service at a very good price but they also had their problems.

When I first set up my VPS early last year I got a lot of help with setting up DNS records and so on (something I can do myself nowadays) but what I didn't get I got from a website I came across a few years ago called DigitalOcean. 

I cannot tell you how many times I've googled something and found an article on DigitalOcean that explains a perfect solution to my problem. More and more I started to think it would be good to host with DigitalOcean but I stuck with A2 until about November. 

In November I got hosting credit for DigitalOcean so I thought I'd give it a try and see what DigitalOcean was like, especially now since I am more competent with setting up my own server. I wrote the server_setup script that I use to configure a server, created my first Droplet and transferred a recent site backup to DigitalOcean. Boom! It worked.

Performance wise, on the front end DigitalOcean was a bit faster than A2, which to me seemed unbelievable since A2 was blazingly fast as it was. 

But I mentioned A2 had problems. There weren't many of those and I think A2 are fantastic but they did have one thing lacking that something that is more tailored to system admins/developers should have and that is snapshots. When I first moved to A2 I asked if they offer snapshots but unfortunately not. DigitalOcean provides snapshots! Snapshots allow me to make backups from time to time, for instance before a big update or whatever. It also means I have a secondary, weekly backup of my server. 

So all in all, I'm sad to be leaving A2 but happy to be moving to my fourth host for my fourth iteration of my website. Hello DigitalOcean!

Posted by J B Balfour in Website news

Many of you will know that I actually moved to a website from YouTube as it was my intention to write articles and reviews as opposed to producing videos for them. Writing them takes a bit longer compared with recording them and editing them as everything needs to be proofread and checked through several times but it's a lot easier to produce a fancy-looking article than it is a video. However, it was my web development interest that made writing these articles and reviews feel better (I also love video editing, don't get me wrong).

It was for that reason I moved to writing these reviews and articles from recording them. 

YouTube was once my main production but it was slow in gaining popularity so it was a bit of a lost cause.

Future plans

My plans for the future of my YouTube are to basically move away from it and back into my website. I average about 1500 views a week at present (I'm sitting at about 500,000 views) but my website has on average being getting about 300 a day. And my website is more enjoyable. I'm going to slowly phase out my YouTube, removing the videos entirely. 

Posted by J B Balfour in YouTube

Well, perhaps we should start with what made my old site slow. In this post, I'm going to talk about lessons I've learned and lessons you can also learn, in particular with PHP.

  • PHP 5.3 - in version 3.0 I used PHP 5.3 on my website. I did eventually move to PHP 7.0 but I had to revert some parts of the website back to PHP 5.3 due to compatibility issues. PHP 7.0 is considerably faster and has a new OP Cache that improves performance further.
  • Database calls - there were tons more database calls on my old website and they weren't optimised. I now make sure that all database calls are to the same connection using connection pooling and use prepared statements on all statements.
  • Deep integration with slower services - a big issue for my old version 3.x website. By including the Facebook API and so on I was burdening my server with things it really didn't need. 
  • File reads - and lots of them. Lots of file reads slowed my server and had a detrimental effect on performance due to file locks. This was perhaps the biggest reason my old site was slow.

What makes my new website fast? 

  • PHP 7.0 and OP Cache - PHP 7.0 is a lot faster and it makes no difference to my new website since it's been heavily optimised for PHP 7.0. OP Cache also reduces the amount of time my server spends parsing PHP and takes some of the load away. (This article explains this
  • Database calls are, as previously mentioned, faster now due to the use of connection pooling and prepared statements. 
  • Less third-party services - my website no longer uses the Facebook API. I've also cut out several other APIs that were being experimented with.
  • Far fewer file reads - in fact, there are only two file reads now - one for the very short head and one for the very short foot. 
  • Object-oriented design - something I've always loved about programming is OO design, and when I first developed version 3.0 I had no idea PHP had an OO model of development. Now in 2018, under the redevelopment of the website, I decided it was best to make it object-oriented. This improves the ease of development but also makes it perform better. 
  • Far less CSS and JS - in terms of front-end performance, the site loads in less than 500ms from a UK based connection (where my server is) and this is only possible due to the optimisations that have been made. I've cut both the CSS and JavaScript files by considerable amounts, even as much as half. This has been particularly successful due to the inclusion of the Girder framework which means less focus on the responsive design that was, I will admit, quite cumbersome before. One of the biggest reasons for the smaller CSS is because I no longer spend time overwriting other CSS selectors and properties because my new website abolishes things like Magnific Popup and utilises solely on my own CSS. This change means that there is less overwriting and more specific CSS. This also means that less time is spent parsing the CSS and makes it better in both battery life usage and performance on mobile devices.

A final word about my site

It's not at the stage where it's finished and I'm also looking at ways to improve performance even more, but at the same time, I'm trying to bring my website back to how it was before in terms of functionality. For instance, I've still not had the time to bring a search box on to the masthead of the site and I aim to get that done soon. And I want to get the Twitter widget a bit more interactive as well.


Today I realised something big that I really wanted to fix. It comes from a really rubbish problem that both JavaScript and jQuery have that I've spent hours trying to fix.

  • $(window).width() >= 800px is not the same as @media screen and (min-width: 800px)
  • window.innerWidth is also not the same
  • window.outerWidth is also not the same

So my solution to fix this and it's a pretty decent fix albeit it's more of a hack, is to put an invisible element known by its class name as media_tester in the .balfbar element. The JavaScript for BalfBar is now programmed to check for this element and if found uses it for media queries. It has also been added to the SCSS file.

Posted by J B Balfour in BalfBar