Providing fast site operation as part of the development pipeline

Website performance is not only about how to make website pages load faster. It is also necessary to convey the importance of effective web resources to developers and other project participants. Performance is the same part of the functionality as everything else, so its implementation cannot be postponed to “someday”.



The topic of performance interests me for a long time. I remember it all started with an introduction to the "greedy" algorithms and algorithms such as "divide and conquer." There was something particularly pleasant about taking a code that took a few minutes to execute, redo it and get it done in a couple of seconds.

If we talk about networks, the performance problems here are different: usually it is not a matter of computational complexity, but of taking the right actions at the right time in the best possible way. At first glance, this task may seem elementary, but in fact it is much more difficult.

Transferred to Alconost

Steve Souders was one of the first to become interested in analyzing how browsers request web resources and expect an answer: what resources are blocking work, what can be postponed, what happens to the response headers? According to the results of his research, he compiled a list of 14 quick loading rules for a website . For example, here are the performance rules applied in the YSlow tool (you may already be familiar with it) .


14 rules of Steve Suders ( source )

Today, there are more and more new tools for monitoring performance: some need to be run separately, others are built into the pipeline of development and deployment. One of them is Google's Lighthouse : it displays data on PWA (progressive web application) indicators, SEO, etc.


Screenshot of Lighthouse 3.0 shown at Google I / O 2018 conference ( source )

Such tools help to decide on what to pay special attention when finalizing the site - and at the same time they implement many concepts, among which it is not so easy to understand: PRPL, RAIL, Paint Timing API, TTI, HTTP / 2, Speed ​​Index, Priority Hints and others ...

Why performance stays offscreen

The issue of responsiveness of websites is a serious problem in various companies. We have excellent tools and clear guides, but few people take the time to increase productivity. That is, the point is not that we do not know why sites are loading for so long.

Therefore, I am not trying to explain why effective web site operation is important.

This is much better told by other resources, and with real figures on real projects. I want to talk about the culture of development and how it defines priorities . Only by taking performance as another “function” of the project, we learn to pay attention to it.

If you are reading this, then you are most likely a developer, you are trying to keep abreast of new Internet technologies and you are not indifferent to performance. If you ask where you work and what you do, it may turn out that you are from the development department of a company, and one of your tasks is to ensure productivity. But most likely, the same cannot be said about the rest of the employees of the department and the company as a whole - unless, of course, you work independently. And this is normal: it is impossible to know everything about everything.

When solving everyday tasks, you have to work in a variety of technical areas: develop new functions, interact with other departments (add scripts for analytics, advertising, remarketing, A / B testing), organize continuous integration and delivery (CI / CD), ensure security, create a nice looking and easy-to-use interface. But you still need to cover the rear tests!

It is often almost impossible to pay attention to something else: time is limited, and the amount of outstanding work tends only to grow. Therefore it is necessary to set priorities.



Prioritization should be objectively based on a measurable hypothesis. For example: “We believe that with the introduction of the X function, the retention of users will increase by Y%” - however, in practice it looks much more complicated. Take a look at the tasks that have to be addressed, and pay attention to who puts them:

• The implementation of functions . Usually, the owner or product manager sets new tasks according to his vision and team goals. A request for a function may come from those who depend on our work (for example, adding a third-party tracking script or A / B testing ).
  
• Organization CI / CD . Developers can create their own pipelines for assembly and deployment, but most likely they will use the infrastructure prepared by others (for example, the infrastructure department).
  
• Security Well, if there is a department in the project (or at least one person) specializing in security, which helps to check the structure of the system, the implementation of functions, it sends us safety reports and informs about corrections.
  
• User interface Typically, a project has a designer and / or user interaction specialist who is responsible for appearance, usability, and information architecture.
  
• Testing Where are we without tests, right?
  

If someone is responsible for performing a task, it will most likely be found on the task board. Most of the tasks relate to specific roles of the workflow, but there are some that are tacitly entrusted to developers — for example, testing: the development department as a whole is responsible for it, and therefore some components end up testing better than others.

Perhaps no one will argue that automated testing is useful. Usually the development department decides for itself how extensively to cover the code with tests - it is important that all the developers in the team are able to write tests. The situation is similar with performance issues: it is usually assumed that developers should deal with this. I noticed that writing tests for code and, at the same time, understanding the consequences that a single fragment will cause to work incorrectly is easier than taking into account all the elements that can slow down a web resource .

Six stages of introducing ideas about the importance of web resource performance

We have tools for performance analysis, but their use depends on the developers themselves. How to introduce in the company the idea that performance must be perceived as one of the functions?

I made a list of six items, which should help in this matter.

1. Development Environment User Environment

Easy work , shot by Emil Perron

I use MacBook Pro to develop websites. As a phone, I have an iPhone X, and there is a separate test device. In addition, I have a very fast internet connection, and I am sitting not far from the data centers in Stockholm and London. After work, I go to the subway, where there is 4G (and no gaps). Generally speaking, it was in Stockholm that 4G first appeared - back in 2009 .

At users such smart conditions I will hardly (with rare exception).

If we ourselves have no problems with performance - how to prioritize the optimization problem? It's like trying to implement an interface for people with disabilities, without using keyboard controls, screen readers, or checking for contrasting colors — that is, a bad job.

And we don’t have to wait for changes here: Western web developers like to choose the latest from laptops and other devices. The same can be said for almost everyone who is responsible for setting goals for the project and the company. In addition, in some cases, we focus on the upper segment of devices - because they are used by those who are more likely to be ready to pay for our product. Bruce Lawson said on this occasion that we should build “a worldwide network, not a network for the rich West.”

Think about what is better: attract more users, even if they are less solvent , or less, but more solvent?

Interestingly, without taking into account the work of users on real devices, we end up making false assumptions . Suppose we decided to facilitate development and abandon platforms on which statistics have fewer users or lower usage (for example, fewer page views per session). It makes no sense to support the old browser, which almost no one uses . And one could say that this decision is based on solid data.

But let's not hurry. But what if low indicators on some platform are due to the fact that our product is inconvenient or inefficient on it? It is difficult to prove such a hypothesis, because the developers will say that everything is fine with them - on their computers and in a specific browser (suppose it will be Google Chrome). We unwittingly pay more attention to the browser we use, and as a result we often compromise in favor of a more modern working environment. Oh, I hear a cry of pain from the other side of the monitor: “Are they still using this browser? Let them update! ”

Recently, I came across a quote that I really liked:

“When I was working on Google, someone told me a story about how they completed some great optimization, and suddenly it turned out that the page load time only increased. Having gone deep into the data, they discovered the reason: after optimization, much more traffic came from Africa. Previously, it was impossible to use the product with a slow Internet, and after optimization this became possible, and a huge number of users with poor connectivity appeared, which increased the average download time. ”
- Dan Lou, Swollen Internet

I repeat: it is easy to simulate productivity growth by eliminating users who give poor performance and spoil statistics. But this is not optimization, but only a game with numbers .

Take it and distribute the old devices to the colleagues working on the project. Model poor connection conditions, slow processors - and adapt your product to this. Find out which devices the users have, and giving priority to the devices from which they actually access your site, be especially vigilant.

2. It is better to learn the basics of technology, rather than specific libraries.

Until now, many job requirements and job interview questions have focused on libraries, not on the underlying technologies. Although it would be more correct to ask: “What happens when the browser tries to load the website? What are the reasons why the site may load too long? How would you organize a web project architecture of non-trivial size (client, server, database, caching)? ”

A developer who knows the answers to such questions will intelligently select the npm library for the project. Discussing the functionality with the designers and the customer, he will be able to express a special look at the development. Such a developer will take into account the APIs of both new and old browsers and try to take advantage of the “inconvenient” platform, and not isolate it.

Perhaps, as a result, the department will need to hire a specialist who knows React or Vue, and immediately put him into operation and move the project further. And at the same time, it would be good for new employees to stay longer in the company, question existing technical solutions and offer better options.

There are two constants that do not change, wherever I use my skills as a developer:

1. It is necessary to cast doubt on the decisions of your own company, otherwise a competitor will do it and will come forward. Stimulate feedback from project participants and allow them time to develop innovative prototypes and pilot versions.
   
2. Technical decisions made today will not last long. Rely on modularity, the ability to remove components and fast delivery.
   

If you agree with the above, you are open to the ideas of people who are not committed to a particular technology and can justify the advantages and disadvantages of various technical solutions.

Participate in interviews. Suggest allocating time at which employees can learn something (for example, you can regularly hold small presentations at lunch) and explore ideas that can benefit projects.

3. Take time to experiment and test.

Previously, I sent colleagues links to speeches at conferences like Google I / O and articles that tell about all sorts of new products. It seemed to me to be aware of the latest events is useful to me and them.

Thoughtlessly sharing links that are interesting to you, you often only burden your colleagues even more: they have to not only do their job, but also read them sent by you. It is supposed to learn better in practice, so it will seem to them that they should try to apply this new library, technique, idea, etc.

Do them a favor - apply a novelty in the project yourself. “The new browser API looks cool” - the wrong approach to evaluation. It is better to reason like this: “If you use X like this, our project will be better .” The second is certainly more difficult, but the return in this case is higher - and it will be much easier to convince the boss.

There are many case studies online about how performance optimization improves key performance indicators. A good source of articles about this is, for example, WPO Stats .


Many case studies in which increased productivity has led to improved key performance indicators.

Sometimes, in order to force a company to pay more attention to the speed of a web project, it’s not enough just to do some practical research as evidence.

Need a prototype. But it may seem that there is no time for its creation and never will be: everything goes to correcting errors and adding new functions.

In my opinion, every function should go through three stages:



The idea may come from the owner or manager of the product, but it may come from the developer . It is necessary to test it and show that it works - for this you need a prototype. Only after this function will be implemented. In addition, this means that before the implementation of the idea must be tested in some form. It will be necessary to prove that improving site performance improves performance - but this also applies to other functions.

When looking for something that can be accelerated, choose something that users can sense. In order for users to notice the difference in a reasonable amount of time, the site’s speed should increase by at least 20% , and better by 30% .

4. Educate colleagues

Have you ever had such that some piece of code had to be removed or replaced, because no one understood how it works? Perhaps this one has not passed the cup. If the code is understood and supported only by its author, what happens if this person goes on vacation, gets sick, leaves the company? ..


We take advantage of the absence of John - get rid of unnecessary complexity.

Most of us work in a team, so when choosing the solutions we need, we need to focus on those that will be understandable to most colleagues. Define the “least common multiple” in a team and try not to use over-complicated solutions just because it’s interesting to mess with them . In optimizing performance, a small increase is sometimes achieved by an excessive increase in complexity.

A couple of months ago, I wrote about image optimization and how to improve apparent loading speed . I started with the obvious: smaller requests, choose the right format, optimize images. However, most people only remember about the use of image-fillers, which allow you to make a smooth transition to the desired image.


Variants of what can be shown before loading the image.

This is the most interesting and innovative part! It's true? Now try to tell your colleagues that you are going to create a backend service that will process the images in the queue and store a small thumbnail that will be embedded in the page when rendering. When will it work? How long will it take? Where to store sketches? How to scale this service on different servers?

It is most effective to avoid the delivery of images and optimize those that still have to be delivered - this is what you should strive for.

In addition to choosing “sufficiently good” solutions that most colleagues understand, one should think about raising the level of knowledge in the department . Are you considered a dock in a specific area? Make a presentation to your colleagues and inspire them with a new idea.

After all, if only you advance some idea, it will not survive for long.

5. Share success stories (and failures)

To change the way of thinking in a company, you will first have to convince your colleagues in the correctness of the new approach. But sharing the results of your experiments is also needed outside your department.

Across the company, this will help inspire other employees and open the way for more ambitious initiatives . And it will be easier to get support for the necessary services and infrastructure if it turns out to be necessary for several departments.

Talking about the work on the performance of the website outside the company, you can attract talented guys to the team and demonstrate customer and user care .

If we talk about the performance of web applications, I especially like the Etsy approach. Here is what happens inside the company:

“The performance department here has a“ honor roll ”on which employees from other departments have contributed to speeding up the site: there you can see a photo of the hero, a vivid graph showing the increase in productivity, and a brief description of the solution.”
- Lara Hogan, “Changing the culture of work in an organization”

Photos of the distinguished employee and a graphic graph of the results of his work with explanations.

Outside the company, they have been talking for years about the difficulties they are facing and how things are at the moment.


Etsy blog site performance reports

Before you start talking about improving performance, it is important to frankly and clearly describe the current state of affairs and indicate which aspect you should work with. One of the best examples here is Vox Media , the company that owns The Verge and other high traffic sites. In May 2015, Vox Media experts wrote about the site’s slowness and that they intend to speed up its work.

“Our main priority then was to roll out the project and refine it later . And often we did not have time to polish and optimize the released version - it was necessary to start the next major project. As a result, we have accumulated quite a large technical debt in terms of performance . ”
- Vox Media, “We declare failure in work on performance” (emphasis added)

SpeedCurve report on several news sites, including The Verge by Vox Media ( source )

Vox Media experts decided to focus on several performance indicators (drawing the first element, the entire page and the speed index) and regularly publish articles about how the work on performance is going.


One of the Vox Media records with information about the work done.

To summarize: do not be afraid to admit (including publicly) that your product is slow. There are sure to be willing to work on this, and your openness will show that you are striving to improve.

6. Performance objectives should be part of the workflow.

It is important to introduce performance checks into the department’s workflow and automate them as much as possible - this will help to more successfully disseminate ideas regarding the effective operation of the website.

To identify performance problems, there are many tools, for example: WebPagetest , Pagespeed Insights , Audits in the Chrome developer tools , etc. With their help, it is convenient to get real-time reports on the speed of the site.


WebPagetest is a very useful performance reporting tool.

But it is better, of course, to automate the creation of reports, without relying on the launch of checks by developers manually.

With the help of a minimally functional prototype, you need to set limits on performance indicators , run daily checks on a working site and set up notifications when these restrictions are not met. This will help to identify problems in a timely manner and to find the probable causes in specific versions possible - and all this is set up easily.

Better yet, run the tests as part of the checks for requests to incorporate changes made to the code. With this approach, the performance when merging branches and deploying a site is almost guaranteed not to decrease. Such testing is called synthetic because it is performed automatically using a script in a predetermined environment (which includes the device, network speed, location, etc.).

You can add synthetic tests with RUM tests that track the interaction of real users with the site. The point is to collect various indicators, such as the load time or the drawing of the first element , and publish it on a service where you can visualize and compare the results.

You can, of course, use general-purpose tools - like Google Analytics with custom events - but I advise you to pay attention to specially designed solutions: for example, Caliber , SpeedCurve or SiteSpeed .

Performance monitoring should be invisible and attract attention only when action needs to be taken.

The necessary tools are mostly distributed for a fee - by subscription. Solutions with open source (for example, SiteSpeed) must be placed on their own equipment, so take into account the time needed to set them up. It is very important to think carefully about how you will offer to add these tools.

Case Study

Some months ago, I suggested using Caliber to monitor site performance. Previously, this would have been another “cool idea,” but this time I still wanted to achieve my goal. Therefore, I did this:

• I tried the product myself. I signed up for a trial version, set up monitoring of our sites with realistic conditions (access points, network speed) and started collecting data.
  
• Presented the decision to colleagues. After making sure that the tool works, I prepared a presentation for them, revealed the problems we had and showed how the proposed solution could improve the situation. I explained in detail how this tool works, and offered to use it for three months, and then decide whether to leave it.
  
• Designed the idea officially. I wrote a proposal that could be given to interested parties for consideration, and included such sections: “Why use something at all”, “Why use Caliber”, “Advantages”, “Disadvantages” and “Work plan”. Specifying for the paid product the period in which the decision on its use will be made is correct: nobody loses wasting money.
  

Why was my suggestion helpful? Because it touched on all six ideas that I mentioned here.

1. The tool checked sites from various access points and with the specified limitations, which differs from the conditions of checking in the office.
   
2. It did not depend on libraries and frameworks. To create a website, you can use anything - and we will take care of the speed of work.
   
3. This solution could be applied in our projects - that is, it was relevant, and not just another reference to a random article.
   
4. Colleagues were informed, knew how to use the tool, and collectively agreed to promote it.
   
5. , , - . , ( ).
   
6. — .
   

Conclusion

, — , . Thanks for attention!

About the translator

The article is translated in Alconost.

Alconost is engaged in the localization of games , applications and sites in 68 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.

We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.

Read more