Tech Talk: "How we optimize our Front End" mit Jürgen Ratzenböck von jobs.at

Tech Talk: "How we optimize our Front End" mit Jürgen Ratzenböck von jobs.at

Alright, welcome to this TechTalk today! Today’s topic will be „How we build our frontend to optimize website performance“ at jobs.at

Today I want to show you a few tweaks we did, to tune our website. My name is Jürgen Ratzenböck, I’m the Head of Technology at jobs.at and in my daily work I deal with a lot of back end and front end web development. Technology-wise I work a lot with PHP stuff and especially the Laravel framework. On the front end side, we heavily deal with Vue.js for our single page application products. So you can find me on the social networks, if you have any questions regarding this talk or you want to know more about jobs.at, just hit me up, write a line at one of the contact opportunities.

What is jobs.at? jobs.at is small team based in Linz and we build a fast and easy to use job platform. We have a big inventory of jobs, spread across all industries among all the municipalities in Austria. Currently we have about 58.000 active jobs – which is quite a lot – and also 830k+ sessions per month.

That’s about jobs.at, so I would say let’s dive right into the topic of web performance and why it is important for us. As you know, the tolerable waiting time on the web has decreased dramatically over the last years. We use cellphones, tablets and other devices every day and we are online nearly everywhere, so people are likely to bounce very fast if a website is slow. To have a good user-engagement, the website needs to be fast, so the people stay on your site. If they stay there and they have a good experience they are also likely to come back. In the end this also yields higher conversion rates for you for instance in your onlineshop.

Secondly – which is also very important for us – is Google. Search engine optimization depends a lot on web performance, we don’t know all the details how Google ranks the sites, but they clearly state that fast websites are important for them. To have a good ranking, you need to take care of this. I also included three quotes of quite popular and successful companies, which once more highlight that web performance is important for a business and that you should take an eye on it.

So, the question is: when can I consider my website to be fast? There are multiple answers possible, actually a lot of different metrics exist among this cycle of requests to the response. There are metrics like the Time to First Byte, which indicates whether your server or back end works good. There are things like the onLoad event or the DOMContentLoaded, which give you a feeling for when the rendering part is done. But lately – or over the last few years – Google introduced a few new things. They are the so called user-centric performance metrics. They are geared more towards how the user actually perceives the loading time of the website. These are things like the first contentful paint, for instance, which indicates the time when the user first sees relevant things rendered in the browser, or when the website becomes interactive. Very lately, they tried to simplify all those metrics into three so called „Core Web Vitals“, which they put more emphasis on right now. They actually announced that they will start in June now to make this impacting the search rank – this will become more important, it actually goes beyond the scope of performance. Right now it focuses on the loading time, the visual stability of the website and the interactivity. So this is definitely something that you should keep in mind when tuning or evaluating your website.

Now that we are ready for evaluation, there are different tools – I think most of the web developers know them. There is PageSpeed Insights, which is around for years now. There is also Google Lighthouse which gives you even more details on how compliant you are with SEO best practices or progressive web app and things like this. A tool that I really like is webpagetest.org, because it gives you very detailed insights with a waterfall diagram, where you can really look into every request so you know how long the TCP handshake takes or dns-resolution and so on. So, these tools are really great and they give you a lot of hints on where you are and what you can do.

What you can do is the next part – I picked a few things that we did over the last few weeks and months and want to show you how you can leverage those to tune your website.

First of all, one thing which I think is quite underestimated but very powerful are Resource hints. Typically, when the browser hits a resource, it gets downloaded and it gets executed like a JavaScript, for instance. With those Resource hints, you can tell the browser „hey, please do something else with this resource.“ There are different opportunities, the first one – the most lightweight one – is called dns-prefetch. You can tell for some resources, that the dns-resolution should take place earlier and this runs in the background basically. The browser then can continue with the execution and when the resource is ready, the dns-resolution has already taken place, so it’s much faster. Similar is preconnect, but it goes one step further – it also does the TCP handshake and the TLS negotiation.

Yeah, these two things are recommended especially for third-party tools or where you build your resource URLs dynamically, so you can already do some of the work upfront. For this it’s quite nice to optimize there. Then there is also prefetch and prerender. Prefetch is especially for navigation, so when you can anticipate how the user interacts with your page, so when you know he’s on page A, he will very likely go to page B, you can already prefetch some resources and store them and when the user navigates, it’s nearly instantly there. Which is quite cool. Prerender renders the whole page, so it not only downloads the things and stores them in the browser, but it also executes everything.

You have to be cautious however, because obviously this uses a lot of browser resources and these should not be wasted, because it takes bandwidth – especially for prefetch and prerender you should really know where the user goes, otherwise it doesn’t make that much sense and it can even have a negative impact. All in all, those are quick wins in my opinion, because it’s just this one rel-attribute and then it’s done. One more thing is the preload, which is actually not really a resource hint, but also a thing which is similar to prefetch, but on the current page. You can use it for fonts, for instance when you know „okay these will be used in a css file“, then you can already preload them to have them faster available.

The next thing – I think it’s already de facto standard nowadays, but it’s still quite important – is to have your JavaScript and CSS minified in production, because bundle-size is also critical. The files should not be too large and there is a lot you can gain. The cool thing is that with nowadays’ module bundlers like webpack or rollup.js or – like you can see here – we have this Laravel Mix, which is just a wrap around webpack. You can do this with one or two lines to get your JavaScript bundled and automatically out of the box, minified in production.

One thing which is quite common when you run your website in PageSpeed Insights for instance is render-blocking resources. JavaScript and CSS are render-blocking, so this means the browser has to halt the rendering and executes the JavaScript. Of course, sometimes this is necessary, but especially if you just see the above default content, which is the first thing the user sees, there is a lot of JavaScript which does not need to be executed right away. So, very important to defer them and load it asynchronously. It is also quite easy to do with just this defer-attribute, so then the browser knows „okay, I will download it“, but the execution takes place after the DOM is fully built and then the rendering is not halted or interrupted. The same applies for CSS: we load all the critical CSS at first – you could also inline it, we don’t do this at the moment, but this would may be an option, because then you don’t even have to download the file – then there are open source libraries to load everything else asynchronously. But of course you have to pay attention to this Flash of Unstyled Content – as it is called –, so that you really immediately load all the CSS which is necessary to not have this blank page and then it turns into the thing it should actually look like.

Alright, then there are CSS frameworks, like Tailwind or Bootstrap – a lot of websites use them. They come with a lot of styles and actually just a tiny portion is used. Quite lately we saw in Lighthouse that we have quite some bad coverage for some of our pages and so we use this nice tool PurgeCSS, which automatically in your build matches the things, the CSS classes you use in your template with the CSS file and then it automatically gets rid of everything which is not needed on this page. Very easy to set up with Webpack for instance – I’m also sure it’s easy with other bundlers. It really shrinks your CSS files. But we ran into two gotchas as well. You have to take care when you load additional HTML-content via Ajax, because then PurgeCSS does not know about those classes and they might have been removed already. Then you have things that look unstyled. The same applies to single page applications. If you use Vue.js, you can use conditional rendering, you also have to be careful that not the things you still need to use at runtime get deleted by PurgeCSS.

Alright, last but not least, one more thing I want to talk about is code splitting. Before, I also thought that it’s best to have everything in one JavaScript file, because that’s just that one file downloaded by the browser. This is fine, maybe have one vendor JavaScript file, where you get bundled all the third-party things. But actually, it’s much better – especially if your JavaScript grows – to split this into chunks and only load those chunks which are really required on this particular page. There are multiple opportunities how you can do this. On the server side for instance, we have this asset manager, which we implemented on our own which then includes the JavaScript tag, based on the HTTP controller we currently execute. So we have one JS file per route. But also there are other possabilites, with Webpack for instance you can do the splitting with the Split-Chunks plugin. Or in Vue.js if you have client-side routing, then you can also dynamically import modules with this ES6 syntax and then for instance this customer login component you can see here is only really loaded when the user navigates to this page. This is also quite easy to do and very powerful. For shared bundles, you also have to take care that they are not duplicated, because with all those module imports it can happen that they are twice included. So you should take care of this as well.

Alright, to sum it up:

  • Having a fast website is definitely something which is important.
  • For evaluation, use the tools – they are really great and it absolutely makes sense to know where you are before you do anything.
  • It’s also not rocket science to tune the web performance. I know there are a lot of things you can do, but especially PageSpeed Insights and Lighthouse give you very good hints and they are also great resources.
  • One more thing is definitely that web performance optimization is not only a one-time task, it’s much more a process. Because with every feature you implement and roll out, you could have an impact on web performance. That’s also something we currently work on – to really have automated processes, which are integrated in our continuous integration to tell us „hey, there is something which does not look that good anymore“. Definitely something you always have to be up to date on.

The obligatory slide at then end – it’s a quite exciting time at jobs.at. We expand our team and we’re also actively looking for new developers, so if you are a motivated front end or back end or even a full stack developer, just go to our webpage and I am looking forward to getting new colleagues and building great products at jobs.at

That’s it, thank you!