Split testing caveat - Responses from functions?

Support
1

Hello,

I ran a split test for the first time, and think I got the hang of it. I did however see that there is a caveat in the documentation that says “Split Testing doesn’t work properly for responses from functions or proxies.”

Can someone shed light on this issue? My site uses functions for form submissions, I need to know the impact on that. Do they not work at all? Are they hit or miss? I tried searching for info on this on the forums and the web but didn’t see anything pertinent.

Thanks!
Paul

2

I think that the split testing also messed up my Google Core Web Vitals scores, has anyone seen something similar after enabling split testing? I imagine that the initial cookie check has something to do with it, delaying the page load etc.

3

Hiya @unimprobable and welcome back!

I think the caveats around functions in more detail is that:

All functions requests will likely go to the functions on the main, production branch, rather than being branch-affiliated like other static content is. If you use the same function on all branches, this should work reliably; it’s when you try to split test between functions on that same site that you’ll have problems. If you need to split test functions, I’d be sure to make external calls to a separate other website(or sites) where you have the function deployed. Probably an easier way, this should also work, to differentiate the branch versions:

https://branch--site.netlify.app/.netlify/functions/name (branch version)
vs
https://site.netlify.app/.netlify/functions/name (prod version).

If you use something relative - which is generally a best practice so that you can browse deploy previews and the like at any URL:

<a href=/.netlify/functions.name>

…this won’t be branch-specific functions running!

Bonus caveat since you use forms! Forms are ALSO not branch-specific - if you are trying to split test a form, make sure that both copies of the form have identical fields (names + types) in their html. You can hide the fields that aren’t relevant to each branch on the front-end, and you need not submit all values, but you do need to define the forms with identical fields, names, and types in the HTML. If you don’t do this, it is likely that the “last deployed” form will be the only definition we use, and if your other branch submits fields not in that “most recent” definition, we do not store or display them, and there is no going back in time to get them; the data will not be saved anywhere nor logged anywhere we can find it for you.

I’m not sure about google core web vitals. The initial cookie check is (once content is cached for both branches on a CDN node) done at the CDN edge, so I wouldn’t necessarily expect a drop there once you’ve had things running in prod and gotten traffic to them (since we have to cache 2x the content on each CDN node now).

If you wanted to share some more details about what changed we could potentially advise but at a high level I wouldn’t say it’s a given that that will give bad performance (as for instance it is with password protection; that always requires a round-trip to our origin for every asset load so it’s not intended to be fast!)

1 Like