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 (https://9to5mac.com/2017/09/25/ios-11-battery-life-problems/).
Conclusion
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 https://www.pingdom.com/2017.
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!
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.
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 https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-php-performance-benchmark-2016/)
- 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.
I'm going to be working on a few major things over the next few weeks. My main focus recently has been refurbishing my website with a much more elegant backend and I'm happy to say this was finished on Sunday the 7th after hours and hours of work.
As part of the redesign, I took out my developer tools. I was just this morning looking at my Google Analytics page and found that actually, my developer tools were my most visited pages on my website. As a result, in the next few weeks, I will bring them back.
Girder will also see some fixes and improvements, although as I have mentioned, it's largely a finished project now anyway. I particularly think I will bring in printable columns and flexes to the next version. I'm also going to move it to a SASS/SCSS based stylesheet that will make it easier to select what you want from it.
Poor old Dash hasn't seen an update for a while now either, so it's time for me to get on with the main project I'm working on.
ZPE hasn't seen an update for months because I've begun work on ZPE 2.0 but that shouldn't be the way it is. In fact, I am going to make big changes to ZPE 1.5 in the next few days to make it perform better. I will not stop supporting the Java version of ZPE until the code in the new version is 100% compatible with the Java version and all features are available in both versions. I also may not even drop the Java version, because it's really good as an educational tool now.
BalfBar 1.2 has had some fixes over the last few days so make sure to download that. I will also be putting the code up for the amazingly lightweight BalfPopup tool that, in my eyes, is better than Magnific Popup due to the size of it.
As you may know by now I have been in the process of developing a new personal website for the past few weeks. Well, it's finally here!
The new website is meant to be as similar to the old one in appearance as possible, but its aim is to increase performance and change the way it works. The new website uses my Girder framework for the layout and focuses on reusable CSS classes rather than repeating - something that plagued my old website from the beginning (remember, I wasn't really into web development when I started to rebuild it in 2013).
Although version 3 was the big build for my website, version 4 fixes a ton of stuff that made version 3.x less efficient than it could be. Version 4 also now uses all of my newly developed web tools, BalfBar 1.2, BalfPopup, Dash 1.0 and of course Girder. Dropping things like Magnific Popup makes the website even smaller, and in direct comparison, my new website is about a third of the size of my old one. As well as this, it uses my new development site strategy, allowing me to modify the development site independent of the live site.
Version 4 loads in less than 500ms when tested from Europe. Version 3 took approximately 1000ms to load. On top of that, I've developed a faster way of producing the pages, thus reducing the load on my server when running the PHP and in turn allowing more than 100 concurrent requests at once.
For historical reasons, I have kept just one page of my old website intact and available at http://2013.archive.jamiebalfour.scot/.
I've got tons of stuff still to bring to the new website, but the main aim of this update was to make the new site ready for improvements. My new website is by no means finished, but it's very functional and serves its purpose.
Well, it's goodbye 2017 and hello 2018!
In this post, I thought I'd take a moment to go through a few of my plans for 2018.
First of all, I've got big plans for a new piece of web-based software that I intend to work on this year. This new piece of software will be something of a new content management system, server management system and educational tool. I feel that there is a need for something like this. The system will be built on the basics and fundamentals of Dash and will expand on its file management utilities.
Second of all, Jambour Digital will become a company - something I've planned for a while now. Two of the biggest websites I've ever worked on will begin in January of 2018.
Thirdly, I will launch Dash 1.1. Dash 1.1 will improve a lot of Dash 1.0s biggest features and will hopefully be out by the middle of the year.
Finally, I will get around to launching my new website in January of 2018. This will be the fourth iteration of my website, and although it's very similar to version 3, it's underlying design is much different. It's also considerably more performant than version 3.
My new year's resolutions are mainly to continue with the gym and lose weight as well as to get through my teacher training and find the career I've always wanted to do.
Well, it's traditional that I post one of these look backs at the last things of the year and 2017 isn't going to be any different for traditions sake. This year I'm sad to say that I didn't manage my yearly competition of The Legend of Zelda: Majora's Mask.
Also, I write these posts every year, probably just because I'm sentimental and enjoying doing this, you don't need to be interested at all in this post.
Last meal I ate: Macaroni cheese
Last thing I had to drink with a meal: Coca-Cola
Last place I went out to eat: Goblin Ha'
Last film I watched: Kingsman: The Secret Service
Last game I played: Warcraft III
Last song I listened to: Fireblight Ganon (Breath of the Wild soundtrack)
Last person I have sent a text to: My cousin
Last friend I have spoken to in person: Calum Cormack and Nick Thompson
Last TV programme I have watched: Scotland's Hogmanay Live
Last major purchase for myself: Razer Blade Stealth
I keep saying that 2017 was a bad year for me, but the truth is, it wasn't that bad. 2017 saw me finally getting a gym membership, my first industry job, starting my own business, becoming a server administrator, getting my own phone line through a PBX, the release of the Nintendo Switch and much more.
I am hoping to get the next version of my website, which is currently in development, out in January of 2018.
I wish you all the best and a happy new year for 2018!
I thought I'd take a bit of time to look back at my 2017 a bit earlier than normal, but focusing only on the technology side of things and what's happened this year.
This year has been an incredible year for me technologically, as I've learned way more than any other year before. This year, perhaps the biggest gain for me was moving to a virtual private server (VPS) for my website. This gave me the technical knowledge that I never ever had and allowed me to learn server admin stuff. I now know a lot more about Linux servers and the Apache web server and, as a result of this, have started a business hosting websites for clients that I build websites for - something I wanted to do years ago. As well as this, I've learned to tinker the performance to get it right for my website and my clients' websites.
This year also saw me get my first job, working at Maglabs, which was a great place to work but I was just so anxious that I wanted to take the next step and ended up working at DH Systems after just six months at Maglabs. I only ended up at DH Systems for one month really before deciding that it would be better if I took time out for my health. As a result of the timeout, I actually ended up drawing up a business plan and formed Jambour Digital, which I'm very happy to have done. The company isn't quite active yet, but I've got plans to get it up and running in the new year.
I've also learned a bunch of new technologies such as C++, React.js, Angular JS, Node.js and Symfony 2 this year. I've also learned a lot more about Linux command line and now spend most of my day with a Bash Terminal open on my Mac - an incredible difference compared with last year.
Perhaps my biggest achievement this year is Dash. Dash was originally named BalfBlog at the start of this year, but it has since become so much more than what BalfBlog was and needed a name to reflect that. Even as late as May of this year, huge improvements were coming to BalfBlog and eventually Dash to make it the incredible piece of software it is!
Another thing that I'm working on now is ZPE 2.0, which is being written in C++. Whilst I wouldn't say I'm near finishing it, I would say it's progressing quite well.
I must not forget to mention setting up my own personal branch exchange for a SIP phone! Yes, this year has finally been the year that I have ditched my standard telephone and taken on a SIP phone instead and I now have my own business phone line. There was a steep learning curve with it but I got there eventually.
I also finally got my Razer Blade Stealth, the only ultrabook I've ever wanted to own! As well as this I got myself another similar device (well in the sense it docks into a more powerful system) with the Nintendo Switch, which to date may be the greatest console around.
