Because the page usually waits for it. A single API call placed in the wrong spot can hold up rendering, block interaction, or leave a blank box where content should be. The API itself is often fast. What costs you is where the call happens and what the page does while it waits.
We get asked to fix this a lot. A client adds a reviews widget, a pricing feed, or a booking calendar, and the site that used to load instantly now hesitates. Nobody changed the design. One new request changed the whole experience.
The good news is that most of these problems come from a small number of decisions, and all of them are reversible.
An API integration is your site asking another system for data and doing something with the answer. Live inventory, currency rates, review scores, calendar availability, and CRM lookups are all the same shape. Your page sends a request, waits, and receives structured data back, usually as JSON.
The important part is the waiting. Every integration introduces a dependency on a system you do not control, running on hardware you cannot tune, reachable over a network that varies by visitor. Your page is now only as fast as its slowest partner.
That is not an argument against integrations. It is an argument for deciding deliberately when the request happens, which is the whole subject of this piece.
On the server or at build time, whenever the data allows it. A call made in the visitor''s browser happens on their connection, on their device, after your page has already loaded. A call made on your server or during your build happens once, on fast infrastructure, before anyone visits.
Client-side calls are the default because they are the easiest to write. Drop in a script, fetch on page load, render the result. It works on your machine on office wifi, and it degrades badly on a phone on a train.
Build-time fetching is the strongest option for data that does not change every minute. You pull the data when you build the site, bake the result into static HTML, and the visitor pays nothing at all. Our own blog works this way, which is why the article you are reading is plain HTML rather than a request to a database.
Server-side fetching sits in between and suits data that must be current. The visitor''s browser makes one request to you, and you make the slow call from a machine that is close to the API and can cache the result for everyone else.
More than the API''s own response time, because the browser has to build a connection first. Google''s web.dev documentation explains that establishing a secure connection to a new domain involves a DNS lookup, a connection setup, and encryption, and that this process can take up to three network round trips before any data moves.
That cost is per domain, not per request. So one integration pointing at one host is a fixed toll you pay once. Five widgets pointing at five different hosts means five separate connection setups, and on a slow mobile connection each round trip is real time your visitor spends looking at nothing.
The thresholds are worth knowing because they are what Google measures. Google''s guidance is that Largest Contentful Paint should be 2.5 seconds or less at the 75th percentile of page loads. For responsiveness, web.dev states that an Interaction to Next Paint at or below 200 milliseconds is good, 200 to 500 milliseconds needs improvement, and above 500 milliseconds is poor.
Those numbers make the tradeoff concrete. If your integration adds a second before content appears, you have spent 40 percent of your entire LCP budget on one feature.
Cache it, and be honest about how fresh it really needs to be. Most data teams describe as live is not. Product counts, testimonial scores, team member lists, and pricing tiers change weekly at most. Fetching them on every page view is paying a performance cost for a freshness nobody needs.
Webflow''s own documentation makes this concrete for anyone building on its Data API. Webflow states that cached requests to its content delivery API have effectively no rate limits, while uncached requests to the origin server count against your plan''s allowance. Caching is not just faster, it is what keeps you inside the limits.
We ask one question when scoping an integration: what is the worst thing that happens if this data is an hour old? For most of what clients want to display, the honest answer is nothing. That answer turns a per-visit request into a scheduled job.
Assume you will hit them and design for it. Webflow''s Data API documentation gives 60 requests per minute on Starter and Basic site plans, and 120 per minute on CMS, eCommerce, and Business plans, with Enterprise negotiated separately. Those limits are applied per API key, so every integration sharing a key shares the budget.
When you exceed the limit, Webflow returns an HTTP 429 Too Many Requests response along with a Retry-After header telling you how long to wait, typically 60 seconds. A well built integration reads that header and backs off. A badly built one retries immediately, which extends the block and can turn a brief overage into a sustained outage.
Webflow also exposes X-RateLimit-Remaining and X-RateLimit-Limit headers on every response, so you can see how close you are before anything breaks. We log those on any integration that runs on a schedule, because a job creeping toward its ceiling gives you weeks of warning if anyone is watching.
Some endpoints have their own tighter constraints. Webflow limits Site Publish operations to one successful publish per minute, which matters if you have automation triggering republishes on content changes.
Your page should still work. This is the part teams skip, and it is the one that causes the worst incidents. If the reviews API fails and your template has no fallback, you can end up with a broken layout, an error message aimed at developers, or an empty region where the social proof was meant to be.
Decide the failure state while you are building, not during the outage. Sometimes the right answer is to hide the section entirely so the page reads as though it was never there. Sometimes it is to show the last known good values from your cache. Both are better than a spinner that never resolves.
Timeouts matter as much as fallbacks. An API that is down usually fails fast, but an API that is struggling can hang for thirty seconds. Set a short timeout, give up, and move on. Waiting politely for a slow partner is how one degraded service takes your whole site with it.
Not reliably, if it is fetched in the browser after the page loads. Google can render JavaScript, but rendering is a second pass that happens later and is not guaranteed. Other crawlers, including several that feed AI answer engines, do far less rendering than Google does. Content that only exists after a client-side fetch is content you may be hiding.
This is the strongest argument for moving the call server-side or to build time. If the data is in the HTML that arrives in the first response, every crawler sees it with no rendering required. If it arrives later, you are relying on each crawler''s patience.
We treat this as a content decision rather than a technical one. Anything you want cited or ranked belongs in the initial HTML, which is the argument we lay out in detail in our piece on why AI crawlers miss JavaScript-rendered content. Decorative or personalised data can safely load later.
Start the connection early and design for the wait. Google''s web.dev guidance recommends the preconnect resource hint to tell the browser you intend to connect to another domain so it can begin that setup immediately, and dns-prefetch as a lighter alternative that resolves the domain name ahead of time.
Use preconnect sparingly. It is most valuable for the one or two domains you know you will need early, and it stops helping if you apply it to everything, because you are then asking the browser to open connections it may never use.
Then handle the visible wait properly. Reserve the space the content will occupy so the layout does not jump when the data lands, because a late shift moves whatever the visitor was about to click. Show a placeholder that matches the shape of the real content rather than a spinner, so the page reads as loading rather than broken.
Finally, do not block anything important behind the call. The page should be readable and interactive while the integration is still working, which is the same principle we apply to server response time in our guide to improving Time to First Byte.
Open your slowest page, look at the network panel in your browser tools, and count how many separate domains it contacts. Then ask which of those requests genuinely need to happen in the visitor''s browser at that moment. In our experience most sites can move at least half of them to the server or the build.
The pattern we keep coming back to is that integrations are a content architecture question, not a plugin question. Where the data lives, how fresh it must be, and who pays the waiting cost are decisions worth making on purpose, which is the same thinking behind choosing whether you need a headless CMS.
If you have an integration that is dragging a site down and you are not sure which part to change, we are happy to look at it with you. Reach out at phoenix.studio and we will work through the options.
Tell us where you want to go. We'll tell you how we'd get you there.