Current time: 09-29-2020, 03:09 PM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Tips on improving Start Render time
11-18-2012, 06:09 PM
Post: #1
Tips on improving Start Render time
So I've been benchmarking my site again and felt that it has slowed down compare to eight months ago.

Here's the result from eight months ago: http://www.webpagetest.org/result/120314...1/details/

And here's the latest test:
http://www.webpagetest.org/result/121118...1/details/

My start render was slowed down from 0.45s to 0.57s, 120ms slower before I can see anything. The slowdown is noticeable. I don't know if Google Analytic changed their ga.js in ways that can affect the Start Render time, possibly blocking the page load in the past few months. I did use the async method to load it so it shouldn't be blocking anything. But here I go, I see that it is blocking the downloads.

Are there any tips on improving Start Render in general? Or does anyone know a way to implement ga.js better and more effective without affecting Start Render? Thanks WPT!!
Find all posts by this user
Quote this message in a reply
11-19-2012, 02:48 PM
Post: #2
RE: Tips on improving Start Render time
ga isn't causing you any problems or data transfer speed, it's the initial connection and the ttfb that's slow. At a guess, you're on shared hosting, and the server is busier than it used to be... effectively reducing the power of your web server by offering you less of it.

You may well be on a VPS by the look of it... but the same applies. If you do have your own VPS, then ensure the database is tuned properly, and you're using a relevant PHP opcode cacher ( I think APC works best with lighty - I'm an nginx cnvert myself ).
Find all posts by this user
Quote this message in a reply
11-20-2012, 12:28 AM
Post: #3
RE: Tips on improving Start Render time
Try doing several runs to see if it is consistently slower. The main difference that jumps out at me is that in the older test, the css is fetched using the same connection as the base page and in the newer run a new connection is opened and it's the cost of opening that new connection that made the difference.

It's probably just a timing thing with IE where in the old case all of the HTML was available and parsed before it went to fetch the css and in the newer case the browser discovered the css before it finished receiving the html so it opened a new connection.

I think the newer browsers are smarter and if the connection frees up before the new connection opens it will use the existing one even if it opened a new one (and IE 9 even opens 2 in anticipation I believe).

Since your css is cacheable and it's only the first visit where someone could even run into it I wouldn't worry about it too much. You could get really fancy if you want to eliminate the time for loading the css but I'm not sure it's really worth the effort:

Here's basically what the technique would do when the page is being generated, if a "css-cached" cookie is not present you:
- inline the css directly into the html
- create a hidden iFrame at the end of the html that loads a "caching" document
- the caching document includes the external css resource and sets the "css-cached" cookie

That way you can leverage the cached version for all subsequent visits and still not pay the penalty on the initial visit. It's a lot of work to do for 50-100ms on just the first page load though.
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)