Is there a way to reduce Time to First Byte (TTFB) and FCP for arcxp website #77
Replies: 1 comment
-
|
Hey 👋 @praneetharao0994, Based on the metrics you shared, your Interaction to Next Paint and Cumulative Layout Shift are already in excellent shape. The areas with the most opportunity for improvement are Time to First Byte and First Contentful Paint, especially on mobile. Below is a straightforward, Arc-XP-focused overview of what actually moves the needle and why. The first place to focus is Time to First Byte, because it determines how quickly the browser receives the initial HTML from the server. Arc XP gives you several strong levers to reduce TTFB. One of the most effective is enabling Extended TTL in Web Delivery. This allows the CDN to serve cached HTML for much longer while Arc XP refreshes the page in the background. As a result, both users and performance audits receive a much faster initial response. Extended TTL is particularly effective for articles, section fronts, and any content that does not change minute-to-minute. Another major factor in TTFB is how your Content Sources are configured. Arc’s own recommendations emphasize using the longest Time to Live you are comfortable with. Every time a Content Source request reaches the backend during SSR, it slows down the first byte. Increasing TTLs—especially for navigation data, standard queries, and stable components—can noticeably reduce the number of backend calls the PageBuilder Engine performs. It is also important to examine the structure of your Content Source code. Arc XP caches the results of the fetch step, not the transform step. If most of your logic sits inside transform, it will run repeatedly even when the cache is warm. Moving heavier processing into fetch, reducing the size of the payloads you request, and avoiding unnecessary API calls all contribute directly to a faster server response. Resolver performance is another often overlooked contributor to TTFB. Complex or inefficient regular expressions can add noticeable latency before the page even reaches the SSR stage. Simplifying patterns, avoiding nested lookaheads, and placing the most common and simplest resolvers at the top of the list can remove hundreds of milliseconds in some environments. A quick test of your regex patterns on regex101.com will usually reveal if any pattern is acting as a bottleneck. Once the server responds quickly, the next step is improving First Contentful Paint. FCP depends heavily on how quickly useful pixels appear on the screen. Arc XP encourages a robust SSR approach, where the page is as complete as possible on the server so the client’s JavaScript does not need to do extra work before something is rendered. Any component that is not essential to the initial view can be moved to client-side rendering after the first paint. The Largest Contentful Paint element is also central to FCP. On Arc XP, this is often the hero image. Preloading the hero image in the head, serving correctly sized images through Resizer, avoiding lazy loading for above-the-fold images, and preferring a text-based LCP when possible all contribute to a faster first paint. It is common to see meaningful improvements simply by optimizing this one element. JavaScript weight is another factor that affects FCP. Reducing bundle size, code-splitting heavy components, loading non-critical scripts after the initial render, and deferring analytics or third-party scripts can significantly speed up how quickly the browser is able to display initial content. Since your INP score is already strong, the goal here is not to minimize interactivity but to avoid delaying the moment the browser can paint something on the screen. Finally, predictable layout behavior helps both rendering and stability. Even though your CLS score is excellent, ensuring that ad slots have fixed heights and defined size sets prevents late rendering shifts, which in turn removes delays in FCP and LCP. Resources |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently our metrics look like this
Largest Contentful Paint (LCP)
2.3 s
Interaction to Next Paint (INP)
53 ms
Cumulative Layout Shift (CLS)
0.01
Other Notable Metrics
First Contentful Paint (FCP)
2 s
Time to First Byte (TTFB)
1.7 s
for a website in desktop device and when it comes to mobile it looks like this
Largest Contentful Paint (LCP)
2.9 s
Interaction to Next Paint (INP)
109 ms
Cumulative Layout Shift (CLS)
0.05
Other Notable Metrics
First Contentful Paint (FCP)
2.4 s
Time to First Byte (TTFB)
1.6 s
Is there a way to make the numbers better
Beta Was this translation helpful? Give feedback.
All reactions