I’d like my deploys to be even faster, so tips are welcome!
Note: maybe the checks for “mixed content” and parsing of “header rules” and “redirect rules” are part of post-processing? Since my deploy has a lot of pages (~800) I can imagine the mixed content check may take some time. However I would prefer another CI to check this part with something like Lighthouse CI.
form detection. We can disable this for you as long as you have optimization totally disabled (I see you do), AND you don’t want to use our forms service. If this is true, let me know your site’s API ID and I can turn off forms processing for you.
mixed content warnings. We look for http:// links in your pages and tell you about those so you’ll be aware that a browser is likely to act ugly when displaying the pages. No way to disable this.
However, we wouldn’t have to process at all if you used best practices in creating your site. I don’t think you just edited 839 pages in one commit, yet you have 839 new assets to upload. This is likely due to some antipattern you use in building, as described in this article:
If you don’t change most files, we don’t have to upload and scan most files (no processing of files that didn’t change will occur), so that’s the “best way” to speed up your deploys
I’d love it if you could turn off form processing for our project with this App ID 846d57cb-c5ef-452b-9f3b-c2c43365617d. We are not using Netlify forms for that project.
Of course you are totally right about your point of changing as little files as possible. I can try and explain why we have so many changes:
We have different events triggering our deploys: git push, datocms publish, nightly cron job. In development many code changes, like changing the site header, affect all our HTML pages. And our project has a lot of HTML pages: 833 out of those 839 are HTML pages. The HTML pages contain a static list of locations with opening hours for the next 7 days. The nightly cron job fetches all the new opening hours and that again affects all HTML pages. Only on a cms publish event can we generate specific HTML pages.
We do use an immutable cache strategy for all our assets (configured in _headers) for better UX, but clearly we can’t do that for our HTML.
It is our suggestion that you abstract out the things that could change every page, such as changeable filenames and headers, newsflashes, and list of store opening hours so they reside in one file, that is included from your other files/normal pages. Then you don’t have to upload all the unchanged content of the 833 pages…
Anyway, I’ve disabled that form processing on that site so your next deploy should activate that setting.
I’m not sure how to abstract all things out. A big part of my love for Netlify and the JAMstack is that every page starts and works for everyone with just plain markup. Everything that requires JavaScript (and APIs) I see as an enhancement. So for very dynamic and nice-to-have content I can imagine loading that in asynchronously and thus not affecting the initial page markup. For something like our opening hours we could consider that. However components that are part of the core navigation such as the header, I want to work regardless of the capabilities of the client consuming our website. So I will always want to include that in the static page markup.
Before we started using Netlify we had our own CI and hosting of static generated files using an Nginx server. We would use Server Side Includes (SSI) to include things like headers to abstract them out of our static page markup (<!--# include file="header.html" -->). I see a thread on SSI on Netlify from which I understand Netlify has no such mechanism. Is that correct, or any plans maybe? (Sorry if this gets off-topic, I could start a new thread).
Thanks for disabling form processing on our project. I’ll mark your original answer as solution.
Server Site Includes sounds like a function of server-side rendering. While that is similar to JAMstack, it still assumes you will be processing your pages before it is served so it’s not identical. As mentioned in that other community thread, we server non-server processed pages. That said, SSI seems like it’s outside the scope of JAMstack.
If I want to do the same for other projects, is there a way I can do this through the Netlify Open API? I wasn’t able to find it yet.
Is the reason form-processing is on by default so that developers don’t have to enable anything manually and it just works out-of-the-box? Personally I would like to be able to control this as a developer, either via the Netlify app or a netlify.toml setting.
Hmmmm… personally I like that suggestion. The idea of being able to explicitly opt-out of the post-processing which looks for forms to handle could give a nice deployment speed bump to people who fully understand this and know for sure that they don’t need it. Especially useful for those who also have very many pages in their site.
Hi! just checking whether the suggestion to opt out of post-processing via the UI or as a netlify.toml has made it into the road map? meanwhile, could I ask you to turn off post-processing for the following App ID: 67a2fe1a-20fc-494b-977e-49fb47fc81d1?
(the site is built with Gatsby and no plans for using netlify forms)
I went ahead and turned off processing HTML files for our Forms product for this site. However, the system still scans all HTML files for mixed HTTP/HTTPS content, and there is not a way to stop that.
Was there some other specific post-processing step that you are interested in skipping?
Hello! I was wondering if we could get HTML form post processing disabled for our app as well. The API ID is 96ae52d7-6d75-4c48-9e95-cdb717195ca3. Thanks in advance!
Please elaborate on the technique you recommend for doing this. I have tried jQuery (which works great, except for the fact that search engines cannot see that content), plain old JavaScript (which is a mess to maintain for complex includes), and roll-your-own Ajax calls (which for some reason beyond my understanding do not result in content that can subsequently be styled by other JavaScript).
If you have a mechanism that works – especially if it is along the lines of SSI or PHP include statements – please don’t keep it to yourself.
It’s been 29 years, and we’re still waiting for a built-in way to include HTML from other files as easily as you include an image.
Forgive me if I put in another plug for my suggestion to expand Snippets. Netlify already recognizes head and body tags, if it recognized semantic HTML5 markup tags (header, footer, main, aside, and nav, for instance), it would be trivial to implement this technique.
Sadly, @gregraven I am not actually a front-end developer, not sure what the “best practice” method is. Do people still use <div>s that can import format from another file? I do have to admit I used Server Side Includes when I last needed this functionality 15 years ago, but of course that doesn’t precisely work here.
Jquery should be visible to search engines if you enable our prerendering - if you weren’t seeing that please let us know!
Interesting, thanks. I did look at that page many moons ago, but I’m building multi-page websites and not SPA, so my eyes glazed over a bit. I’ll check it out again. This could be what I’m seeking.
