College fests are irreplaceable delights of a college student’s life. Each college tries to make its fest bigger yet different than others’ and so is case with fest websites. These fest websites stand as expression of creativity of its makers which more often than not leads to a large page load time and poor user experience. While working on websites for Oasis and Apogee at Department of Visual Media, I explored a few techniques to make the sites faster. Here are a few of them. Both graphics designers and front-end developers might find the blog helpful.
This is the most basic yet the most effective step of all. With improved browser rendering engines, SVG files have gained popularity in the web design domain. Being vectors they scale up with screen sizes without any depreciation in quality and they are lightweight. As a bonus they support animations and JavaScript interactions.
But sometimes designs contain textures which cannot be recreated in vectors, in such situations one has to choose between JPEG and PNG? This question does not have a generic answer as JPEG uses lossy data compression unlike PNG and hence is always smaller in size but the lossy compression has it’s own implications. For example, text in JPEG images is blurred out on edges. PNG also supports the use of transparency which makes its use as a necessity at times.
Just choosing the right file format can save up of to 80% payload in images.
Test
Many designers tend to ignore this part which can actually turn out to be very crucial while exporting to raster formats (JPEG and PNG). Typically printers use CMYK colors (32 bit) and hence a lot of design tools export using this format by default. This leads to a problem when rendering on the web as it only supports RGB colors (24 bit) although, a browser would display a CMYK image it cannot reproduce the exact colors. Apart from this, JPEG also supports grayscale colors (8 bit). Progressive and Optimized JPEGs can provide significant reduction in size. As a rule of thumb you might use baseline optimized JPEGs but I strongly suggest going through [1] and [2] .
PNG provides with four color modes of which 24 bit RGB and 8 bit paletted are of interest to us. Typically you would use RGB colors, but if the image does not contain too many colors 8 bit paletted colors might turn out to be better. Converting the image to 8 bit color mode would entail choosing only the best 256 colors, thus drastically decreasing the size of the image. As a word of caution, using paletted color modes can sometimes increase the size of the image when the dimensions of image are small.
[3] is a great read about the tweaks discussed above.
Though file compression is the most obvious step in decreasing page load time, it is still not performed right most of the times. For all your text files HTML, Js, CSS, JSON, etc. “minify” (whitespace removal) is the most popular compression technique available. Though it might appear to be elementary, its aggregate impact could be significant. Most modern text editors like Sublime Text and Atom have plugins for minification. You can also add this to your gulp/grunt build process.
Different image formats have different compression techniques and there exist great open source utilities like JPEGOptim , PNGOUT and SVGO which can decrease the file size by up to 70%. I personally prefer image_optim which combines all these packages, provides a handy shell interface which works for all image formats and integrates easily into build processes. But setting up image_optim on Windows is tricky, if you are on Windows you might want to install those utilities individually or you could alternatively use TinyPNG for rasters and SVGOMG for SVGs.
Most compression techniques in the above mentioned utilities are lossy hence deal with them cautiously.
Browsers can decode gzip encoded responses from a server. gzip does not help much with raster images but manages to compress text files to about one tenth their original size. This provides massive savings with minimum efforts and gzip compression can be easily enabled on both apache and nginx. [4] explains this process in a simple manner.
Fun fact, SVG files are just XML documents because of which gzip works great on them as well. The complete isometric map of the miniature city on the landing page of Apogee 2016 website mentioned earlier is a single ginormous SVG file of about 2 MBs. SVGO compression decreased it to half and ultimately with gzip it is transferred as a payload of only about 200 KBs.
Fonts make websites seem beautiful but they can also make them lethargic. Google Fonts is by and far the best option to load fonts on the web almost all the fonts (or their similar alternatives) are available on Google Fonts. As browsers cache fonts, many a times the Google Fonts font you are trying to load might already be in the user’s cache. Also, we might only need one or two font-weights for a given font which we can choose to load selectively in Google Fonts thus dramatically reducing the size.
If you need a font only for some titles, it might be a good idea to export those as SVGs instead. Though a bit tedious, this leads to big savings as it removes the barrier to your creative ideas.
Loading all the content at once might make the loading times large specially in one page sites. Lazy loading files of less importance might turn out to be useful, Recliner.js is a great tool to achieve the same.
Decreasing the number of HTTP requests can make your page load significantly faster. [5] describes different ways you can achieve the same. Apart from the ones described above, SVG sprites are useful in decreasing number of requests. svg-sprite is a useful tool for making SVG sprites.
HTTP/2 would completely change this landscape though, you can read more about it in [6].
Caching the less frequently changed files makes pages load super-fast for returning users. [7] walks through enabling caching in apache, for nginx you might want to refer [8].
I hope that this posts helps in making your sites faster. If you have any suggestions please let me know in the comments below and I will surely take them into consideration next time! :-) Thank you!