This functionality was built directly into Google Analytics back in October, William. By changing a line in your on-page tracking code to use the Doubleclick js instead of the regular ga.js, you can pull the demo/interest info into your Google Analytics automatically.

You change this line...

ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';

to this...

ga.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'stats.g.doubleclick.net/dc.js';

A couple of things to note:

• the biggie! This functionality is only available in the classic Analytics. It hasn't yet been enabled in Universal Analytics, so if you want to use it, you'll need to stick with the classic version.
• you must also modify your site's Privacy Policy to indicate how this additional data will be used
• you'll need to turn on Enable Demographics and Interest Reports in Property Settings
• this change will also allow you to create and collect data for Remarketing campaigns

Once you've made the above changes, you should go to Audience > Demographics > Age to validate the code and confirm that the change has been successful.

That what you were looking for?

Paul

Sorry Dana - totally missed your mention about conversions being down. In that case you'll want to do some head-to-head testing with webpagetest.org.

The other thing to consider is that over half your Safari traffic is from mobile, Is it possible there's a mobile-optimisation problem and not a Safari problem? (How do the other mobile browsers perform in comparison?)

And the last suggestion I just thought of: Pingdom now offers Real User Monitoring (RUM) that purports to also be able to track the page speed of Safari users. (It uses it's own javascript module you add to your pages.) Given that this comes free for 1 site even with their free plan, seems like it would be an essential step toward getting a better handle on just where and how big the issue actually is.

P.

Dana, the good news here is that you have probably been worrying for nothing.

The function GA uses for tracking page timing is simply not included in Safari or Safari for iOS (phone/iPads). So those Safari figures you are seeing are completely anomalous and totally unreliable.

Here's the chart that shows which browsers have the capability to report their page speed in Analytics.
http://caniuse.com/nav-timing
As you'll notice, both desktop and mobile versions of Safari are no-go.

The bad news is, just because the GA timings are worthless doesn't prove definitively you don't have any Safari issues. By far the best way to assess the situation is to analyse whether Safari-based visitors behave significantly differently on-site. Is their bounce rate higher? Time on site or conversions substantially lower? If no substantial difference compared to other browsers, you don't have an issue. (Usually this is the case - a site that performs in Chrome and Firefox almost always performs about the same in Safari, in my experience)

The one option you do have to get actual speed tests is to use webpagetest.org and select a testing location that offers the Safari browser as one of the options. Then you'll want to test multiple pages that represent the different primary templates and sections of your site. Do note though that even this will be using Safari on Windows, which was capped at version 5 back in 2012. So you can expect that current versions of Safari, especially native Mac apps, are likely faster.

Hope that sets your mind at ease, and gives you some next steps to further investigate alternative methods!

Paul

P.S When using GA page speed results, do note that by default Analytics only gathers data on 1% of page views. You need to customise your GA site snippet to push that level higher. This is critical for most sites because unless they have huge traffic volume, a 1% sample rate will be wildly inaccurate. The code snippet to add is

_gaq.push(['_setSiteSpeedSampleRate',100]);

and it has to go before the call to _trackPageview. By setting the sample rate to 100 as above, GA will try to track speed of all pageviews. It won't succeed of course, but you'll have far more reliable data. (GA will record speed data for a max of 10K hits per day)

It's not unusual at all to experience this kind of minor, temporary drop, Gordian. The search engines will need to re-index the changes in content and URLs created by your redesign, and this can easily take a week or two.

The critical thing is to be certain you have effective monitoring processes in place to make certain you catch any issues that the redesign might have created just a soon as they occur, so you can fix them before any long-term damage is done.

• Segment out your traffic to determine exactly what source or sources might have caused the drop. For example, your overall traffic may have dropped, but if you look at the source segments, it may turn out that your organic search traffic is consistent, but your site's referral traffic from Pinterest has dropped significantly. (I've had this exact situation with a client - a goof in the .htaccess file was breaking the Pinterest referrals)
• Use Google Analytics and Webmaster Tools to make certain you're catching any new 404 errors and getting them fixed ASAP
• Use Google Analytics to monitor your most valuable pages to make sure they're not seeing an unusual increase in bounce rate, or unexpected drop in time on page.
• Use Google and Bing Webmaster Tools to ensure your site is being fully crawled and watch for changes to how many pages are indexed. (You can use the "submit URL" tools in both to submit the most important pages of the site for re-crawl - can often speed up the process of getting the new URL structure recognized & indexed.)
• Watch for unhealthy increases in page load times for your most important pages via Google Analytics. (Note: you have to customize the Analytics code snippet to get it to include more than the default 10% of pageviews which is almost never enough for accurate analysis.)
• Use your Moz Analytics crawls to keep an eye out for unexpected ranking drops in your most important keywords. (GWT average rankings can also be used for this) Also watch for any increase in dupe content flagged in Moz Analytics

The idea is that yes - it's natural to see a small, temporary drop after a redesign. But you want to be certain that the drop isn't being caused by a correctable technical issue. Hence the need for close monitoring, even if assuming it's just temporarily due to new site design.

Hope that all makes sense?

Paul

P.S. Getting some new, quality, authoritative links to the newly designed pages can really help too. Social Media, especially Google+ can be really effective for this.

As long as the link is correctly tagged with full primary Analytics variables (utm source, medium and campaign) it will show only under campaigns, Mark. It's an either/or process. Traffic can't be recorded under 2 sources or else your analytics would be completely inaccurate (artificially inflated for every tracked link).

Hope that makes sense?

Paul

Actually, no-indexing your contact page is usually a very bad idea, especially if you are depending on any aspect of local SEO for the site in question.

You Contact page is the ideal spot to include all your geo-location information, your properly formatted NAP (Name, Adderss, Phone) to match your Local Citations, and a Google Map of your location.

As the others have said, even if not depending on Local SEO, there's no value to just no-indexing this single page.

Paul

As someone who helps a lot of clients with Social Media, Peter, I'm going to agree with you wholeheartedly.

Specifically as relates to a SM feed widget, they can be a disaster! Their coding and external API calls can slow down page rendering horrifically, they create significant clutter, and as you point out, they server to pull hard-won visitors away from your site where you had a chance to convert them. (And that's assuming you have consistently valuable feed content in the first place.)

The one time I've found them effective is if they are placed on specific pages the sole purpose of which is generating SM engagement i.e. NOT in the sidebar of every page.

Social media engagement can definitely be used to help build a reputation or to drive more effective customer service. But far too many folks are just "doing it because they can" without actually building a strategic plan for how the work will benefit them, and measuring and adjusting to know whether it's actually working.

Paul

Love the whole "like spending money on jewelery" analogy! Especially the part about not spending on it when your roof's leakin' or your fridge is empty. So gonna steal that

Paul

_If I have some inbound links pointing to www.MY-CUSTOMER-SITE.com and some pointing to MY-CUSTOMER-SITE.com, I would think that this rewrite isn't necessary as it would seem that Googlebot is smart enough to know that these aren't two sites. _

Absolutely NOT, unfortunately. Search engines specifically consider these two versions of the URLS to be two totally different sites. The redirect rule you currently have is specifically in place to correct this problem so the two versions of your site (in the eyes of the engines) aren't competing with each other.

The previous developer knew what he was doing. Leave the redirect as-is. Just be careful that all links you create use the primary version of the URL - you'll retain a bit more "link juice" that way than having them go through the redirect. (i.e. always write links as www.my-customer-site.com/whatever for links in content, menus, incoming links where possible)

Paul

P.S. For proof that search engines consider those URLs different sites, Google's own Webmaster Tools has a setting where you can tell Google which version of the site URL you want to be primary. Much better to do this with a proper 301-redirect though so that you can tell ALL search engines, not just Google.

Image h x w attributes don't affect the actual speed of your page load much, Dan. They do strongly affect the perceived speed to the user.

If the size attributes are included, the browser can leave a correctly-sized space for each image as the page gets rendered, even if the images haven't started to download yet. Then the rest of the page content flows in around the image "placeholders". (Images are always slower than text.)

If no image size attributes are present, the browser essentially ignores the placing of the images until the image files actually download, then redraws the whole page to add the space back in for the images.

This redrawing for the images means that text and other elements will move around on the page until all the images have downloaded and it has finished rendering. This gives the user an impression of a much slower page, since they can't start to read the content until it has stopped moving around. Done properly, the visitor can start reading the top of the page even while all the images lower on the page are still downloading.

So yes, obviously including height and width attributes for images is standard best practice for designing an effective on-page user experience.

Hope that helps?

Paul

P.S. As proof, Google thinks they're such a standard requirement that they have included a check for them as part of the scoring algorithm of their Google Page Speed tool.