Once more, compared to the rest of the protocol and data transfer, TFO will be insignificant.
Proof:
3wHS.png
The indicated rows are the full 3-way handshake. The TCP connection is established in 51 ms without TFO from my location to yours. TLS Client Hello on its way after 54 ms and first encrypted data being sent by the browser after 109 ms.
Of note, Ping to your server is 49 ms, so we're looking at a single round trip to establish the TCP connection, and another single round trip to have TLS completely ready.
3wHS-trace.png
All this confirmed inside the browser with timings:
3wHS-timings.png
51 ms to establish connection, another 58 ms for establishing TLS, after which the browser waits 71 ms to be served your page's initial html.
This is then followed by being shoved 80 kB of CSS and 87 kB of JavaScript, which takes approx. 250 ms to parse before the rest of the content is loaded in parallel through a connection pool, which takes a total of 1.18 s before DOM content is loaded. Page load completes after 1.66 s. Effectively, TFO could maybe shave off half a round trip, i.e. ~ 25 ms, if you take the necessary processing and added complexity into account.
If you don't have any stalls or async hangups because of this, that would mean
at most saving 1.5% on the page load time with TFO. Is that worth the added risk, and potential loss if you have any hangups because data is sent prematurely? I think not.
1.5% is also not "significantly accelerating" anything. Even in the theoretical ideal situation of 3%, it's still not significant.
Off-topic:
P.S.: While there I noticed that you are implementing a P3P header. Don't bother with that, it's a dead, unfinished spec not used by anyone, even the spec itself states: "The Technical Architecture Group (TAG) has discontinued work on this document. The specification should not be referenced in this form or implemented as-is."