One of the single part workshops I attended was a discussion and exploration into front end optimization. As someone who works mostly in front-end design, this was an intriguing talk to me. It was rather technically oriented so the notes are a bit dry, but if you are stepping into this field at all, there are a few pearls you might find useful.
The first and most important note that the presenter made was to optimize your digital projects for the front end, contrary to popular belief. While it is of course important to build your systems on a strong framework and have clear channels to resources and reduce unnecessary clutter in back-end code, people often forget the impact front-end code can have to the end user. If your front-end development is sloppily thrown together, this is the layer that directly hits the user, and can easily result in a degradation of performance even if back-end code is flawlessly executed.
The next point the speaker hit on was minifying HTML, CSS, and Javascript files. The number of lines in a file counts toward the KBs needed to load the site and can slow it down. The speaker pointed out that users are unlikely to care about “pretty code” especially if it’s causing slower performance.
Minifying is a practice I’ve had trouble stepping into myself, if only because I like to “grab and go” with my code. I often hear of keeping two copies: your editing file and then uploading the minified version to the web – I just have had little reason to lately, as my own website’s pages are not incredibly line-heavy. Likely as I work more on larger projects, minifying will become more and more my practice – this speaker’s stressing of it was part of the motivation I needed to look into it more.
Next were a few basic points, like avoiding redirects and bad URLs. Not only can they be confusing and frustrating to the user, but redirects can cause the page load time to increase (as the request has to jump around more than usual), and bad URLs will likely destroy the flow of users actually using the application. Redirects like m.mysite.com for a separate mobile versus web version can also cause issues down the road: for instance, content missing from one version of the website and two sets of code to now maintain that have quite a large portion of duplicate content (which may cause issues for search engine optimization). Using responsive design can help fix this issue by allowing one set of code with varied breakpoints to function on all devices. If you must do re-routing, try to limit it to the server side instead of client side to optimize the redirect’s speed and overhead. One last tip: if your redirects attempt to make a user download the app (such as a mobile version of a site redirecting or loading a modal saying you must visit the app store), stop what you’re doing right now. Not only is this annoying and likely to drive traffic away from your site, it’s a poor attempt at getting a hook in a user who isn’t even sure they enjoy your content and can leave a very bad first impression that might make them unlikely to come back. Furthermore, redirecting them to an app because developing your mobile site more robustly wasn’t in your plan shows a laziness to develop your site with their needs in mind.
Allowing GZip Compression was another point made, which required a little more research on my part as I hadn’t heard of it prior. GZip is a compression algorithm for websites that finds similar strings within a file and replaces them temporarily, which can make the file sizes a lot smaller – especially in documents made for the web, where phrases, tags, and whitespace are often repeatedly used. If you (like me) had never heard of GZip and would like more details, find out more here: https://developers.google.com/speed/articles/gzip
Page load times are obviously critical to the success of an application, and can often be an indicator of how optimized performance is (after external factors such as internet speed or evened out, of course). Typical metrics for average load times tend toward users losing interest in a web page if it hasn’t loaded (or at least, loaded something) within half a second. Mobile users tend to have more patience, but after about ten seconds their patience is gone – two seconds or less makes them quite happy though. This number has been one I utilize quite often now when asked “how long is too long” or doing quick load tests. It’s a simple note and numbers to remember, but ones that can really help in a pinch if you’re trying to quickly decide if more optimization of existing code is needed, or to move on to the next task or project as the code “loads reasonably”.
Applying web best practices is a key component of ensuring optimization. Not only will following best practices likely result in more efficient and optimized code, it will also typically result in cleaner code for developers to understand, and greater optimization for search engines, thus resulting in more end users.
Another practice for optimizing your user’s front end experience is to cache and consolidate your resources. Consolidation can consist of compression (such as GZip) for files and also image compression. Of course, with image resources there is always the fear of a quality trade-off with compression, but when done correctly images typically still have room for at least a bit of optimization with little to no loss in quality. If your site is image heavy, I recommend looking into image compression and load optimization – it can seem scary, especially on a portfolio site where quality is key – but the results can pay off in happier users. This is definitely something I myself need to get more comfortable with learning about and utilizing, especially as I build out my own portfolio projects and such – and so I’ll challenge you to it also.
If you’re still unsure about using compression on your images, you can at least dip your toe in the waters by ensuring you’re using the correct file types for your images. PNGs (portable network graphic) are almost always the most optimized file type for web and mobile use. GIFs (graphic interchange format) are typically best for very small images (think a Wingding style icon, at about the size of ten to twelve point font), or images containing very little color (typically three or less color points). GIF and PNG both support transparency in modern browsers (degradation for transparency can get spotty especially for PNGs in older versions of Internet Explorer. If you’re having issues in IE 7 or 8, the fix can be as simple as saving your PNGs as “Indexed” rather than “RGB” mode). GIF provides support for animation frames – meaning if you require animation in your image and cannot or do not wish to achieve the animation effect with several images and CSS (this can definitely be cumbersome), GIF is the ideal format. JPG (Joint Photographic Experts Group) is ideal for all photographic quality images. BMP (Bitmap Image File) and TIFF (Tagged Image File Format) are not ideally suited for use in web applications any longer.
Another key facet of front end optimization is ensuring you as a developer do everything in your power to combat device limitations for your users. This includes creating adaptively: load resources on user demand and customize images by screen size to ensure the fastest load time – to name a few ways. Practice progressive rendering – loading an image entirely at lower quality and progressively enhancing the image as more power to do so becomes available – helps ensure users with slow graphics cards still get the full experience, even if it starts off a bit fuzzy. JavaScript slowness can be a debilitating issue in slower CPUs; considering this and limiting your necessary JavaScript (of course, don’t betray your functionality needs!) can help every user enjoy your website easily and speedily.
The presenters finished out with a few tools that can be used to measure the performance of front-end and mobile devleopment. Webpagetest.org can be used on internal sites – which is great for entities with a large intranet presence. Pagespeed is a plugin that can be added to your page to test and gather data on load times. Mobitest is optimized for mobile speed testing, and the Chrome Remote Debugger and Safari Web Inspector allow you to plug in an Android or iOS device respectively and test for performance.
Overall a lot of great information here – some of which I was a bit leery of given my own ways and justifications for those, but could see the merit in what the speaker was suggesting and that it was, at the very least, worth considering and potentially implementing aspects of for each project as the struggle between optimizing and “getting it done” rages on. Regardless, there was plenty I learned or at least gained a stronger awareness of, and I’m very glad I attended the workshop to have my eyes opened a little bit wider.
“There are two ways of constructing software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” – C.A.R Hoare