You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using Shopify template structure for a small Instagram app, and while I tried to apply for "Built for Shopify", I found to my surprise that the app has a LCP score above the 2.5s recommended to apply to the program (about 3.5s).
This app uses online-access token to authenticate users (this could be removed, but we did it this way as we might add features to edit products in the future, and we wanted to have this done from the start), so when users first authenticate, there is several redirections:
The app itself is barely optimizable. The app itself just does one Ajax request to render (I've checked the API timing and it is fast). It is using a placeholder while loading. It uses Polaris and App Bridge, with no extra dependencies. Everything is minified. Static resources have a long cache control value, and served through a CDN (CloudFront).
In other words, I've exhausted all the possible optimizations at our level, which just leave the starter.
The issue with this app is that it is a "install and forget" app. Merchant will typically install it, have the long initial double OAuth dance, set it up, and leave it. And will likely never open the app ever once setup, as everything else happens through app blocks.
My only intuition though is that Shopify calculates the LCP by also taking the whole OAuth callback time (which indeed take 2-4s the first time), which would heavily penalize apps like ours.
It is a bit odd though that following the Shopify starter and the best security practices (by using online access token) is actually preventing to apply to the Built for Shopify program due to those performance penalties.
I wonder if there are some plans to either:
Improve how LCP is calculated for apps.
Provides a way to ask both offline AND online token in one request to limit the time spent on authentication.
Or eventually modify the way the starter is structured to optimize it for Shopify performance recommendations ?
Thanks!
The text was updated successfully, but these errors were encountered:
Hi,
We are using Shopify template structure for a small Instagram app, and while I tried to apply for "Built for Shopify", I found to my surprise that the app has a LCP score above the 2.5s recommended to apply to the program (about 3.5s).
This app uses online-access token to authenticate users (this could be removed, but we did it this way as we might add features to edit products in the future, and we wanted to have this done from the start), so when users first authenticate, there is several redirections:
App => OAuth callback (for offline token) => Redirect => OAuth callback (for online token) => Redirect
The app itself is barely optimizable. The app itself just does one Ajax request to render (I've checked the API timing and it is fast). It is using a placeholder while loading. It uses Polaris and App Bridge, with no extra dependencies. Everything is minified. Static resources have a long cache control value, and served through a CDN (CloudFront).
In other words, I've exhausted all the possible optimizations at our level, which just leave the starter.
The issue with this app is that it is a "install and forget" app. Merchant will typically install it, have the long initial double OAuth dance, set it up, and leave it. And will likely never open the app ever once setup, as everything else happens through app blocks.
My only intuition though is that Shopify calculates the LCP by also taking the whole OAuth callback time (which indeed take 2-4s the first time), which would heavily penalize apps like ours.
It is a bit odd though that following the Shopify starter and the best security practices (by using online access token) is actually preventing to apply to the Built for Shopify program due to those performance penalties.
I wonder if there are some plans to either:
Thanks!
The text was updated successfully, but these errors were encountered: