Current time: 12-18-2017, 01:56 AM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Test Results not looking good. Need some help please.
11-25-2013, 10:29 AM
Post: #1
Test Results not looking good. Need some help please.
Our 12 year old company recently had a new website build and migration. I ran the site through this test and the results look terrible. Could someone look over these results and let me know what you think? I am not knowledgeable enough to interpret the results.

I really need to get with the web company that built our site. Many of our customers talk about how they navigate the site and the site actually hangs up during database search and will not advance further. Can you see what might be the problem?

Thanks to all in advance.

Charlie

Website Test: http://www.webpagetest.org/result/131124_N7_S0F/
Find all posts by this user
Quote this message in a reply
11-26-2013, 01:21 AM (This post was last modified: 11-26-2013 01:27 AM by robzilla.)
Post: #2
RE: Test Results not looking good. Need some help please.
Looks like noone spent any time on optimizing the web server, and your developer didn't think to optimize any of the images used.

They very first thing I would do is enable gzip compression of your HTML, CSS and Javascript files. It looks like you're on your own server with Apache and cPanel, so you can probably use these instructions: http://docs.cpanel.net/twiki/bin/view/Al...izeWebsite

Also enable keep-alive from within Apache, so that connections can be reused between HTTP requests, and set expiration headers for static resources (images, stylesheets and such) that don't change often. Your developer ought to be able to assist you with this. I would also stress to them that your images aren't optimized; image compression is a simple trick that can significantly reduce bytes transferred, without visible loss of quality. According to your WPT results, you can save up to 1.2 MB, which is quite worth it.

As for the slow database searches and long Time to First Byte (even on the initial 302 redirect to www.), that's something on the backend, and we can only guess what the cause may be. Usually it's a poorly set up web server, a poorly programmed website, or (worse) both. In short, I would agree that you need to talk to the company that built your site :-)

Ironically, your developer's website has many similar performance issues: http://www.webpagetest.org/result/131125_28_QH1/
Find all posts by this user
Quote this message in a reply
11-26-2013, 08:27 AM
Post: #3
RE: Test Results not looking good. Need some help please.
Rob - Thanks for the advice and feedback. I'll pass this to the developers.
Find all posts by this user
Quote this message in a reply
11-26-2013, 01:51 PM
Post: #4
RE: Test Results not looking good. Need some help please.
Was this site written from scratch? If so, then you've got the added complication of no knowing the code quality, and a lack of free bespoke performance enhancements ( eg WordPress W3 Total Cache, Magento lesti::fpc ).

First, it's taking 2 seconds to redirect from carcoverworld to http://www.carcoverworld.com. This should be instantanious, so fixing that will be an instant win.

To address the (now) 1 second TTFB...

You do have things that can be tuned: MySQL, Apache and PHP. MySQL needs feeding loads of memory in relevant places: there's a script called tuning_primer.sh ( many thanks to Matthew Montgomery ) which will provide you with a good starting point for that.

Apache's been dealt with to some extent ( keepalive, mod-compress, etc ). I must admit to being a bit rusty with it, as I find nginx to be a faster, lighter and just plain simpler to work with.

With PHP there are two ways you can improve performance: use an opcode cacher, and feed it lots of memory, and run in FPM mode. The eAccelerator opcode cacher seems to work best with apache, and APC ( the later version built via PECL ) for PHP-FPM.

You'll possibly also gain from a varnish server in front of your site, so it can deliver as much content as possible directly from it's local storage. However, configuring it correctly is not a trivial task.

For the rest of the content, A CDN will perform 2 things: first it'll deliver faster than your (shared) 100Mbit/s internet connection, and second, it'll remove the load off the server network interface - 100Mbit = 12.5MBytes/sec, which can get swamped fairly easily with a heavy graphics site. In addition, the use of sprites will reduce the number of files necessary to build a site, and so also aid performance.

As a shortcut it may be worth playing around with Google's mod_pagespeed plugin, as it has the ability to post-process your site into a more efficient form, including autogenerating sprites, resampling images and so on.

Also, look at image compression, but don't go wild about it at the moment.

http://www.webpagetest.org/result/131126_BE_5WT/ is probably more relevant to your site - better, but... no cigar (:


If you need a hand let me know... Here's my site ( totally irrelevant but looks good! ) http://www.webpagetest.org/result/131126_7D_5XS/
Find all posts by this user
Quote this message in a reply
11-29-2013, 02:51 AM
Post: #5
RE: Test Results not looking good. Need some help please.
Our developers have improved some of the site metrics, but it looks like we still have problems and the site just hangs and won't advance at times for us and our customers. (Intermittently). This is our biggest concern. Thanks for your feedback.

New Test Results: http://www.webpagetest.org/result/131128_FB_V91/
Find all posts by this user
Quote this message in a reply
11-29-2013, 07:20 AM (This post was last modified: 11-29-2013 07:24 AM by robzilla.)
Post: #6
RE: Test Results not looking good. Need some help please.
If you compare your performance to the sites listed in your developer's portfolio, you'll find that they're all about at slow as yours, and are managed using the same proprietary CMS, so that's probably where the problem lies. And if they take care of your hosting, too, then you're probably not really in a position to improve performance by yourself.

I browsed around the site (from Europe) and the lags weren't too bad, except for the search box, which took a good 10 seconds. Particularly wasteful is the shortness of Apache's keep-alive setting (5s currently). Unless you're on a busy server, they should be able to crank that up to 60s without a problem, and this could make the browsing experience feel a bit snappier. It's a simple fix for them.

It's a little odd that the redirect from carcoverworld.com to http://www.carcoverworld.com is taking so long, since it's an action that's usually handled directly by the web server (Apache in this case, either through httpd.conf or a .htaccess file). That would suggest the web server, or the machine itself, is either under high load or poorly configured.

Either way, if it's managed hosting, there's not much you can do other than complain.
Find all posts by this user
Quote this message in a reply
12-03-2013, 11:08 AM (This post was last modified: 12-04-2013 03:10 AM by pmeenan.)
Post: #7
RE: Test Results not looking good. Need some help please.
Your host, Softlayer in Dallas is fine. There are a lot worse, like GoDaddy.

I have had a few sites hosted on Softlayer a few years ago and they were OK. Better than a VDS on GoDaddy.

The huge issues are the 2 second Redirect and the interleaving of CSS causing a a very long time to Start Render and First Paint. The JS could also be causing a rendering re-start.

All CSS must be at the top of the <HEAD> right after the </TITLE>

BIG ISSUE: Move the <STYLE> CSS out of the <HTML> and into the <HEAD>!!

This is a likely reason for your slow Start Render Time because the <STYLE> is not scoped. One is inside a <DIV>, this is wrong. Just put it in the <HEAD>

No JS should be loaded before all CSS. If a JS script loads CSS then add a CSS link for the same file.

There are various reasons for using redirects, none of them are legitimate.

If you are using open source and or plug-ins they may be hi-jacking your visitors.

What is happening is somewhere in early the PHP code a PHP script is running and when the script is done, 2 seconds later your home page is loaded by using the redirect.

Somewhere in the PHP there will likely be a header statement like:

header('Location: http://www.carcoverworld.com/, true, 301);

or may look like

header('Location: . _SERVER["REQUEST_URI"], true, 301);

If you want me to take a look and find out what is going on I'll do that for you out of professional curiosity.

<edited to remove inappropriate content>
Find all posts by this user
Quote this message in a reply
12-03-2013, 11:13 AM
Post: #8
RE: Test Results not looking good. Need some help please.
iSpeed - Thanks so much for the look over. Any additional info or review is appreciated and will be forwarded to our web development folks. Thanks.

Charlie
Find all posts by this user
Quote this message in a reply
12-04-2013, 03:19 AM
Post: #9
RE: Test Results not looking good. Need some help please.
@iSpeed, please keep your contributions constructive without devolving to insults. The slow start render has nothing to do with the CSS location - the main issue is that there are so many separate css and js files that are being loaded individually (though they are all cacheable so it's mostly a first visit hit).

Charlie, the redirect looks like it is being done by the application rather than the web server. You should be able to create a simple .htaccess rule that will do the redirect directly (bonus points for making it a cacheable 301 redirect) which would improve any cases where the users hit a redirect.

From the looks of things, the web server is doing a reasonably good job serving static content so you may have to look at adding caching to the application layer itself (depending on what platform it is built on there may be out-of-the-box solutions available).

The other thing that can get you a quick win would be to re-compress some of your images. The big banners in particular - http://www.webpagetest.org/result/131128...ess_images

Just compressing the banner images better will cut the page weight by close to 70% and the site will look exactly the same (likely a problem across the site).
Visit this user's website Find all posts by this user
Quote this message in a reply
12-05-2013, 02:17 AM (This post was last modified: 12-05-2013 03:12 AM by iSpeedLink.com.)
Post: #10
RE: Test Results not looking good. Need some help please.
(12-04-2013 03:19 AM)pmeenan Wrote:  @iSpeed,The slow start render has nothing to do with the CSS location -
If you do not believe me, maybe you will believe Google:
From Google's Web Performance Best Practices
"Browsers block on external CSS files before painting content to the screen. This incurs additional network latency and increases the time it takes to display content to the screen."

How does the page get rendered without the CSS?

When subsequent CSS links are encounter by the Browser the rendering has to re-start. Look at the waterfalls and the location of the last CSS and the Start Rendering. Locating the CSS at the top of the <HEAD> is a fact. Not my opinion.

Think about it. First the C in CSS, is CASCADING. means child selector attributes will inherit attributes from form parent selectors. When the parent or child is in the subsequent CSS file will that not have an effect on page rendering?

Secondly the order in which the STYLE attributes are defined sets precedence. Subsequent attributes override the prior.

The Browser must complete the DOM database tables to be able to render the page. When parsing the CSS and the Browser encounters new CSS the Browser could instead examine to see if and how this change will affect the rendering already done. This would add some very complex code and slow the process, it is then likely the Browser will determine that the best approach to deal with the new CSS changes is to start over.

Or they could simply without need for additional complex code just start over. They can then, as they have, publicize the rule about putting the CSS first so the Browser does not have to re-start rendering.

(12-04-2013 03:19 AM)pmeenan Wrote:  @iSpeed,- the main issue is that there are so many separate css and js files that are being loaded individually (though they are all cacheable so it's mostly a first visit hit).

There will be NO second cached visit when the user clicks the Back button rather than wait for the first page load.

The first and foremost is the fist page view in order to get in to the cache. When the user clicks the Back button rather than wait for the first page load the cache does not get loaded.

Furthermore there will be less first loads because Google is very careful to monitor the time you click on a link and when you return from the site. Every time someone bounces from a Search Link the page is lowered in the ranking for that search term. With lower ranking there will be fewer referrals from Google. With no Google referral there will consequently be no need for a cached second view.

The Google bot is only concerned about first page views. Google's job is to refer good quality links to their users. It is in Google's best interest to filter out pages that load slow. Most Google users are visiting site for the first time. Because Google knows (as they have published) how many will abandon a site with slow a page load. Again, with no Google referral there will consequently be no first view or a need for a cached second view.

Google has also published they use page load speed in their ranking metrics. The even are so concerned with this metric they have gotten involved with a project that ranks Web Page Speed. Maybe you have heard of it? PageSpeed Insights. Slow pages are ranked lower and get fewer first views and no cached second views. Again, with no Google referral there will consequently be no first view or a need for a cached second view.

(12-04-2013 03:19 AM)pmeenan Wrote:  Charlie, the redirect looks like it is being done by the application rather than the web server. You should be able to create a simple .htaccess rule that will do the redirect directly (bonus points for making it a cacheable 301 redirect) which would improve any cases where the users hit a redirect.

Where is he going to redirect to? If there were a better page to load first, wouldn't it be better to make that page the index page rather than use a redirect?

Would it not be much better to solve the problem rather than use a time consuming, albeit small, redirect?

Finding the PHP redirect (it is a PHP redirect as evidenced by the header) is a piece of cake using a quick and simple text search of the PHP files for the redirect header() command.

There may be a reason for the redirect. It is possible there is a authentication or initialization process that must be run for an online app to run.

If it's a clandestine hi-jacking it would be wise to find the culprit. It could be a devious Web Developer.

(12-04-2013 03:19 AM)pmeenan Wrote:  Charlie,
you may have to look at adding caching to the application layer itself (depending on what platform it is built on there may be out-of-the-box solutions available).
Caching of dynamic pages adds another level of complexity and another point of failure. Would it not be better to eliminate the need for the caching?

PHP is very capable of doing a better job of transmitting the HTML than a caching solution.

First of all PHP can specify header parameters more dynamically than Apache. PHP can override the default output buffering and send the <HEAD> before the output buffer has enough bytes to trigger early transmission.

Would it not be better to address the underlying PHP problem? In many cases it is just a simple matter of adding a flush() command in the appropriate places.

For Word Press, especially free WP Themes, it is a simple matter of correcting the PHP code. For example WP Themes typically use context switching between HTML and PHP. Throughout the code WP uses <?php $variable ?> in HTML output mode. Each time this happens it requires a time consuming context switch.

The correct way is to keep the mode in PHP output and use Heredoc string quoting and inserting a flush() whenever appropriate.

Most designers process their SQL Queries for dynamic content before sending any HTML.

I will transmit as much of the page as possible. Usually at least the <HEAD> and page HTML header. I will halt the output, flush the buffer, process the SQL query, format the query results storing the resulting HTML in the next output buffer and flush this buffer before the server has completed transmitting the previous buffer.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


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