Embedding Marketo Forms on Build rather than on Page Load

[Alex_O_Regan]

Hi,

I'm a web developer working at a company that wishes to use Marketo forms on it's website.

I've successfully gotten Marketo Forms integrated into the website, however, the load times for these embed scripts are unacceptably slow, and cause the website to feel clunky.

My possible solution for this is to execute the embed script during the website build, and then inject the returned form into the static webpage, so that the form will be served as static HTML, along with the rest of the page. However, I'm worried that when it comes to the client interacting with the form, the MktoForms2 script might not be able to detect that the form is already in the webpage.

Does anyone know if this solution will work? I'd like to know now, rather than starting the work only to realise that it's impossible. Any help is appreciated.

Regards.

Alex

[Josh_Hill13]

Sanford Whiteman​ ?

Consider using API for this instead.

[SanfordWhiteman]

Inlining the entire form as HTML will absolutely not work.

You can inline the JSON form descriptor ​however (which is how forms work on Marketo-hosted LPs) and enhance the load time. I explained the process here: Smoothing embedded Marketo form loads

[Alex_O_Regan]

Thanks guys for your help and advice, that being said, I'm pretty disappointed with Marketo Forms as a whole from a dev point of view. I appreciate the features that the custom Marketo scripts offer, but I hate how heavily-imposed they are.

Why am I forced to use this ill-fitting MktoForms script to do something as simple as retrieve a HTML form and then post data back with an Auth key?

[SanfordWhiteman]

There's no obligation to use a visible Marketo form, nor even the Forms JS API, to post data to the Marketo forms endpoint.

You can use a completely bespoke form if you want. Of course, you'd then have to write your own code for validation, progressive profiling, visibility rules, and XHR submission, and the form would not be editable in the Marketo Form Editor (or, to be precise, edits in the Form Editor would have no effect on the public-facing form). But nothing is stopping you from creating a dummy Marketo form and submitting data from another form using its formid (i.e. not even using the Forms JS API to post data, though I don't know why you wouldn't at least take advantage of this part of the library).

What you can't do is scrape the HTML of a form that's intended to be JavaScript-powered and expect it to behave the same way without the JS. This is the same with any JS forms library and isn't specific to Marketo: the HTML does not comprise the core logic.

[Alex_O_Regan]

I definitely agree with you to a point, however Im forced to use the forms2 js so that our marketing team can edit the forms, so this puts me in a position where I am forced to use the js, but unable to have our bespoke (and most importantly, synchronously loaded) forms

. I just think it's a shame that there isnt a simple API endpoint that can return the marketo form (and any relevant data) and have the forms js _not_ make a network request for it.

[SanfordWhiteman]

I just think it's a shame that there isnt a simple API endpoint that can return the marketo form (and any relevant data) and have the forms js _not_ make a network request for it.

In the above blog post, I note how you can pre-fetch the form descriptor so there is, exactly as you say, no additional network request to get the form object as described in the Form Editor.

Naturally the object returned is not a <form> object (it couldn't be because of decisions made at runtime) so the <form> DOM is still built in the browser.

[Alex_O_Regan]

A remedy, but if I understand that blog post correctly, there will still be a form popping into the document after load, which is still not ideal. I appreciate your advice on this matter hugely.

[SanfordWhiteman]

The <form> DOM will be built on-the-fly. It has to be -- otherwise the things users build in Form Editor couldn't all be functional, like Visibility Rules based on hidden fields.

You don't have to show it until it's completely rendered the first time, if you're concerned about the < 50ms where some browsers may show the content in progress.