This website uses cookies. By using the website you agree with our use of cookies. Know more


Performance as a feature

By Ricardo Lopes
Ricardo Lopes
Passionate about building fast software, mission accomplished when a response is received before the request is made. Sports lover, playing with Air Jordan.
View All Posts
Performance as a feature
Let’s face it: no one likes a slow website. Nowadays with the enormous speed we can have on our internet connections and having devices with multiples cores and tons of memory we don’t have the patience to wait for a page to load. If a page is taking too long to load we do one of two things: we click refresh again and again and again to see if something happens, or we just move on to another site.

A lot of big players like Google and Amazon have already tested and proved that even a small delay like 100ms can have a big impact in conversion rate and user experience. So the conclusion is that the slower the page loads, the fewer people will visit it and it will have a negative impact on conversion rate - and we don’t want that.

If losing visitors isn’t enough to convince that performance needs to be amongst our main priorities when developing software then there's also the cost of maintaining applications with poor performance. Those applications will need better, and a lot more, servers to be able to run, which means more money spent on infrastructure. Also, applications with poor performance tend to break more often because they can run out of resources quickly or cannot scale if a higher request rate comes in, which leads to downtime of the application.

How we embrace this challenge?

The first thing is to make sure that the teams understand why performance is so important and why it is something that needs to be part of every development. At Farfetch we take performance into consideration in all the decisions we make, and although every project can have its specific challenges, we feel that if every development process takes into account the next points we can ensure that we are delivering quality software with a high level of performance. It isn’t good enough that a certain feature works, it needs to work and to be pretty fast.

Training, teaching and teamwork

In software development, we know that being constantly aware of what is happening in the community is vital. Day after day new techniques, tools, practices, programming languages emerge, and we need to be aware of what is happening so that we could take advantage of that in order to improve our work. Teaching and teamwork are also fundamental, working together will help deliver better quality software. An example of that can be if a team member knows A and another team member knows B, the software they can produce will be AB, if they worked alone the final version would be only A or only B. Besides, at the end of the development, both team members will know AB, so they have acquired new skills which they can also pass on to other team members.


Using a profiling tool can help identify possible points of improvement in an application. It is crucial to know how much memory and CPU is being spent and detect which method is taking more time to complete an identity and why that is happening. Based on these reports we can take action in changing how we are doing things and then compare the two versions to see the improvements.

Pipeline for Performance Tests

Now that our software is already approved by the team and we didn’t detect anything with a profiling tool, it is time to go live, right? Wrong! Every test and evaluation that we made till now was only one person using the application, in live we can have thousands of requests per minute or even more, the tests that we have done until now don’t give us the necessary confidence to know that the application will behave well in a live environment.

So now it’s time to test our application with some traffic, and for that we use a pipeline to run performance tests. Since the majority of our applications are APIs REST we use JMeter for our tests. This process is all automatic, and what happens is:
  • The application is installed in a controlled server environment.
  • Test data is inserted into the database if needed.
  • The test cases are loaded to JMeter.
  • The tests are running for an X number of minutes with a Y number of requests per minute.
  • A report is generated and saved to the performance history of the application.
  • The report results are compared to the thresholds defined for the application.
  • The pipeline fails/passes if the results exceed the threshold or not.
So is this worth it? The short answer is YES! I have lost count of the number of times a performance problem was detected in this step and corrected before going live, or at the very least the team was aware of the cost of a new feature.


Although we might catch performance problems in the pipeline, only when we go live we really know how our application is used. One thing we can be sure, although we can have the use cases on how our application should be used, what will happen in live is that our application will be used in certain ways that we didn't even think of. That is why having a good live monitoring and a system that raises alarms. By monitoring live a team can detect that certain calls take longer than other calls to complete, create test cases for those calls, investigate why that behaviour is happening and correct it.

All the points described above are used at Farfetch, and we are getting amazing results compared with how things were done in the past. There are other things that can help a team to better test and evaluate the performance of the application, but this post is more focused on what a team can do by being completely autonomous, without depending on other departments. Maybe in another post we can discuss other things that can be achieved when we have all departments working together.

In summary, we see performance as a feature at Farfetch. Having a high performant software is a mindset. You wouldn’t go live with a feature that doesn’t work, that wasn’t tested, or that doesn’t meet the requirements, because you don’t want to have a negative impact on user experience, then why would you go live with a feature that has a terrible performance?

Remember that now more than ever, customers want things and want them fast. So having the mindset of checking and improving the application performance can have a very good impact on your business as your users will be happier and you will also save more money on infrastructure because you can do more with less.
Related Articles