{"id":199,"date":"2015-04-15T18:30:54","date_gmt":"2015-04-16T00:30:54","guid":{"rendered":"http:\/\/www.managerjs.com\/blog\/?p=199"},"modified":"2015-04-16T17:30:29","modified_gmt":"2015-04-16T23:30:29","slug":"managerjs-web-performance-grades","status":"publish","type":"post","link":"https:\/\/www.managerjs.com\/blog\/2015\/04\/managerjs-web-performance-grades\/","title":{"rendered":"Talkin’ ‘Bout Your Web Perf"},"content":{"rendered":"

I’ve had a lot of luck using this article to push performance conversations further.\u00a0The numbers are dated but the concepts are real.<\/p>\n

You have to know how good is good enough. How bad is too bad to tolerate. You have to separate user interactions by value and user expectations. Here I break down user expectations and give some (lenient) standards that ought to be worth discussing (and keep people from setting their hair on fire).<\/p>\n

Web Sites Don’t Get Special Dispensation<\/h1>\n

The guidelines for latency limits are not new. For example, the advice given in Response Times: 3 Important Limits<\/span><\/a> is over 40 years old, but still generally true.\u00a0 In fact, special guidance to web-site operators only tends to emphasize how more and more impatient our users\u00a0are becoming.\u00a0 Consider these excerpts from a white paper by Gomez entitled Why Web Performance Matters: Is Your Site Driving Customers Away<\/i><\/span><\/a>:<\/span><\/p>\n

\n

The average online shopper expects your pages to load in two seconds or less, down from four seconds in 2006<\/b>; after three seconds, up to 40% will abandon your site<\/b>.<\/span><\/p>\n

Gomez’ own studies reveal [a] lack of visitor loyalty. By analyzing page abandonment data across more than 150 websites and 150 million page views, Gomez found that an increase in page response time from 2 to 10 seconds increased page abandonment rates by 38%.<\/span><\/p>\n

[The] average impact of a 1-second delay<\/b> meant a 7% reduction<\/b> in conversions.<\/span><\/p>\n<\/blockquote>\n

(original emphasis.)<\/span><\/p>\n

The industry advice continues on and on: incremental decay in performance causes decay in retention and conversion. Slowing down matters. A lot.<\/span><\/p>\n

Shades of Success and Failure<\/span><\/h2>\n

<\/p>\n

We often boil this all down to “How long is too long?”\u00a0 We want a line in the sand.\u00a0 The problem with that is it doesn’t express the continuum of bad consequences that arise from bad performance.\u00a0 There isn’t a magic upper limit to response times. We can’t naively say, “As long as the response time is better than X we’re OK, but once it crosses X there’s a crisis.”<\/span><\/p>\n

There is certainly a lower limit<\/b> on how fast something operates: getting an operation to return in 500 microseconds instead of 2 milliseconds isn’t going to pay dividends if the observer is a human.\u00a0 We just can’t tell the difference. \u00a0<\/span><\/p>\n

Instead of asking how long is too long, start with how fast is fast enough. This helps us limit our investment in things that are already doing well enough.\u00a0 Remember, this is only applicable to human<\/i> interaction.\u00a0 When something is “fast enough” it gets an “A”.\u00a0 At that point, the return on investment falls off — sometimes dramatically.<\/span><\/p>\n

The upper limit<\/b> of latency — the demarcation of total failure — is harder to quantify and certainly less static.\u00a0 The lower bound on latency is caused by physiological limitations in the human body. The upper bound is subject to the changing expectations of ever refining tastes.<\/span><\/p>\n

With this in mind it should be clear that a set of criteria for judging grades of success will be subject to change.\u00a0 However, that doesn’t stop us from making our current, best guess.<\/span><\/p>\n\n\n\n\n\n\n\n\n
\n

Grade<\/b><\/span><\/p>\n<\/td>\n

\n

Motto<\/b><\/span><\/p>\n<\/td>\n

\n

Notes <\/b><\/span><\/p>\n<\/td>\n<\/tr>\n

\n

A <\/span><\/p>\n<\/td>\n

\n

Leave it Alone <\/span><\/p>\n<\/td>\n

\n

From a human factors perspective, it is wasteful to make it faster than this.\u00a0 You’re stealing from other features that need remediation or creation. <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

B <\/span><\/p>\n<\/td>\n

\n

Acceptable <\/span><\/p>\n<\/td>\n

\n

Users will generally be pleased by this.\u00a0 A margin (up to 10%) of the snobbiest (most discerning) users will still be dissatisfied. <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

C <\/span><\/p>\n<\/td>\n

\n

Tolerably Slow <\/span><\/p>\n<\/td>\n

\n

Users will generally dislike this, but tolerate it.\u00a0 Up to 20% of your users may fail to convert or continue the flow simply because of performance. Snobby (highly discerning) users will declare this a total failure. <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

D <\/span><\/p>\n<\/td>\n

\n

Dangerously Slow <\/span><\/p>\n<\/td>\n

\n

Majority of users will deem this unacceptable relative to their other web experiences. <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

F <\/span><\/p>\n<\/td>\n

\n

Automatic Ship-Stopper <\/span><\/p>\n<\/td>\n

\n

Unusable for all but the most intensely motivated users. <\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

User Expectations Vary Across Categories of Interaction<\/span><\/h2>\n

Again, there is no clear line between success and failure. To make matters worse not all operations have to meet the same standards. Users allow some operations to take longer than others based on many complex factors. Let’s\u00a0boil these down to four categories of interaction, represented in the following table. We name each category, give an example of an interaction falling roughly into that category, and a typical black-and-white limit for that category based on articles like those mentioned above.<\/span><\/p>\n\n\n\n\n\n\n\n\n
\n

Category<\/b><\/span><\/p>\n<\/td>\n

\n

Example<\/b><\/span><\/p>\n<\/td>\n

\n

Typical Limit<\/b><\/span><\/p>\n<\/td>\n

\n

Impression of the Interaction<\/b><\/span><\/p>\n<\/td>\n

\n

Notes<\/b><\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Point <\/span><\/p>\n<\/td>\n

\n

Stimulus<\/b>: click on a check-box <\/span><\/p>\n

Response<\/b>: check mark appears <\/span><\/p>\n<\/td>\n

\n

100 ms <\/span><\/p>\n<\/td>\n

\n

What interaction? The computer is invisible. <\/span><\/p>\n<\/td>\n

\n

The user does not tolerate a perceptible delay.\u00a0 The expectations on these interactions are so high that a round trip to the server is (generally) out of the question. <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Chunk <\/span><\/p>\n<\/td>\n

\n

Stimulus<\/b>: click on a drop-down that lazy loads it’s content.<\/span><\/p>\n

Response<\/b>:\u00a0after a brief delay, the content appears in a relatively small portion of the screen<\/span><\/p>\n<\/td>\n

\n

1.0 s <\/span><\/p>\n<\/td>\n

\n

The computer is working for me. I’m in the flow. <\/span><\/p>\n<\/td>\n

\n

Ajax interactions that change a small portion of the page generally fall in this category.\u00a0 <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Page <\/span><\/p>\n<\/td>\n

\n

Stimulus<\/b>: click on a search result<\/span><\/p>\n

Response<\/b>:\u00a0a new article appears taking up most or all of the screen<\/span><\/p>\n<\/td>\n

\n

3.0 s <\/span><\/p>\n<\/td>\n

\n

Hmm.. That took a moment.\u00a0 I will allow it. <\/span><\/p>\n<\/td>\n

\n

When the whole screen gets redrawn.\u00a0 We play games with user perception by getting something to render without waiting for everything.\u00a0 Be careful, if the user is actually waiting for something that is last to render then these games fail to improve perception. <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Commit <\/span><\/p>\n<\/td>\n

\n

Stimulus<\/b>: click “Commit” at the end of a wizard. <\/span><\/p>\n

Response<\/b>: see prompt that the work is done and ready to be inspected <\/span><\/p>\n<\/td>\n

\n

10 s <\/span><\/p>\n<\/td>\n

\n

Wow, that was a lot of work. Good thing that<\/i> doesn’t happen every day. <\/span><\/p>\n<\/td>\n

\n

This is the upper limit on how much waiting a user is willing to do in-flow<\/i>. You can’t have many pages like this. You really shouldn’t even show a spinner.\u00a0 The user should get concrete feedback on progress. <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Batch <\/span><\/p>\n<\/td>\n

\n

Stimulus<\/b>: place a stamped envelope in the mail-box on the curb. <\/span><\/p>\n

Response<\/b>: read the snail-mail reply <\/span><\/p>\n<\/td>\n

\n

> 10 s <\/span><\/p>\n<\/td>\n

\n

Huh? Oh yeah! I remember doing that, but my context needs to be totally rebuilt. <\/span><\/p>\n<\/td>\n

\n

Anything taking longer than about 10 seconds ought to yield the context to the user and communicate completion some other way.\u00a0 Don’t hold the user staring at a spinner for 30 seconds.\u00a0 Too long! <\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Slower Interactions Must Be Less Frequent Than Faster Interactions<\/span><\/h2>\n

Slower interactions (like lazy-loading a product’s\u00a0information) should happen much less often than faster operations (like responding to a user click to draw a check-mark).\u00a0 The following graphic gives a qualitative feel for what this means:<\/span><\/p>\n

\"2015-04-15-frequency-comparison\"<\/a><\/p>\n

This image roughly says that Page interactions ought to occur much more often (meaning, at least an order of magnitude more often) than Commit interactions.\u00a0 Chunk interactions are much more frequent than Page. Finally, Point interactions are much, much more frequent than Chunk.<\/span><\/p>\n

Keep this in mind when trying to decide what latency category an interaction belongs to.\u00a0 <\/span><\/p>\n

\n

Will the user do this rarely (less than daily)? Will they do it regularly (roughly every session)?\u00a0<\/span><\/p>\n<\/blockquote>\n

Mean Stinks at Performance Requirements — We Use 95th Percentile<\/span><\/h2>\n

If you suppose that 2 seconds is the acceptable latency for an operation, and testing reveals that the operation is returning in 1.8 seconds, on average<\/b>, then have you succeeded? Probably not.\u00a0 Unless all instances of that operation complete in roughly the same amount of time there is a good chance that about 25% of your users are having an unacceptable experience.\u00a0<\/span><\/p>\n

We don’t use average, we use 95th percentile.\u00a0 That allows for a tail of exceptional cases (which still matter but aren’t our focus) while giving a more correct impression about how fast the system is for all<\/i> of your users.<\/span><\/p>\n

Total User Experience Category Grades Measure End-To-End Latency<\/span><\/h2>\n

We’re going to throw out Point and Batch interactions.\u00a0 Point interactions are so fast that we don’t expect a back-end call to be involved. Batch interactions are so long that we don’t expect their naked latency to be exposed to the user.\u00a0 That is, we expect such a long operation wouldn’t block the user from progressing by throwing up a spinner for several minutes.<\/span><\/p>\n

Here are the guidelines for grading Chunk, Page, and Commit interactions. All numbers are in seconds, and according to the 95th percentile of the measurement.<\/span><\/p>\n\n\n\n\n\n\n
\n

\u00a0<\/span><\/p>\n<\/td>\n

\n

A+ <\/b><\/span><\/p>\n<\/td>\n

\n

A<\/b><\/span><\/p>\n<\/td>\n

\n

A- <\/b><\/span><\/p>\n<\/td>\n

\n

B+ <\/b><\/span><\/p>\n<\/td>\n

\n

B<\/b><\/span><\/p>\n<\/td>\n

\n

B- <\/b><\/span><\/p>\n<\/td>\n

\n

C+ <\/b><\/span><\/p>\n<\/td>\n

\n

C<\/b><\/span><\/p>\n<\/td>\n

\n

C- <\/b><\/span><\/p>\n<\/td>\n

\n

D+ <\/b><\/span><\/p>\n<\/td>\n

\n

D<\/b><\/span><\/p>\n<\/td>\n

\n

D- <\/b><\/span><\/p>\n<\/td>\n

\n

F<\/b><\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Chunk<\/b><\/span><\/p>\n<\/td>\n

\n

0.27 <\/span><\/p>\n<\/td>\n

\n

0.37 <\/span><\/p>\n<\/td>\n

\n

0.50 <\/span><\/p>\n<\/td>\n

\n

0.75 <\/span><\/p>\n<\/td>\n

\n

1<\/span><\/p>\n<\/td>\n

\n

1.4 <\/span><\/p>\n<\/td>\n

\n

2 <\/span><\/p>\n<\/td>\n

\n

2.7 <\/span><\/p>\n<\/td>\n

\n

3.7 <\/span><\/p>\n<\/td>\n

\n

5.5 <\/span><\/p>\n<\/td>\n

\n

7.4 <\/span><\/p>\n<\/td>\n

\n

10 <\/span><\/p>\n<\/td>\n

\n

>10 <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Page<\/b><\/span><\/p>\n<\/td>\n

\n

0.82 <\/span><\/p>\n<\/td>\n

\n

1.10 <\/span><\/p>\n<\/td>\n

\n

1.5 <\/span><\/p>\n<\/td>\n

\n

2.2 <\/span><\/p>\n<\/td>\n

\n

3 <\/span><\/p>\n<\/td>\n

\n

4.0 <\/span><\/p>\n<\/td>\n

\n

6 <\/span><\/p>\n<\/td>\n

\n

8.2 <\/span><\/p>\n<\/td>\n

\n

11 <\/span><\/p>\n<\/td>\n

\n

16 <\/span><\/p>\n<\/td>\n

\n

22 <\/span><\/p>\n<\/td>\n

\n

30 <\/span><\/p>\n<\/td>\n

\n

>30 <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Commit<\/b><\/span><\/p>\n<\/td>\n

\n

2.7 <\/span><\/p>\n<\/td>\n

\n

3.7 <\/span><\/p>\n<\/td>\n

\n

5 <\/span><\/p>\n<\/td>\n

\n

7.4 <\/span><\/p>\n<\/td>\n

\n

10 <\/span><\/p>\n<\/td>\n

\n

14 <\/span><\/p>\n<\/td>\n

\n

20 <\/span><\/p>\n<\/td>\n

\n

27 <\/span><\/p>\n<\/td>\n

\n

37 <\/span><\/p>\n<\/td>\n

\n

55 <\/span><\/p>\n<\/td>\n

\n

74 <\/span><\/p>\n<\/td>\n

\n

100 <\/span><\/p>\n<\/td>\n

\n

>100 <\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Notice that each series progresses exponentially with a “B” being roughly OK<\/b>.\u00a0 We realize that this might lead to some easy to lampoon results.\u00a0 For example, what makes a 3.7 second response time a C- and a 20 an F? Sounds a bit like magic numbers. Still, we believe there is value in having a constant relationship between the grades.\u00a0 For example, it is useful to know that a B is exponentially worse than an A, and a C is exponentially worse than a B.\u00a0 Furthermore, performance improvements tend to become exponentially more difficult to achieve.\u00a0 So, improving from a D to a C is about as hard as improving from a B to an A.\u00a0 (If the progression were linear then it would be much easier to go from D to C.)<\/span><\/p>\n

Don’t Game Your Category<\/b><\/span><\/h2>\n

WARNING:<\/strong>\u00a0A team may rationalize that a particular measurement is scoring so poorly because it has been miscategorized. For example, you say, “We can frabinaz in 3 seconds, which is a C for Chunk interactions; but, let’s just call it a page interaction and then we will have a B.” That works as long as the user experience is designed with that in mind.\u00a0 Calling something a “page” interaction means that we expect users to do it at least an order of magnitude less often than a “chunk” interaction, and we assume their expectations will be relaxed and forgiving.\u00a0 You can game the system with categories, but calling everything a Commit doesn’t achieve patron retention and conversion.<\/p>\n

Assume Mobile (3G Budget)<\/h2>\n

If you have to simulate bandwidth then start with mobile bandwidth. Most general purpose sites can’t afford to ignore the mobile experience.<\/p>\n

Keep Back-End Performance on a Tight Budget<\/span><\/h2>\n

Sometimes back-end operations need to be implemented without a UI to surface them. You should still keep them on a tight budget. And it isn’t fair for the back-end to spend all of the performance budget.<\/p>\n

According to High Performance Web-Sites<\/a>, back-end time for most Yahoo properties accounts for 10 to 20 percent of the total latency.\u00a0 Based on that, we budget 20 percent of total Page latency for back-end.<\/span><\/p>\n

Since Chunk interactions should have far fewer assets, we double the back-end’s relative allotment of time to 40 percent.<\/span><\/p>\n

Commit interactions should be dominated by the back-end latency of the interaction. They get a relative allotment of 80 percent.<\/p>\n\n\n\n\n\n\n
\n

\u00a0<\/span><\/p>\n<\/td>\n

\n

Back-End Budget of Total Latency <\/b><\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Chunk<\/b><\/span><\/p>\n<\/td>\n

\n

40%<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Page<\/b><\/span><\/p>\n<\/td>\n

\n

20%<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Commit<\/b><\/span><\/p>\n<\/td>\n

\n

80%<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

That makes this the Back-end\u00a0Grade Scale for Chunk, Page, and Commit interactions.<\/span><\/p>\n\n\n\n\n\n\n
\n

\u00a0<\/span><\/p>\n<\/td>\n

\n

A+ <\/b><\/span><\/p>\n<\/td>\n

\n

A<\/b><\/span><\/p>\n<\/td>\n

\n

A- <\/b><\/span><\/p>\n<\/td>\n

\n

B+ <\/b><\/span><\/p>\n<\/td>\n

\n

B<\/b><\/span><\/p>\n<\/td>\n

\n

B- <\/b><\/span><\/p>\n<\/td>\n

\n

C+ <\/b><\/span><\/p>\n<\/td>\n

\n

C<\/b><\/span><\/p>\n<\/td>\n

\n

C- <\/b><\/span><\/p>\n<\/td>\n

\n

D+ <\/b><\/span><\/p>\n<\/td>\n

\n

D<\/b><\/span><\/p>\n<\/td>\n

\n

D- <\/b><\/span><\/p>\n<\/td>\n

\n

F<\/b><\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Chunk<\/b><\/span><\/p>\n<\/td>\n

\n

0.11<\/span><\/p>\n<\/td>\n

\n

0.15 <\/span><\/p>\n<\/td>\n

\n

0.2 <\/span><\/p>\n<\/td>\n

\n

0.3 <\/span><\/p>\n<\/td>\n

\n

0.4 <\/span><\/p>\n<\/td>\n

\n

0.56 <\/span><\/p>\n<\/td>\n

\n

0.8 <\/span><\/p>\n<\/td>\n

\n

1.08 <\/span><\/p>\n<\/td>\n

\n

1.48 <\/span><\/p>\n<\/td>\n

\n

2.2 <\/span><\/p>\n<\/td>\n

\n

3 <\/span><\/p>\n<\/td>\n

\n

4 <\/span><\/p>\n<\/td>\n

\n

>4 <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Page<\/b><\/span><\/p>\n<\/td>\n

\n

0.16 <\/span><\/p>\n<\/td>\n

\n

0.22 <\/span><\/p>\n<\/td>\n

\n

0.3 <\/span><\/p>\n<\/td>\n

\n

0.45 <\/span><\/p>\n<\/td>\n

\n

0.6 <\/span><\/p>\n<\/td>\n

\n

0.84 <\/span><\/p>\n<\/td>\n

\n

1.2 <\/span><\/p>\n<\/td>\n

\n

1.6 <\/span><\/p>\n<\/td>\n

\n

2.2 <\/span><\/p>\n<\/td>\n

\n

3.3 <\/span><\/p>\n<\/td>\n

\n

4.4 <\/span><\/p>\n<\/td>\n

\n

6 <\/span><\/p>\n<\/td>\n

\n

>6 <\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Commit<\/b><\/span><\/p>\n<\/td>\n

\n

2.16 <\/span><\/p>\n<\/td>\n

\n

2.96 <\/span><\/p>\n<\/td>\n

\n

4<\/span><\/p>\n<\/td>\n

\n

5.92<\/span><\/p>\n<\/td>\n

\n

8<\/span><\/p>\n<\/td>\n

\n

11.2<\/span><\/p>\n<\/td>\n

\n

16<\/span><\/p>\n<\/td>\n

\n

21.6<\/span><\/p>\n<\/td>\n

\n

29.6<\/span><\/p>\n<\/td>\n

\n

44<\/span><\/p>\n<\/td>\n

\n

59.2<\/span><\/p>\n<\/td>\n

\n

80<\/span><\/p>\n<\/td>\n

\n

>80<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Common Language Helps<\/h2>\n

In many ways, the categorization and cut-offs are arbitrary. It’s just a model to provide common language for discussing performance.<\/p>\n

Make sure your back-end folks know the experience their call will be part of. \u00a0Tell them if it is a chunk or a page.<\/p>\n

Make sure you identify your A interactions. For those critical parts of your experience you should probably target an A, even if some less important part of the site is at a C.<\/p>\n

Make your own trade-offs. Those are yours. \u00a0This is just language for discussing them.<\/p>\n","protected":false},"excerpt":{"rendered":"

I’ve had a lot of luck using this article to push performance conversations further.\u00a0The numbers are dated but the concepts are real. You have to know how good is good enough. How bad is too bad to tolerate. You have to separate user interactions by value and user expectations. Here I break down user expectations… Continue reading Talkin’ ‘Bout Your Web Perf<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":200,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[53,52,54,51],"class_list":["post-199","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-lab-notebook","tag-latency","tag-page-grades","tag-performance-budget","tag-web-performance","wow fadeInUp","entry"],"_links":{"self":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts\/199","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/comments?post=199"}],"version-history":[{"count":4,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts\/199\/revisions"}],"predecessor-version":[{"id":204,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts\/199\/revisions\/204"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/media\/200"}],"wp:attachment":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/media?parent=199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/categories?post=199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/tags?post=199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}