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.
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 ZPE 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.
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.
