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.
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.
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, 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