Time to first byte too long

[aboue]

Hi,

 

My PS e-commerce website (www.2amores.com) has a long "time to fisrt byte" (around 3 or 4s). Not only the home page but all the pages.

 

I followed some of the advices I found here in this forum (empty connections tables of database, verify modules of the homepage, etc.). I choose all the optimisation on PS back office (CCC, smarty compilation, etc. expect that I maintain W3C validation) But the problem remain.

 

 

I recently imporved the shared server plan.

 

Do you have any idea of what I can do?

 

Thank in advance for your help.

 

Best regards

 

Alex

 

PS: I attach sreenshots of webpagetest, server bakoffice and PSconfiguration

[LeGastronome]

Hi,

 

What version ?

[Rodrigg]

Same problem here. My shop www.ciadopedal.com.br takes 2-4 seconds to first byte. Using Hostgator.

Smarty force compile= no

Smarty Cache=yes

CCC enabled for all items, except high risk

Rijndael

Cache not enabled (I had some problems) but i had tryed to enable it and the results doesn't change

Connections tables empty, statistics disabled.

 

How can I speed up my site? Help me please

[Rodrigg]

More information: I have a Joomla site at the same host, and ttfb is 0.5-0.6

[Rodrigg]

Well, I think my questions don't have an answer

Is anybody here using Aitoc Performance Booster? Is it effective?

[bellini13]

I too have a long TTFB. I have ruled out the server, mysql, apache and php as the issue, but simply creating html and php pages that perform various functions, and tested those pages, and they respond perfectly fine, always well under 1 second.

 

However whenever I test a page under prestashop, the TTFP is always much higher 2+ seconds. I have tried to defrag the mysql tables being used but it has not helped.

 

At this point, it will be trial and error. My plan is to take a copy of my site and place it in a sub-folder, and then start to comment out the code until the TTFB goes down. That should help isolate where the issue is.

[sickz]

This is can have following issue

Your Shared host is to Slow. Most Shared hosts are optimized for many Customer - Get a New hoster which doesn't have many clients in One Server.

You use to many modules/Bad Coded modules.

 

Install a fresh Version of prestashop with exact Same Optionss like the Demo shop you should See nie the Real difference.

After that Import your categorys and Produkts only and compare again.

 

I got a webhoster which is useing SSD Drives

And only 20 Customer per Server Speed is great, about 600-700 TTFB and 3~ Till everything is loaded

 

Try to use mediaserver they improvr the Speed.

 

Excuse please writing from my Handy

Edited June 23, 2012 by sickz (see edit history)

[Rodrigg]

Well.. In my case I have a Joomla site at the same server working with 0.5-0.6 of ttfb... So I think it's not a host issue. I also tried to make a fresh install of prestashop in a subdirectory, and it's slow too... I don't know what to try now.

[sickz]

You can't compare Yomla with prestashop.

Just like i Said compare your fresh Installation with the prestashop Demo. I saw today someone who was Hosting in hostgator Too and had a smiliar Problem but Even worse

[bellini13]

easy enough to rule out if it is the hosting server, as I said in my case it has been ruled out since TTFB is flawless outside of prestashop functionality.

[bellini13]

so here are the results of my baseline testings against prestashop

 

baseline test: a simple static html page that returns "hello world". no images, javascript or css returned

145 ms First Byte Time

96 ms Target First Byte Time

 

php baseline test: a simple php script that returns static html that says "hello world". no images, javascript or css returned. no mysql or prestashop libs loaded

96 ms First Byte Time

105 ms Target First Byte Time

 

php prestashop config: a simple php script that returns static html that says "hello world". no images, javascript or css returned. This just requires the prestashop config.inc.php

Note: config.inc.php includes 2 simply mysql queries

* this loads all prestashop configuration and stores in memory

* this loads all prestashop languages and stores in memory

130 ms First Byte Time

96 ms Target First Byte Time

 

my shops home page loaded: (index.php)

3080 ms First Byte Time

ms Target First Byte Time

 

My plan is to dissect the home page and find the culprit.

[sickz]

easy enough to rule out if it is the hosting server, as I said in my case it has been ruled out since TTFB is flawless outside of prestashop functionality.

 

TTFB is based on how much work the server has to do before he can complie anything, like i Said above you can't compare joomla wirh prestashop.

Its like Apple and Oranges...

Joomla is Not so complex like prestashop, i don't understand why you can't Face that it Night be the hoster.

 

Ofcourse is a plain html Way fastet then a Full Shop Script. I judf suggest you to make the Tests listed above

[bellini13]

I'm not comparing joomla to anything, or prestashop to anything. I am simply trying to figure out why PRESTASHOP has a 3sec TTFB for my store. I have already ruled out the hosting server, that it is not the cause of the issue. when i have compiled the results of my analysis I will share.

Edited June 24, 2012 by bellini13 (see edit history)

[Rodrigg]

A fresh install in my server gets 1,5-3s (v1.4.8). I think it is very high. If I save my home page in plain html, it drops to 0,2.

I can't use mediaserver because it's not working with SSL (a bug?).

Is someone getting less than 0,6 with prestashop? Is it possible?

 

[Dh42]

Bellini, Since you know what you are doing with prestashop, you should run a timer and display the value at different execution points in the store. So you can see where the lag is.

[sickz]

My time is with same settings like you have

 

My time with google chrome

your time with google chrome

 

 

 

As you can see I have a lot more pictures and files on the first load, since it looks okay on google chrome it must be a issue for Internet explorer or your hoster....

[bellini13]

Below are the results of my testing. As a reminder, the TTFB on my home page was 3 seconds.

1. The biggest drop in response time came from disabling the FileSystem Cache. After disabling the FileSystem cache, and only leaving Force Complile=No, and Cache=Yes, my TTFB dropped to 700ms
   
2. The next thing I noticed in my Positions menu, was that I had a lot of modules hooking top, header, left, right and footer. A lot of these modules were disabled, but not uninstalled. I reviewed the Hook code and hooks are still executed on disabled modules. After doing the following, my TTFB dropped to 500ms
   
   1. 
      
   2. I uninstalled all modules that were disabled
      
   3. I added exceptions on the left and right modules, since for my site I do not have left and right columns on my home page.
      

[*]I thought I would finally disable the stat modules in prestashop. I really don't use them and I always read people say they take overhead. Well my TTFB increased to 593ms when I disabled them. I tried this a few times and TTFB was consistently higher with stats uninstalled.

So while my TTFB is still higher than I would like, it is certainly so much better. I am not using mcrypt lib, so there could be some advantages there, but unlikely. I have also started to install the memcache extension to see if that will help at all.

[Rodrigg]

Well, I am afraid I will never get this ttfb with hostgator+prestashop... What hosting service do you use?

[bellini13]

i'm using myhosting.com, with a vps centos build

[kikbo]

Really enjoyed reading Bellini's posts...

 

http://www.webpagetest.org/result/120711_3J_1PE/

 

My first-byte time is between 850 and 1200 ms and I'm on a GoDaddy Virtual Dedicated Server :-/

 

Force Compile off, Cache on...I've checked all the obvious performance things...

 

How can I further improve my first bye time?

[bellini13]

hi there, the only other thing i did was go through all the sql queries being executed and found a number of database columns that are not properly indexed that are used in the queries. this improved my overall speed, but I don't recall it improving my TTFB.

 

without going through your configurations it would be hard to recommend how to reduce yours. have you already deleted/uninstalled modules that you will never use? Do you have any disabled modules?

 

I could offer my paid services to analyze your store and see if there are any more efficiencies that can be made. Two other things I noticed from your speed test are

1) You are not using keepalive, so everything css, js, image etc has to re-open a connection instead of sharing a single connection

2) You have extremely large images 1mb to 4mb. You should find a way to compress these down to something more manageable.

[indus]

Hi Guys

 

I highly recommend the latest 1.4.9 release. My first byte time has definitely reduced to around 600-700 ms and from F status has moved up to D status on webpagetest.org. Previously my TTFB was around 1.2 seconds. This is very good indeed. If anyone knows any presta stores which score A on that site do let me know so i can see what they are doing.

 

Iam on shared hosting.

 

Edit : Just re run the test and got a C. 500 ms. I dont know if my host has made improvements or not, but i have never seen a C before for TTFB.

Edited August 25, 2012 by indus (see edit history)

[bellini13]

reading through the v1.4.9 change notes, i see alot of tuning of mysql indexes, which is good. That accounted for a large portion of my overhead. I will eventually test the new release on my site, and will report back if my TTFB has improved.

[indus]

Yes i was following this thread for a while and posted here since you have been doing some tests of your own. Do let us know what you observe with this new release. I also noted one small thing about the TTFB but not sure if it is a coincidence. The CCC fourth option Compress inline JavaScript in HTML after "smarty compile" execution, when i deselect it, or when i keep this as original. the first byte time achieved was a C. I changed this setting quite a few times back and forth and it went again to D with compression enabled.

 

Might be a coincidence though. Iam not sure. But everytime i selected original Keep inline JavaScript in HTML as original the time was faster.

[Aswin C.]

in smarty set debug to true

then you get an idea what exactly is slow.

put smarty.config.inc.php -> debug = true

[achura]

Hi bellini13!

 

How is your investigation about ttfb?. I´m thinking that the problem is the time connection to mysql,because if i click quickly there isn´n ttfb, but if i wait the ttfb long came again. Perhaps it disconnect early?

[bellini13]

my findings have resulted in 2 culprits

1) mysql execution time

2) php processing time

 

Alot of the mysql execute time is spent querying for data against tables that are poorly optimized (ie..missing indexes).

But for me there was a lot of overhead in process hooks for modules that were deleted or disabled.

 

Shaving off 10ms here and there adds up when you are trying to get under 500ms TTFB.

 

I have completed my upgrade to v1.4.9 as well as applied a new theme, and while the site loads quickly, I am still above 500ms TTFB, which I have come to accept.

 

There are some override class files that you can enable that will display a lot of useful timing information. You enable them by renaming them (ie. _FrontController.php to FrontController.php). I would highly recommend doing this to get an understanding of where all the process time is taking.