• Web Performance for Product Managers
  • Cliff Crocker
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: flying – yogurt
  • Proofread: PassionPenguin, Chorer, Greycodee

Web performance for product managers

I love talking to others about Web performance, and I’ve been lucky enough to have had quite a few. The audience was varied, mostly front-end developers or engineering leads, but I increasingly felt like I could have an interesting discussion with the product owner. Such wonderful discussions often make me feel like I have a better way to simplify the conversation and express my enthusiasm for introducing product managers to the world of network performance. I hope this article serves that purpose and covers some of the basic areas of network performance that I find most useful in honing product management skills.

So, whether you’re a product manager or not, if you’re not familiar with network performance, I’ve put together some concepts and guidelines for you to get up to speed on. These include:

  • What causes the page to slow down?
  • How is performance measured?
  • What do the different indicators mean?
  • Understand and use percentiles
  • How do you discuss performance issues with different stakeholders?

Let’s get started.

What causes the page to slow down?

Too many things can make the page slow. Here are just a few of the big factors you should be aware of. But keep an eye out for other reasons: performance is as elusive and uncontrollable as a many-headed beast.

request

Your page consists of many static resource files. Images, fonts, JavaScript, CSS, tracking pixels… These all play a role in providing a rich browsing experience. But in general, these resource files can leave you in a painful situation like death by a thousand cuts.

Steve’s golden rule still holds true today: 80% to 90% of rendering time is spent on the front end, with most of that time being spent on web requests. If you want to optimize your site, start by minimizing the number of requests.

code

Front-end developers have a lot of best practices to follow, and this is usually something you put in during the sprint for performance optimization. Recommendations for code optimization can come from a professional review, or from an automated tool like Lighthouse (and SpeedCurve, of course). When analyzing site performance for users, I like to use PageSpeed Insights for some more advanced advice. We’ve built Lighthouse scoring and auditing into our product, which is a great place to start.

Problems may arise from (but are certainly not limited to) :

  • JavaScript
  • Improved “critical path” or render blocking
  • Also, use instructions to preload page elements or asynchronously load scripts

Although most of the time the focus of the product manager is on the front-end developer, if you detect excessively long start rendering times or more abnormal base metrics (such as time to the first byte), keep an eye on the back-end development effort. This is very important.

image

Image optimization is still one of the areas where you can get huge performance gains at minimal cost. With the continuous development of image compression technology, new image formats are introduced into practical application. These formats provide a rich set of features while minimizing the bandwidth required. In some cases, these formats are browser-specific and can lead to increased complexity in the workflow.

Whether or not you have the opportunity to actually work in the field, it’s helpful to understand the image pipeline, whether it’s managed internally or as a service. This is especially true for sites that maintain large product catalogs or contain large amounts of user-generated content.

It’s also important to note that not all of the performance gains will show up in your metrics, but they will be appreciated by bandwidth-poor or data-constrained users. Consider setting an image-related performance budget based on the size and number of requests, rather than the duration of the request.

network

Exactly. The Internet has always been an anomaly. Sending bit after bit from point A to point B via cable ———— I’m still amazed and excited when I think of the complexity involved.

For your part, you might wonder how technology partners can improve the performance of your service, given that you’re paying a lot of money for it. Content delivery networks (CDNS) such as Akamai, Fastly, Cloudflare, and Cloudfront can sometimes have a significant impact on performance. Traditionally, these effects are more pronounced at service back-end time, but can also have a significant impact on the front end when considering some of the distribution of resources (images or other static content) from the server to the Web and some of the advanced optimizations available at the edges. If you don’t pay attention, these platforms will only make things worse, not better.

Third Party services

(a long sigh) We have a love-hate relationship with it. However, we are not averse to using them, and even use them often.

For us, third-party services refer to contributors outside of their domain who exist to enrich content or provide services. The main reason to complain about it is that it is usually beyond your control; When it affects the performance of the service, there is little you can do to speed up the service, you can neither remove the tag nor kill the process.

But as a product manager, you have to live with that. You are the master of influencing things beyond your control. You can hold them accountable and maintain a strategy to keep them on the same page. Such as:

  • Work directly with your supplier manager (if you have one) or the responsible stakeholder to set performance budgets for third-party services. Perhaps you have created a tag budget that can be executed with the responsible party. Budgets can be about size.
  • If your Marketing Department needs to add a new element, another old one must be replaced.
  • Review your third-party services and remove any unused onesscriptThe script.
  • Before introducing new third-party services, perform a review process to ensure that they have passed some basic performance guidelines. My favorite tool is 3rdParty. IO, co-developed by Nic Jansma.

No matter what the cause of the performance problem is, it must be solved in a team spirit. Poor performance is usually not the fault of any one person, and it is rare for a single person or group to have the ability to fix the problem independently of the rest of the team. Performance is a team job.

How is performance measured?

There are two main methods, both of which focus on measuring how browsers respond when users visit your site.

Comprehensive monitoring

It’s not real. In essence, integrated monitoring is more like a robot that can do what you tell it to do (such as visit my home page from X location on the X browser) and actively collect performance data.

Integrated monitoring is great, and it provides a lot of useful things, giving us a lot of detail about what’s going on when we perform that action. Include:

  • Waterfall diagram, which contains detailed information about each request,
  • Slides and videos can help you visualize the rendering experience as well
  • A reasonable and consistent baseline when looking at the composition of an application.

Comprehensive monitoring is great for content that tends to change over time, especially when viewing the number and size of requests (images, JavaScript, CSS). These things have a big impact on speed.

However, for all the benefits of integrated monitoring, it still lacks one critical component: the end user.

Real User Monitoring (RUM)

You’ve guessed it: measure real users. RUM can be viewed as performance-based analysis derived from the actual browser of the end user.

As a great product manager, you’ve focused on building your product from the outside in. You talk to countless customers, take their feedback, and turn it into a need for your next product. The power of empathy can spread throughout your entire team when creating an exciting roadmap and creating a new vision for your product or product line.

That’s why you need RUM. Real users, real experience. RUM is the foundation for understanding Web performance and has become the preferred source of facts when communicating performance with stakeholders. Without RUM, how can you make performance one of your product requirements? I know this is very difficult. However, in this day and age, not taking RUM into account can bring disadvantages to performance evaluation.

What do the different indicators mean?

Whether you use integrated monitoring or RUM, each tool can capture dozens of performance indicators. Over the years, figuring out which performance metrics we should focus on has become a “dangerous” process. Like the pendulum, the trend has shifted from “measure all indicators” to “this is my only indicator”. Today we seek a balance between the two, and the answer to the question, “Which metric should I focus on?” is still a bit of a bummer:

“Adjust measures to local conditions.”

Don’t obsess over details. You don’t need to understand 100 percent of metrics. For most product managers like you (especially those who are new to performance), focus on the metrics that are most relevant to the user experience. This guide from Tammy may help solve this problem.

In recent months, my conversations with product managers have focused on core metrics for the site. If you’re in the field and are under pressure to improve SEO or deal with inbound issues related to the numbers displayed in the Google console, you might want to familiarize yourself with these metrics. Fortunately, you can read a lot of excellent material on the subject. Start with these resources:

  • Track site core metrics
  • Understand cumulative typographical shifts
  • How important is the first input delay?
  • Everything I know about the site’s core metrics by Simon Hearne

Understand and use percentiles

Now that you have an overview of the different metrics, it’s important to take it one step further and learn how to apply percentiles to each metric — so that you can better understand how different groups of real users experience your site.

Here’s a histogram:

The histogram represents the distribution of users with multiple experiences when they visit your site. Keep that in mind.

Performance is a distribution, not just a number. This is not to say that once you measure it, everything is done. The histogram represents the continuity of the experience and allows you to think about the shape of the performance distribution and how you want to affect performance. Moving left speeds it up, moving right slows it down.

I still need a number. What should I do?

Don’t worry, you’ll still be working with numbers. Percentiles represent small fractions of your audience, from 0 to 100. You don’t have to be a statistician to do this, you just have to think like this:

** 50th percentile (median) : ** I find it easier to understand and communicate using the 50th percentile, the median. You can even take it as an average if you want.

** 75th percentile: ** For some popular metrics, such as the website core metric, the 75th percentile is often used in reports.

** 95th percentile: ** If your site is already pretty fast for most users, you can focus on making the experience faster for the few remaining users. Five percent may not sound like much, but if your site has 10 million visitors a month, that means 500,000 of them are really having a bad experience.

Unless you use an arithmetic mean (that is, a mean in the traditional sense) to describe a population, there is no definitive answer to which percentile to focus on (each with its own merits). This is not ideal for this type of distribution.

How do you communicate and discuss performance with different stakeholders?

I find this to be one of the biggest challenges product managers face in measuring performance. We’ve been working on this challenge for years, but we still don’t have the best answer. Here are some ideas about communication you might want to keep in mind.

Know your audience

This is not a new concept. When it comes to cross-functional work, you may have different responsibilities and use multiple languages. Think twice before coming up with new terms and concepts, or giving the CEO too much detail.

Keep it simple

Don’t over-communicate or confuse others. If you focus on performance KPI reporting, great. If you manage to adjust around this unicorn metric, that’s great. Just don’t backfire. I often see product managers lose terms like percentiles or avoid displaying two sets of numbers when trying to communicate their RUM metrics and their composite metrics. Don’t do that. Also, use RUM whenever possible. You can use comprehensive monitoring to highlight some data, such as page weights or element counts, or to state the number of third parties on your site. This is where the RUM data are well supplemented by the comprehensive monitoring data.

Visualize performance

In this area, integrated monitoring tools have a head start. Use slides or videos to discuss performance topics with other participants who are not in-house. There’s nothing like a before and after video to promote great team work.

Benchmark test

Benchmarking is another great tool you have at your disposal. The team wants to win more than lose. Benchmarking to compare yourself to your competitors is very effective. This is especially true when managing your site’s core metrics. If half or so of your competitors are faster than you, how does that affect your search results?

Don’t be afraid to lose face. Whether you or your competitors are at the bottom, that can change at any time. Use benchmarking to improve yourself or learn from others. Check out our industry web speed benchmarking test to learn how to use benchmarking in the toolkit.

conclusion

These are the basics, and I hope you found reading this article worth your time. Just like any topic you touch on as a product manager, you can always push further in this area.

Any other questions or thoughts? I’m sure other readers would like to hear these voices too, so feel free to comment.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.