Front-end performance: Driving the discussion and nailing it!

“I want my site to load in 2 seconds… at the max!!!” – Quite often this comes as a requirement from the client, and very often our response is close to one of the two statements below:

1.    Absolutely. We have already delivered it for ABC client in XYZ geo and apparently the requirements seem to be very similar to that of yours.

2.    Seems difficult… the targeted page-speed looks aggressive. In the recent past, we delivered quite of few projects of similar complexities, and the average speed has been 3.5 seconds.

Hold on to this thought for now and we’ll rephrase the response a little later in the post; but for now, let’s understand what are we trying to achieve. Our primary objective is to help our clients succeed, but educating them is also an integral part of our job. We need to do our job in a diligent manner to ensure that he really understands what he’s asking for.

First-thing-first i.e. feasibility check

Instead of committing the client without enough due-diligence, it would be nicer to understand the contributing factors in a detailed manner, which would help in delivering the targeted speed.

To check the feasibility, ideally, the first logical step is to take the ‘expected number’ (in our case, say 2 seconds) and start identifying the individual components contributing to the total page load time.

Preferably the first segregation is:

1.    Components which are NOT in our scope/control

2.    Components which are in our scope/control

Elaborating on point #1, we should start listing down those components which are not in our control, along with their individual load-time. Even better, if we categorize them based of whether they load in sequential-manner or they load in-parallel… eventually their impact on the timeline.

A couple of examples of these 3rd party component:

• Social media APIs for loading content (Facebook / Instagram / Twitter)
• Ads APIs (Google Ads / Facebook Ads)

What did we achieve?

The outcome of this exercise:

• A realistic number on the timeline
• which is NOT in our control
• and which is going to STAY

So, subtract this number (assume 0.5 second) from overall target and you get your revised goal as 1.5 seconds.

With a more specific number in hand, let us revisit the requirement, and try to make it quantifiable. So, let us rewrite the requirement on client’s behalf.

I want homepage of my site to become interactive in max 2 seconds, running on Mobile-4G (5 to 12Mbps) or Cable (5Mbps) and would be accessed by 10,000 concurrent users. 0.5 second is already blocked by other resources, so practically all you have is 1.5 seconds.

It can be clearly be seen that most CRITICAL elements from the requirements were actually neglected. Run it by your team, and the immediate (and obvious) response from a UI developer/architect could be ‘it is not feasible!’ – but can there be a different response? I believe… Yes.

What next?

Appreciating the client requirement, we are in a much better situation to start creating the performance budget. This takes us to point #2 where we start looking into each component of development, which is in our scope, and plan it right from the beginning. Performance has to be thought through right from the beginning, as it is not something that can be achieved by adding further 20% on the top of existing development efforts.

It could be a 2-step approach:

1.    Negotiation with the client for ‘favorable’ environment and ‘supportive’ dependencies

2.    Staying positive and applying all we know to achieve the targeted number

Step 1: Nobody likes people with a negative mindset, talking only about the problem and not the solution. So, merely illustrating the problems clearly doesn’t help, you may also need to present the viable options on the table. Negotiation with the client could look something like this –

This looks achievable, but we need the following dependencies to be met:

• The number of high-resolution images can be maximum 2, with a max size of say, 380KB each
• Icons can be provided in SVGs, rather than picking from a font-file where 80% remains unused
• Instead of using custom fonts, we may go for ‘font-family’ of native fonts with fallback options
• Styling for form-components can be avoided
• Instead of embedding the videos inside the page, ‘click’ can take the user to CDN etc.
• If there are some 3rd party libraries that are business-critical, we can look at ways to load them in a way which do not hinder the page loading.
• Targeting modern browsers (like Chrome, Firefox and MS Edge) should cover ~80% of targeted users, so legacy browsers can be covered separately (or outside 2-second commitment)

And, if the client has some business-reasons for not obliging to above constraints, it can be negotiated that first-time page-load might take longer, but subsequent page-load would be as per the requirements.

Step 2: Apply whatever you have learned so far:

• [Not including oft-quoted golden rules of GZip, minify, script-at-bottom, CSS-at-top etc.]
• Be very choosy with readymade frameworks and libraries, pick wisely and assemble as needed
• Use latest in CSS, like native CSS-Grid and/or flexbox
• Export images in WebP format, replacing the time-consuming JPGs, PNGs, and GIFFs
• User SVG sprites to reduce multiple HTTP requests
• Strip-off the page from the CSS/JS not need on that specific page
• Use native lazy-loading (supported by Chrome) and leave custom scripting as fallback option
• Apply rel=preconnect, helping browser to connect with other domains faster
• Apply rel=preload, requesting resources without hindering the existing body/windows onload events.
• Apply rel=prefetch, identifying resources which might get loaded next
• Plan service-workers and caching wisely wherever feasible
• Last, but not the least, use UnCSS at the build time to ensure no unwanted CSS gets into production

Summing up

Performance optimization is one of the most discussed topics, primarily because it has a direct impact on revenue. A study in 2017 at Akamai revealed that delay of every 100ms could lead to a 7% decline in conversion. There’s no one silver bullet to solve all performance issues, but at the same time, there’s enough data available at our disposal. The need of the hour is: to understand the reasoning behind the business-requirements; know our weapons well; be cognizant of all the dependencies and convey it clearly; and give-it-all to achieve the common goal.