Sentry timed the gap between the pay click and the payment confirmation for weeks before any code changed

A funnel assembled from backoffice records cannot see this failure at all. The session dies before the payment POST, so there is no attempt to count, and the next morning the campaign gets blamed ^[5]. The only place the event exists is the browser. According to the dev.to post, the author put Sentry on that one interval, the gap between the click and the payment confirmation, and spent weeks matching it against the hours when campaign traffic peaked ^[6].

The post records three findings, in order: the buyer reached the pay button, the buyer clicked, and the payment did not go out ^[8]. The author wrote, in Portuguese, that the Slack argument between Growth, Marketing and the technical team over which tool to use and whether to migrate was not the wrong question, it was just in the wrong order ^[7].

The checkout was a micro frontend: several teams, several slices, one payment path. MFE solves deploy, the author wrote, and does not solve what the phone downloads in the first two seconds ^[3]. Each slice brought its own code and a piece of its neighbour's, so at the pay step the phone pulled duplicated runtime, the pixel, the upsell, a modal, and sometimes leftovers of the logged-in area before the button rendered ^[4]. A thin SPA shell adds to that: near-empty HTML, the whole bundle, parse, hydrate, then the button exists. It passes on office Wi-Fi and times out on a phone during a live ^[12].

The rule the author draws is one sentence, "o passo atual baixa o JS do passo atual. O resto espera o clique" - the current step downloads the current step's JavaScript, and the rest waits for the click ^[11]. The check is cheap. Open DevTools on the pay step, and if a dashboard chunk is still in the list, the micro frontend put it in your first load ^[14].

Lighthouse is in the same evidence class as a vendor benchmark table. It runs on lab hardware over a cable, on a CPU that is not the buyer's at the hour of the live, and the post says a green score does not on its own prove a sale ^[9]. For that score to predict revenue, the devices and networks hitting the pay step at peak have to resemble the bench. A bloated bundle clears review when the checkout only hurts on organic traffic, and the failure lands when the influencer posts the link ^[18].

The 10 percent showed up on the dashboard a month after the work ^[1]. The post does not state the baseline conversion rate, the traffic volume, or whether ten percent means ten points or a tenth of the previous rate ^[1]. It also says the author did the framework work, "Eu fiz isso tambem" ^[10], and the three changes shipped together as page ready, code on demand, server close ^[15]. Server rendering, lazy loading and the move to an origin nearer the buyer share the 10 percent between them ^[2]. Server rendering was available at all because a BFF already existed; without one, the browser assembles the pay step over multiple round trips ^[13].