June 15, 2014 at 7:44 am #109857
Your page has 3 blocking script resources and 6 blocking CSS resources. This causes a delay in rendering your page.
None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.
DougJune 15, 2014 at 1:48 pm #109897Brad DaltonParticipantJune 15, 2014 at 3:26 pm #109901
Hey Doug, you can't fix it but some plugins can help.
Let me explain what is happening.
When a page loads in a browser, it goes from top to bottom. With a theme (no plugins) you will have a single css file in the <head> of the site. That css file is styles.css. WordPress requires it. It's where your theme's styles are. It needs to always be in the top. What happens when the page loads is that the browser has to download that file before it renders anything on page. Now you may never notice this because it's so fast, but when you download a lot of plugins and each plugin author has his own css style sheet being loaded in to the wp_head hook... You get a very slow site. Why? Because the browser has to load all of those style sheets! Six is bad... Seven is worse. The browser can load 6 files at a time. So adding one to your six would drastically reduce performance.
What you need to do is speed that site up! The things you can do to make the site faster and score over a 90 on a speed test (besides not having a crappy server) is reduce how many files (css and js) you are including, compress (minify) those files, and compress your html.
This will help you compress your html: http://www.feedthebot.com/pagespeed/enable-compression.html
For the minification, wordpress actually has native support that few plugin programmers avoid using even if they don't know they are using it. The script/style enque method is annoying to devs but it actually has a reason... There are various plugins that will take all of your style sheets and combine them in to ONE style sheet, then minify it. Same for JS (oh and it hooks to the </body> even if the original file was in the <head>. It stops the css/js from blocking rendering.
This is one of the most popular plugins that does that:
The paid version isn't necessary. One thing to know about these type of plugins is this... if you are messing with your theme's CSS/html/php (templates etc...) then you want to turn the plugin off. Because the plugin will remember the scripts/resources and not render them new. It makes it faster to work from local memory instead of redownloading the resources. Which if you altered... you wouldn't see the changes you made.
I hope this helps.June 15, 2014 at 3:29 pm #109902
I was in a rush. In case you didn't understand... A browser has to PAUSE to download JS and CSS files when it see's them. Putting them in the bottom of the site lets the site load so humans don't see the pause. This is never bad unless the MAIN css file is in the bottom of the site, because then the browser would download (really fast) a lot of html and make the site look bad, then all of sudden when the site downloads the css it would correct it all.
It's unlikely you would even notice unless the client was lagging. Rendering is that fast these days, but it's best practice to put the MAIN css file in the <head> of the site (at top). So that browsers first learn how to put the site together, before putting it together.June 15, 2014 at 3:48 pm #109907
Thank you, Brad and Joseph.
I appreciate your input. 🙂
On another topic, I just noticed that MANY caching plugins now have a status of "Not available: This plugin is not allowed on our system due to performance, security or compatibility concerns..." Were you folks aware of that? It just happened recently.
DougJune 15, 2014 at 3:54 pm #109909
It sounds like you are using a shared host. GoDaddy?
Doug, do you own http://discover-your-customers.com?
Are you the SEO?June 15, 2014 at 4:07 pm #109910Brad DaltonParticipant
For the last 2 years i have never used or recommended caching plugins as a great solution because they only cache about 50%.
Proprietary caching at the server level works extremely well for me.
There has been multiple reports of security issues with caching plugins.
June 15, 2014 at 4:13 pm #109911
Studiopress has a caching program too by the way. On their web hosting platform. They have some special functionality with w3tc.
I don't think there is a serious concern for security with w3tc. If there were, it would be common knowledge. That blog post is a little secure and google doesn't reveal anything too obvious. I mean w3tc is like 4rth most downloaded plugin on wordpress.
I don't cache with w3tc anyways. I make too many site changes, lol. I do however use it for minifying my css/js from the few plugins I run.
It has other valid uses. Not everyone (sadly) include their files as //. Some people use http:// which prevents the website from being used in face book apps (iframes). The plugin will mop up all the unsecure resources and deliver them to the site in https:// if it's being requested.
I like that. I do a lot of Facebook apps.June 15, 2014 at 6:34 pm #109918
Yes, shared hosting; that is one of my clients. Is GoDaddy the issue?
Thanks, DougJune 15, 2014 at 6:35 pm #109921
Thank you for letting me know; I appreciate it.
DougJune 15, 2014 at 8:47 pm #109936
Doug, in my experience with Godaddy they prevent websites from doing a lot of things. They even prevent you from using php mail functions. So if you host WP on their server, sometimes wp_mail doesn't work. So plugins that have mail functions stop working from time to time.
Otherwise Godaddy isn't as bad as people say it is.June 19, 2014 at 6:18 pm #110691
Thank you, Joe!
- The forum ‘General Discussion’ is closed to new topics and replies.