This week's focus was mainly on getting the blog to comply with PageSpeed Insights's recommandation, and globally getting a finer understanding on best practices for serving this blog to you with my small VPS.
It so appears that compressing assets is of utmost importance, and while I already knew that through my previous experiences using gulp and other JS-based compilation tools, I also assumed nothing similar existed in the PHP world. I have been using a Ghost blog previously, and making both Ghost and Wordpress themes for my previous blogs using npm tools. I've also done some SPAs for my work, which of course were sites running entirely on the client side with little to no server interaction. That plus the whole trend of using JS everywhere lead me to think you couldn't do it in two clicks in PHP.
Oh boy I was wrong.
- removing blanks, using shorter variable names, etc… compressing what can be compressed make your assets load faster. That's the naive solution to speed up your website.
- merging files when it makes sense, so that the client doesn't have to spawn a new HTTP connection (or new stream in HTTP/2, even if that's less costly) for each file but one.
- versioning files to bypass cache when a new set of files are generated.
But often, these are done in JS, or are left aside, like that of async loading of assets in the right order for optimal page load.
It does everything at once! Thanks to its Twig support, it's as easy as putting the following snippet in your your Grav site:
And at the end you get two ordered asset files (picture depicts a different version with synchronized JS assets):
- usually, that means more files to send to the client (unpractical in unreliable/+slow mobile network settings)
- at best, that means the device will have to compute more (slowing even more light devices as phones)
Well, no. And it’s worse, because at least before, we were screwing up small things with JS, it was a toy. The thing is, there is a mass psychosis about JS and it’s like everybody is pretending that it isn’t awful. And then, as if this wasn’t bad enough, someone had the brilliant idea of putting this thing in the backend. Nodejs is costing millions per year to naive companies who are adopting it. You were wondering who they are: they are startups and small companies.
Mind you, these engineers are smart, but they’re weak against crowd thinking.
At my new company, everyone was pretending that JS was alright. I got tired and spoke up. Turns out, deep down they all hated JS, it was just crowd thinking. Now they all hate JS. And we’re waiting impatiently for Web Assembly.
It just has too many faults and a litteral monopoly on browser runtime to be left excused with that.
While I still haven't chosen a transpiler to start with, I have come accross one I like in its own setting.
- A new language: WebAssembly code defines an AST (Abstract Syntax Tree) represented in a binary format. You can author and debug in a text format so it’s readable.
- A Compile Target: A way for other languages to get first-class binary support across the entire web platform stack.
Oh my, I diverged again from the initial subject, right?