Need advice on where to look to improve TTFB (Nginx)

Hello!
Maybe you can help me Im now struggling to pinpoint how can i improve TTFB overall and boost jpegs load times. No luck so far (on some occasions users are still waiting 1,2-3 seconds). I`m lost.

This is results with Cloudflare DNS
http://www.webpagetest.org/result/160405_P7_c14430d893bff083c01ad7e5ab44c3c6/

This is results with no cloudflare
http://www.webpagetest.org/result/160405_JW_a9f16ec3ce901d97e14fbdd3352db8b4/1/details/

My primary suspects were:
SSL Negotiatios (Turning on OCSP improved picture by some 150-200ms)
Network (DNS resolves between Client-Cloudflare-Nginx) pictures seem to prove this idea. But not shure.
Hoster\Physical machine (CPU, memory, io, limits) all seems to be ok

TTFB and start render are separate: TTFB defines the time it takes for the html scaffolding of the web page takes to be delivered, and start render is when the client sees something in theit browser.

As your site 302 redirects to /ru, I’ve done another run ( From Amsterdam again - hoi! ) to there, just to see if it gives a different pattern.

http://www.webpagetest.org/result/160408_99_1RC/

Negotiation takes 0.2s, which is OK, but the 0.5s TTFB is a possible cause for concern. I’ve not got much experience running Java behind nginx, but I’d say that this is the limiting factor, assuming things like tuning any databases have been taken into account. It is all infrastructure - based though: are you just proxying, as there are a lot of tunable parameters in the nginx config relating to that.

As for images, make them smaller! Delivery speed will almost certainly be restricted by the speed of the client connection. You can see if SPDY helps max that out ( or http2 if you’re using a bleeding edge version of nginx ).

I would probably loosen your TLS support, and include 1.0 and 1.1 so old browsers ( like IE 10! ) can access your site.

EDIT. Are you running a caching DNS server? That may help a bit, especially if you interact with any 3rd parties before delivering content.

{ I am looking the WPT chart through Cloudflare http://www.webpagetest.org/result/160405_P7_c14430d893bff083c01ad7e5ab44c3c6/4/details/ }

TTFB
I would suggest to re-look at the initial 2 redirects:
http://java.lotsof.com/https://java.lotsof.com/ (139 ms)
https://java.lotsof.com/https://java.lotsof.com/ru (221 ms)

If the user is supposed to always hit the path /ru over HTTPS, can the first redirect itself be this format:
http://java.lotsof.com/https://java.lotsof.com/ru

I have not worked with cloudflare but, would it be possible to issue it from the CDN instead of the origin? This should reduce the latency and speed up the first byte time.

Finally, I don’t really see an issue with the First Byte (118ms) or the TTFB (119ms) for the first request.

Start Render
Your site loads a bit slow due to 2 main issues:
[list=1]
[]Mixing order of CSS and JS: You have 2 CSS followed by 2 JS and then a few more CSS and so on. This will cause render to block and slow down the display. Ideally, make the non-critical javascripts to be asyc / defer to speed up performance.
[
]Slowness in loading the static objects: Static objects like “/resources/css/style.css” and “/resources/js/bundle.desktop.js” are taking over 1.5s each. Since they are on the critical path, the browser will not display anything until it loads. Consider caching these objects on the CDN.
[/list]

Hope this helps.