We ran a WebPageTest for our Magento store, and got an F for First Byte Time. I went through the documentation to get a better understanding of First Byte Time and noticed that the definition is listed as this: “The First Byte time is the time from when the user started navigating to the page until the first bit of the server response arrived. The bulk of this time is usually referred to the “back-end time” and is the amount of time the server spent building the page for the user.”
What I’m trying to acquire is some practice ideas on what we can do to improve First Byte Time. I noticed there are a lot of calls to external script files, and am not sure what to attack first. The site is www.cookiesandcrumbs.com. Please let me know if you any suggestions.
What platform are you running on (wordpress, some other cms, custom app) and what type of hosting are you on (shared, VPS, dedicated)?
The external scripts are not going to impact the first byte time at all. It is usually driven by database queries and other operations done by the publishing system to generate the HTML that is sent to the browser. If you ave shell access and can install platform code, New Relic is a great tool for providing visibility into where the time is going. Otherwsie there are also tools for the various platforms that can help.
We’re running Magento. One of our competitors ranks #1 for a highly sought-after keyword phrase, yet has F’s for three of the five categories, so we’re trying to put this all into perspective.
Site speed is not as big a ranking factor as some companies selling optimization services make it out to be, but if you think of your users, then improving your site’s performance (i.e. their experience) certainly gives you an edge over that competitor.
Your TTFB does look to be an issue. I tested your homepage on my computer just now (from Europe) and saw a 1.5s wait-time, which is basically time spent waiting without anything happening. Definitely somethinig worth tackling. Are you on shared hosting?
Yes, we’re on a HostGator shared hosting account. Although it’s not completely finished, we wanted to roll it out as soon as possible to get it indexed in the search engines.
Fair enough, but you lose out on quite few optimization possibilities on shared hosting. After all, there’s only so much you can do within Magento to make it faster. Installing an opcode cache like eAccelerator or XCache would probably benefit you most of all, but requires root access to the server. Once the site is finished, you could consider turning on Magento’s internal caching system. Have you browsed around for Magento optimization techniques? Enabling Flat Catalog and the Magento Compiler are two tips I ran across here. On a private server you’ll also be able to place any rewrite rules directly into the Apache configuration, and turn off checking for .htaccess files on every page hit. If you stick to shared hosting, consider an extension like M-Turbo.
Another reason to switch to a private server (or a different host) is that HostGator does not support simple gzipping of your HTML, CSS and Javascript. On your homepage, this could cut off up to 371.8 KB (but it won’t help decrease your TTFB).
I hesitate to always point to the host/server as being slow because it is a combination of the server code (your application) and the actual physical servers (web and database). Shared hosting providers generally have much lower server performance (particularly around database queries which publishing systems like to do a lot of) than VPS or dedicated servers.
You can usually solve it in one of two ways:
1 - Throw more hardware at it (get a better performing host/server)
2 - Improve the application code
Even slow shared hosting providers can be made to perform well but it usually takes a fair amount of development work and tuning to get there.
You can try the W3 Total Cache plugin since you appear to be running on wordpress. It will let you turn on various different caching layers to help hide the underlying performance issues. You can also try turning off all of your plugins to see if it is being caused by a plugin (and then turn them on until you track down the culprit).