Frontend Performance Optimization

The biggest piece of content was the heavy product image, and after the first round of optimization, its load time increased because we load all the images after the page wireframe has loaded. It was decided to separate the first image and send it along with the HTML code generated on the server. And after the browser sees the big picture, the rest of the product gallery is drawn to it. Laravel is used as the backend of the site on the server. The result of this optimization pleased: 55 GPS points.

It would seem that the problem is solved: we managed to do the impossible and combine the impressive functionality of the site with the high speed of its loading. But this result in practice cannot be evaluated anywhere except for good GPS indicators: the visitor of the resource still sees the same staged loading. So maybe it was worth not chasing abstract points, but paying attention to the real needs of users?

In addition, now the marketing department has removed a large banner from the site, and the script for accepting cookies turned out to be the heaviest element. This means that the goal has not yet been achieved and further optimization measures need to be taken.

How to kill web performance in an attempt to optimize it

We always want to get both speed and functionality at the same time, but such a requirement contains an internal contradiction. If you want a race car, we remove everything we can to make it as light as possible. There is only room for one pilot and the most necessary structural details. If you need a roomy truck, then you need a large body and a powerful engine. However, the speed of such a car will be an order of magnitude lower than that of a racing car.

Let's see what happens when management demands to combine speed and functionality, using the optimization of the vprok.ru site as an example.

To analyze the effectiveness of optimization, the generally accepted Google PageSpeed ​​(GPS) parameter was used; A score of at least 50 points is considered satisfactory.

First, it was necessary to determine which elements on the page are the heaviest. They turned out to be pictures of goods, and it was decided to make them loadable via AJAX requests. But as a result, the size of the JS scripts that provide these postloaders has grown.

A detailed study of Google's algorithms for determining site speed showed that there are two fundamental metrics: First Contentful Paint (FCP; rendering time for the first content-significant element) and Largest Contentful Paint (LCP; rendering time for the largest content element).