It's time to take a look at this month's webperf rankings of the most visited sites in UK.
Our SaaS solution automatically improves the your website’s loading speed. Our engine works like a proxy in the Cloud, rewriting your page code on the fly to optimise your website’s loading time on desktop and mobile, for all your users, whatever the browsing context. But in practice, apart from improving the speed perceived by your visitors, how can you measure the impact of optimising loading speed on your conversions? In this article, we look in detail at how to test the effects of Fasterize to evaluate the ROI of our solution.
Continue reading How do you measure the impact of Fasterize?
How does onboarding work at Fasterize? How long does the implementation take? Who needs to be involved? In this article, we explain everything you need to know about the steps involved in deploying our SaaS solution, from the audit to the actual acceleration of your site. Follow the guide!
In the history of web performance, “Load Time” was one of the first indicators used to measure the loading times of web pages. Over time, the other KPIs we’ve talked about—Speed Index, Time To Interactive, etc.—made their way onto the scene to assess the perception of speed and Load Time was retired to a dusty old shelf at the back of a storeroom. Let’s look back on this web performance metric that once played an important role, but which is no longer sufficient for assessing the speed of your website, and we’ll see why.
To assess your loading times and improve them, you need to precisely identify your tasks and events that take up the most time for browsers. But how do you know how long it takes a script to execute? Or when the main image on a page displays? What is the processing time for a user action before it executes?
To answer all of these questions, the conventional tools and metrics may only provide limited responses. The answers can be found with custom metrics via the User Timing API.
Jean-Pierre Vincent explains how to use it.
The Time To First Byte (TTFB) expresses, in milliseconds, the time a server takes to respond. It is taken into account by Google and other search engines to assess the speed at which content will be available. So, as you’ve probably understood, it is an important indicator for your loading times, and also one that counts for your SEO.
In the previous part of our article, we explained why the backend counts as much as the frontend to make your site's pages load quickly. But in practice, how do you do it? What should you think about? Should you take care of it internally or outsource these operations? Here are some tips recommended by our web performance experts.
For pages that load quickly, focusing on what appears in the browser by optimizing your frontend seems quite obvious. But do you also pay attention to what’s happening behind the scenes on your servers?
For optimum performance, your backend requires as much attention as your frontend.
Here is some advice about the criteria you should be taking into account so that your infrastructure can hold its own.
One of the essential optimizations for loading speed and interactivity is to defer the loading of JavaScript. Let’s go deeper to understand the impact of a blocking script on loading times, the solutions for minimising the impact, and the pitfalls you want to avoid.
We’ll also take the opportunity to explain the details of the solution we’ve developed: a feature called DeferJS.
