MyBB Internal: One or more warnings occured. Please contact your administrator for assistance.
WebPagetest Forums - Far too complicated for me... Can you help?

WebPagetest Forums

Full Version: Far too complicated for me... Can you help?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi there,

I'm updating a website ( for a friend and find that it loads so very slow. So I found this site. Looks like there must be an answer in the results, but I'm not able to see it....

It was originally built by someone else and I updated it with plugins I regularly use for other sites without any problems.

Would you be so kind to help me find where the problem for this website is?

Hope to hear from you.

Best regards,
FYI, the result urls are sharable so you don't have to paste the screenshot:

You have serious back-end (server) issues that WebPagetest can't provide any visibility into. For starters, it looks like the redirect to the www version of your page is taking an ENORMOUS amount of time. You should do the redirect directly in htaccess and not in application code (that's probably why it is taking so long).

Beyond that it looks like you are probably running on some form of shared hosting with poor wordpress performance. You can try using a caching plugin (W3 Total Cache or WP Supercache) which can help.
You share a web server with 600+ sites, which is not unusual for shared hosting environments, but from the looks of it your provider is overselling (i.e. putting more websites on a server that can only reasonably handle a smaller number of websites without slowing every one of them down). Pretty much every website that I can find hosted on the same server is as slow as yours (and it's 11pm, not exactly rush hour), so you'll probably want to switch to a different hosting provider. Unfortunately, most (cheaper) shared hosting packages are paid for on a yearly basis, so you may run into some extra costs, but the improvements in terms of speed could be significant. Fortunately, it's fairly straightforward to back up a Wordpress site and reinstall it at a different host.

You say you have worked on other websites; perhaps you can host this site where you host the others?
Hi Patrick,

THanks for your answer. It is very helpfull and I will look into the files you mentioned.

And a screenshot instead of a link...Much better... Oops... ;-)

Thanks again! :-))

Hi Robzilla,

That's very clear! To move away from the hoster is the urgent advice I will give my friend.

And yes, I have a hoster I use regularly and I am pretty satisfied with. It is much faster :

Thanks for your help Robzilla!

Very much appreciate it :-)

I could not agree more with Robzilla. He is absolutely right.
Hosting a heavy website on a shared hosting package will cause issues most of the times.

Please keep in mint that although using a caching plugin will help, no caching plugin is a panacea for a dodgy hosting company.

A few days ago I have had the website moved to another host.

Results are amazing. Much better this way! = old = new
Much better, indeed, especially considering you're now actually loading a website rather than a simple 'under construction' page.
You still have the HTTP 301 Moved Permanently issue which is costing you over one second.
This redirect must be in the Word Press PHP as it has followed you (Headers Below)

I suspect someone (e.g. a plug-in) is hi-jacking each visitor then redirecting them back to you when they are done doing what ever it is they do.

Search all your PHP files for "header(" (without the quotes) and look for a header statement that starts with Location like this:
header('Location:, true, 301);

or may look like

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

There is also a problem in your <HEAD> that is costing you an additional One Second

The page should start rendering when the last CSS file is loaded.

First off Requests #14,15,19,20 the CSS files need to be moved closer to the top of the <HEAD> right after the </TITLE>

Your Header includes the Character encoding so the <meta charset="UTF-8" /> is superfluous and is in HTML5 format with a 4.01 DocType. You have 179 HTML errors with the 4.01 DocType and only 5 inconsequential IMG ALT errors when checked with an HTML 5 DocType

But still the page does not begin to render after Request #20 CSS file.

I suspect the jet pack (Request #29) or gravatar JS (Request #30) as the page begins to render after them

Combine all the CSS files into fewer files. A single file is best. Order them in largest to smallest (byte size) sequence.

Your server is using Etag rather than max-age (best) or Expiration date caching. With Etag the Browser must make a request a request to the Server to see if the Etag hash has changed. This request takes nearly most of the page load time. On the waterfall chart the Green is Request time and the Blue is data being received. Etags only remove most of the Blue and none of the Green.

To turn on caching if it's not in your site's control panel, add this or create an .htaccess file.

This is an .htacess file from one of my very staic sites. Everything os set to cache for a year.
If you'd like to fine tune by type of file see:

AddCharset UTF-8 .html
Header unset ETag
FileETag None
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=31536000, public"
ExpiresDefault "access plus 31536000 seconds"
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)(\.gz)?$">
ExpiresActive On
Header set Expires "access plus 31536000 seconds"
<ifModule mod_headers.c>
Header set Connection keep-alive

If you are not going to cache then put as much content in the index page rather than linking it in.

from the old IP:

Request 1:
Location: Netherlands
Error/Status Code: 301
Client Port: 4715
Start Offset: 0.106 s
Initial Connection: 37 ms
Time to First Byte: 7931 ms
Bytes In (downloaded): 0.3 KB
Bytes Out (uploaded): 0.3 KB

Response Headers:
HTTP/1.1 301 Moved Permanently
Date: Tue, 22 Oct 2013 20:34:44 GMT
Server: Apache/2
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 20
Connection: close
Content-Type: text/html; charset=UTF-8

from the new IP:

Request 1:
Location: Netherlands
Error/Status Code: 301
Client Port: 3761
Start Offset: 0.115 s
Initial Connection: 38 ms
Time to First Byte: 947 ms
Bytes In (downloaded): 0.4 KB
Bytes Out (uploaded): 0.3 KB

Response Headers:
HTTP/1.1 301 Moved Permanently
Date: Thu, 28 Nov 2013 08:30:44 GMT
Server: Apache/2
X-Powered-By: PHP/5.3.27
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

One other very bad thing is the image size and the Browser scaling the images.

For example you have an image
4,272px × 2,848px
4,468,736 bytes

Which is scaled to 170px × 170px by the Browser

Resize this image to 170 x 170 and save with 7o% compression

I did this and the result image size is 32,768 bytes, saving 4,435,968 bytes

Same goes for
4,272px × 2,848px (scaled to 170px × 170px)
5,648,990 Bytes

Check ALL the images. Generally you can use 70% -75% compression without affecting perceived quality.

If you cannot get caching turned on the convert the images to MIME code 6 at a site like:

Code 64 increases the file size by 30% or so but the gzip compression reduces this to typically, from my experience, about 7% overhead.

Code 64 converts binary data to character based data making it email and HTTP friendly. This is how attachments are sent in email.

It looks like this with a lot more characters:

<img src="data:image/jpg;base64,/9j/4WH4RXhpZgAASUkqAAgAAAALAA8... ">

Or as a background image in CSS
<style type="text/css">
#img1 {
width: 170px;
height: 170px;
background-image: url('data:image/jpg;base64,/9j/4WH4RXhpZgAASUkqAAgAAAALAA8BAgAGAAAAkgAAABABAgAQAA=... ');
Reference URL's