Patrick Pfeifer Software Engineer

How to Build a Website (3/3): Packaging with Webpack

Jul 20, 2017 7:36:13 PM

With content and dependency management out of the way, now let us look at how to glue all those pieces together.

Serving a static website is a problem that has been solved. There are plenty of powerful products available for this task. The Apache web server being one of the most reliable and widely known among them. But in the end it does not matter much how and where the assets are hosted. You can put them on into a publicly accessible S3 bucket or use any other HTTP-enabled object store that you come across. However, requiring the browser to download 50+ resources from the web just to display a static page, sounds like an awful waste of time (page-loading time) and resources (cpu-cycles spent generating and parsing HTTP headers) to me. There is plenty of room for improvement here.

First up: Since the advent of HTTP/2 there is another very efficient solution to this problem. Check out the apache mod_http2 documentation to find out how to configure your server for “Server Push” if you want to go that route. I have not looked into it yet and will describe another, very well established and capable solution here: Webpack.js. This tool – and its plugin ecosystem – offers every feature one could possibly wish for. And while configuration is not as straightforward (and concise) as it could be, it turns out to be extremely flexible.

One obvious transformation that will greatly reduce the number of assets that need to be transferred to the client, is to concatenate all the CSS and Javascript resources. Besides this, one might also want to “clean up” all the code that makes up the website before publishing it. After all, the source is intended to be processed by a browser, which does not care about the formatting and will also ignore any comment blocks. Note that some are clearly opposing to this point of view, providing good arguments. After considering it, I have not put up a banner at the top of my project’s index.html file, which contains a link to the source code repository. Another possibility, that I have not considered here, would be to compress assets on the HTTP level. On the other hand, a website owner, who, for whatever reason, does not want to disclose the technological foundations and/or inner workings of their page, might even want to go further on this and not only (syntactically) compress, but also obfuscate their code.

All that said, now let’s see how Webpack.js can be employed to gather all website assets and concatenate, compress and/or otherwise transform them.

As mentioned in the previous posts, the website that I created, including all of its 3rd party dependencies, consists of a myriad of HTML, CSS, and Javascript, image and font resources. All in all there are certainly around 100+ of them. And what Webpack.js shall do, is to take all these resources as input, and produce one HTML, one CSS and one JS file as output. This way, the browser will need to make much less requests to the server to display the page, which will bring down the load time and hence improve the user-experience, especially for mobile clients.

The files shall be written to a “target” folder, that can be used as the <DocumentRoot> folder in an Apache <VirtualHost> configuration section. This means, that while the links between resources can be absolute (i.e. paths starting with a slash “/”), all resources that are not processed in some special way, shall be copied verbatim from the source into the output folder. This ensures that the web server is not exposing any source code or build configuration files on the public website address. And it greatly simplifies the deployment onto your web hosting platform of choice.

Have a look at how I have set things up here.

I hope you enjoyed the reading. Any comment, thoughts and suggestions are most welcome.