WebPagetest Forums

Full Version: Huge delay between first byte and start to render
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hey there,

in my test results you can see a huge delay between my first byte and the time when rendering starts.

http://www.webpagetest.org/result/150819...1/details/

Any idea how to improve that or what this is causing?
Hi Seph,

Start Render is composed of Time to First Byte (TTFB) connect time, server response time, processing objects in the HEAD of your document, and initial page parsing and rendering.

Reviewing your waterfall,

1. you have about 900k+ of images in the start render path that you could push out after or possibly compress to reduce the size

2. Move more items out of the HEAD section and move them to the body

3. Most of time on each object is spent in the TTFB and content download phases. You could get a nice boost from using a CDN. Instartlogic.com does some things that would lend well to your site such as reducing your images size (without quality loss) and boosting TTFB and start render via HTML streaming.

Hope this helps!
Rich
Thank you for the feedback. These instartlogic seems like it's only for high budget websites? Mine doesn't earn any money.
Can you implement SPDY? Given the 'normal' size of the home page, this may help by removing latency overhead and downloading a lot of the resources in parallel through a single connection.
(08-26-2015 07:02 AM)GreenGecko Wrote: [ -> ]Can you implement SPDY? Given the 'normal' size of the home page, this may help by removing latency overhead and downloading a lot of the resources in parallel through a single connection.

No, sorry, that is not something I know about.

I made some settings to my cache, no my site seems to run fast on mobile and desktop. Can anyone confirm?

Anyhow, what is weird now here at webpagetest, the first start to render time is still slow but the second one is always very quick, below 1 second in general. Any reason for that?
Can you link to updated test results? The improvement in repeat view is likely from caching but it could be caching in a lot of different places (browser cache for static files, server caches from hitting the page in the first view, etc).
I would look at solutions that put off loading of images until the page has fully rendered, possibly using something like this:
http://www.appelsiini.net/projects/lazyload
Something is very hinky (suspect) with your jpeg images.

The "Compress Images" block is showing as N/A, when you have many jpeg images.

Checking a few of your images, they all require being compressed + progressified.

WPT just doesn't grok (understand) them for some reason.

Try this experiment,

1) convert $in -strip -interlace Plane -gaussian-blur 0.05 -quality 95% $out on all your images

You'd really do this...
convert $in -strip -interlace Plane -gaussian-blur 0.05 -quality 95% $tmp
mv $in $in.orig
mv $tmp $in

2) if load time still to slow, arrange for images to be loaded via pageload event
Reference URL's