Author Archives: Mike Churchill

About Mike Churchill

Michael Churchill is Chief Technical Officer at KeyRelevance and focuses on Analytics, Paid Search, and server/technology issues for KeyRelevance clients.

Chromium “Never-Slow Mode” to Truncate Large Page Content


Posted on
by

Chromium is the browser rendering engine used by Google Chrome, Microsoft Edge, Opera, and a number of other Internet web browsers to convert the HTML, CSS, Javascript, and images into the web pages you want to see.
The Chromium developers recently committed a new “Never-Slow Mode” set of changes to the prototype Chromium codebase in order to test out some new features designed to speed the rendering of web pages.

Note that this is currently a prototype, but it can also serve as a “Coming soon to a web browser near you” comming attractions trailer of where Chrome, Edge, Opera, et al will be heading once this codebase gets integrated.

Why Should You Care?

Nowadays, page bloat is becoming a bigger problem: large code modules, multimegabyte images, and bloated CSS all contribute to slower loading web pages. Newer Web Frameworks technologies like Angular, React, Ruby on Rails, et al, depend on larger client-side payloads and the browser doing more of the heavy lifting on rendering a web site. Easier site development comes at the cost of more work for the browser to render the content, and downloading all the components to make that function comes at a file size and rendering time cost.

Even without those Frameworks, web page size has grown as faster mobile networks and widespread availability of broadband Internet access has made dialup (and it’s draconian speed limitations) a thing of the past. Page speed is lower on a designers list of requirements, and page-bloat is the result. The “Never-Slow Mode” proposed by the Chromium developers would set hard limits on the individual component size and total size for that type of component on a per-page basis. Some of the currently proposed limits are:

Component Type Max Size Per Item Max Size Per Page
Images 1 MB 2 MB
CSS 100KB 200KB
Javascript 50 KB 500 KB
Total Connection Limit   10
Long Task Limit 200 mSec  

Future enhancements already announced include limiting IFRAME nesting depth and a “Feature-policy” header which can trigger on a per-page basis. Currently, the prototype has no UI to inform users that a page is slow and subject to these thresholds/limits.

Since it is still in the prototype stage, it is not clear whether and when this Mode would be turned on. Would it be off by default for both Desktop and Mobile users? On for Mobile only? Turned on automatically when in a slow-bandwidth network area? It is not currently clear.

Page Speed Is Important

Google believes strongly that pages should load quickly, and has already made several steps to help:

  • Advise: Provide their Page Speed Insights Tool for testing and grading a page’s speed on mobile and desktop
  • Penalize: Google is using page load time as a Google Ranking Factor to downgrade slow-loading pages in the SERPS
  • Speed Delivery: Google developed the AMP architecture to allow for fast, lean mobile pages

The Road Ahead

It appears that Google is approaching the point where they will move away from advising on slow pages, dunning slow pages in the SERPS, and providing an alternative delivery mechanism to actively trucating large sites/site components.

As a Site developer, it would be prudent to get jumpstart of ensuring that your site can run efficiently with these proposed limits in place or risk having the site degrade (possibly badly) once these new features are made mainstream. ChromeStory has a little more detail.

Google Enhanced Campaigns and Keyword Level URLs


Posted on
by

Since Google announced their new Enhanced Campaigns initiative which combines desktop and mobile search advertising into a single campaign, AdWords advertisers have been working to upgrade their campaigns into the new system. Google recently announced that ALL campaigns will be automatically upgraded starting in July 2013.

One issue that came to light with the initial announcement was how to handle URLs that are specified at the Keyword level in an adGroup, in conjunction with a site that uses separate URLs for mobile visitors. In the past, one might run separate desktop and mobile campaigns, so mobile-targeted KW level URLs would be specified in a separate adGroup from the Desktop URLs. In the new configuration, the two are merged, so…how does one handle sending visitors to the right location?

Targeting Mobile in Enhanced Campaigns

When one sets up ads, one would normally set up one or more ads for Desktop visitors, and one or more ads for Mobile visitors, and the URLs for each can be hardwired to indicate the “preferred” audience. This is only done at the Ad level, though, and Keyword-specific URLs are left out of this targeting – until now.

Using ValueTrack Parameters to Segment the URLs

Google has a number of “ValueTrack” parameters that can be used to dynamically alter ad copy and/our destination URLs. The most popular of these is probably Dynamic Keyword Insertion (or DKI). DKI allows one to reflect the Ad Campaign’s Keyword in the title or text of the ad copy (or in the URL) by using the {keyword:[default text]} construct in the ad copy.
Google provides a number of other ValueTrack parameters, including an brand new one called "ifnotmobile" . Ifnotmobile is a complement to an older parameter "ifmobile", though the use of this older parameter has changed with the launch of the Enhanced Campaigns. These two ValueTrack parameters can be used to tailor the URLs to the specific platform with a high level of granularity.

Using ifmobile and ifnotmobile to Target the Right Landing Pages

The {ifmobile:[sometexthere]} construct is used to insert text into an ad or URL for mobile visitors only. In the past with standard (legacy) campaigns, this would be used to target mobile AND tablets, but in enhanced campaigns, tablets are treated like desktop systems: {ifmobile:[sometexthere]} is used for mobile platforms only, while the {ifnotmobile:[sometexthere]} construct is used to target desktops and tablets in Enhanced Campaigns.

Below are examples of how to apply this to a variety of desktop vs. mobile implementation approaches, including:

  • Mobile-specific subdomains
  • Mobile-specific subdirectories
  • Mobile visitors identified via a CGI parameter
  • a Mobile placeholder page for a non-mobile-friendly site

Note that sites which use server-side browser detection to segregate mobile traffic from desktop visitors likely do not need to use this approach, since all visitors could request the same landing page and the server would sort it out.

Keyword Level URLs and Mobile Subdomains

To implement this with a mobile subdomain for mobile visitors, one could set up the URL similar to the following. Assuming that mysite.com is the main site, and that mobile.mysite.com is used for mobile visitors, the Landing Page URLs could look like this in AdWords:

{ifmobile:mobile.}mysite.com/specials.php

Thus, desktop and tablet visitors would visit mysite.com/specials.php, while mobile visitors would be directed to mobile.mysite.com/specials.php from the same ad or keyword URL in the AdWords account.

Keyword Level URLs and Mobile Subdirectories

To implement this when using a subdirectory set up for mobile visitors, one could set up the URL similar to the following. Assuming that mysite.com/... is the main site, and that mysite.com/mobile/... is used for mobile visitors, the Landing Page URLs could look like this in AdWords:

mysite.com{ifmobile:/mobile}/specials.php

Keyword Level URLs and a CGI parameter Specifying Mobile

To implement this when you have a CGI parameter set up to distinguish between desktop and mobile visitors, you could set up your URL similar to the following. Assuming that mysite.com/...?mobile=0 is used for desktop and tablet visitors, and that mysite.com/...?mobile=1 is used for mobile visitors. Your Landing Page URLs could look like this in AdWords:

mysite.com/specials.php?{ifmobile:mobile=1}{ifnotmobile:mobile=0}

These would resolve as:

mysite.com/specials.php?mobile=0 for desktop and tablet visitors and as mysite.com/specials.php?mobile=1 for mobile visitors.

Specifying a Completely Different URL for Mobile Visitors

Finally, in some instances one may want to send a mobile visitor to a completely different path than desktop visitors. Perhaps the site isn’t generally mobile-friendly, but it does have a single page that is mobile-optimized, and the AdWords campaign should send ALL mobile traffic to that special page. The Landing Page URLs could look like this in AdWords:

{ifmobile:static.mysite.com/mobilepage.htm}{ifnotmobile:mysite.com/specials.php}

In this final example, desktop and tablet visitors would go to:

mysite.com/specials.php

while mobile visitors were sent instead to:

static.mysite.com/mobilepage.htm

Note that there are limitations in Google AdWords regarding the Display URL and Destination URL. Insure that the mobile and non-mobile domains are closely related or the ads might be disapproved.

Issues with Google Adwords Editor 10.0.0 and Enhanced Campaigns


Posted on
by

Summary: Be aware that Google Adwords Editor 10.0.0 can mishandle SiteLink and other enhanced campaign information when moving from the desktop to your live account and vice versa.

Google has announced a significant change to Google Adwords in their new Enhanced Campaigns. Since migrating from standard campaigns to Enhanced Campaigns involves merging previously separated desktop and mobile campaigns, a lot of the pain can be mitigated by using the Google AdWords Editor (GAE) to move ads/keywords from one campaign to another.

Support for Enhanced Campaigns within Google AdWords Editor had to wait until Version 10.0 was released. The good news is that Version 10.0 was released on 28 Febuary 2013. The bad news is that it suffers from some growing pains. Here are two of the issues we have identified so far:

Moving Enhanced Campaigns started on the web interface

If you have already started the migration process through the web interface, and have taken advantage of the new SiteLinks at the AdGroup level feature, be aware that these AdGroup level SiteLinks may not import into Google AdWords Editor 10.0 correctly. In our tests, these SiteLinks were lost from the adgroup on import. Campaign level SiteLinks were also lost.

Posting SiteLinks are uploaded to the server, but not attached properly

When you post your SiteLinks in an enhanced campaign, they DO appear to get copied up to your account on the server, but with an issue: the SiteLinks are listed as a shared resource for the account but are NOT consistently being attached to the campaign/adgroup to which they were initially added.

What’s probably going on

I suspect that Google made a change as to how SiteLinks are handled internally. In standard campaigns, the SiteLinks are attached to each campaign. With an Enhanced Campaign, the SiteLinks are being treated as an account-level shared resource (like Remarketing Audiences), and the shared resource has to be attached to the appropriate campaign/adgroup. The transition process for this change of implementation is not being handled completely properly.

Conclusion

As with many software tools, using version 1.0 is often a little chancy. The 10.0.0 release is version 1.0 for Enhanced Campaigns. The good news is that Google is pretty responsive to these sorts of issues, and hopefully an update will be forthcoming.

Defensive tactics

In the interim, take it slow. Migrate one campaign at a time, and double check that this various components are being properly applied. Also, keep an eye out for version 10.0.1.

Tracking PPC Traffic from Bing and Other Sources in Google Analytics


Posted on
by

Using Google Analytics in conjunction with Google AdWords is a useful way to track visitor behavior beyond the click. But what about Bing/Yahoo PPC visitors? By default, Google Analytics tracks all Bing or Yahoo visitors, but does not discriminate between paid and organic visitors. If you want to track PPC visitors coming from Bing, you need to add some additional parameters to the landing page URL for the Google Analytics system to decode and track.

As an added bonus, this same technique can be used to track other advertising efforts (e.g. newsletters, site sponsorships, and banner advertising).

How to Track Bing PPC Visitors in Google Analytics
Tracking other PPC/CPM/Advertising campaigns requires setting a couple of additional Continue reading →

Domain Moving Day the Key Relevance Way


Posted on
by

Domain Moving Day the Key Relevance Way

So, you’re gonna change hosting providers. In many cases, moving the content of the site is as easy as zipping up the content and unzipping it on the new server. There is another aspect of moving the domain that many people over look: DNS.

The Domain Name System (DNS) is the translation service that converts your domain name (e.g. keyrelevance.com) to the corresponding IP address. When you move hosting companies, it’s like changing houses, if you don’t set up the Change of Address information correctly, you might have some visitors going to the old address for a while. Proper handling of the changes to DNS records makes this transition time as short as possible.

Let’s assume that you are changing hosting, and the new hosting company is going to start handling the Authoritative DNS for the domain. The first step is to configure the new hosting company as the authority. This should best be done a couple or more days before the site moves to the new location.

What does “Authoritative DNS” mean?
There are a double-handful of servers (known as the Root DNS servers) whose purpose is to keep track of who is keeping track of the IP addresses for a domain. Rather than them handling EVERY DNS request, they only keep track of who is the authoritative publisher of the DNS information for each domain. In other words, they don’t know your address, but they tell you who does know it.

If we tell the Root level DNS servers that the authority is changing, this information may take up to 48 hours to propagate throughout the internet. By changing the authority without changing the IP addresses, then while visiting browsers are making requests during this transition, both the old authority and the new authority will agree on the address (so no traffic gets forwarded before you move).

Shortening the Transition
The authoritative DNS servers want to minimize their load, so every time they send out an answer to a request address for a given domain, they put an expiration date on it. This is called the “Time To Live”, or TTL. By default, most DNS servers set the domain TTL to 14,400 86,400 seconds, which equals 1 day (thanks Andrew). Thus, when a visitor requests the address of the authoritative DNS, it returns the IP address and says “and don’t bother asking again for 24 hours.” This can cause problems during the actual transition, since the old address might continue to be accessed for a whole day after the address has changed.

The Day Before the Move
Since the new hosting company is the authority, they can shorten the TTL to a much shorter value. We recommend that 15 minutes (900 seconds) is a good compromise TTL value during the transition time.

Moving Day
When you are ready to make the switch, have the new DNS servers change the IP information to the new address(es). Since the TTL was set to 15 minutes, very quickly the other DNS servers on the ‘net will be asking for the IP address of the domain. They will be provided with this info, and the switchover will happen much more quickly than if the authority had not changed. Once the new site is live and you have verified nothing is horribly wrong, you can change the TTL on the new DNS servers back to 1 day. If on the other hand, something IS wrong with the new site, you can change the DNS back to the old IP address and within 15 minutes most if not all traffic should be back to the old servers. We also recommend changing the old DNS info to point to the new IP address as a precaution, but if you follow these steps, most of the traffic should have already trasnsitioned to the new DNS servers.

A Bug in BIND
There is a bug in some versions of the BIND program (which executes the DNS translation). This bug will cause a DNS server to continue to ask the same authoritative DNS server for the info as long as he is willing to give it. To complete the transition cleanly, you need to turn the DNS records for the domain off in the old DNS servers. This will cause it to generate an error, which in turn will cause the requesting DNS server to ask the Root level servers for the new authority. Until you make this change, there is still a chance that some traffic will continue to visit the old domain.

Change of Address Forms
The USPS offers a Change of Address kit to help make moving your house easier. Below is the Key Relevance Change of Address Checklist that may make you site’s transition painless.

 

 

 

Key Relevance Domain Change of Address Checklist

2+ Days Pre-Move
Set up new DNS servers to serve up the OLD IP addresses

  • – handle old subdomains
  • – handle MX records

Once that is complete, Change Authoritative DNS records to point to new DNS servers.

1 Day before move
On new DNS servers, shorten TTL to 15 min (900 sec)

Moving Day
On New DNS Servers

  • – Change IP Addresses to new server
  • – Change TTL to 1 day (86,400 sec), or whatever the default TTL is once you are sure all is OK

On Old DNS Servers

  • – Change IP Addresses to new server to catch DNS stragglers

2 Days Post Move (or when convenient)

  • – Remove DNS records from OLD DNS servers (assuming they are still up)