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

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.

New Filter Fields in Google Analtyics

Google Analytics LogoIf you’re an intermediate to advanced user of Google Analytics, you’ve likely used Filters to manipulate data into something you can understand and work with.  One example would be the tweak I shared to demystify the black hole of Not Provided.

Earlier this week Google Analytics announced the availability of a whole herd of new filter fields.  The new fields heavily target those with high-volume mobile traffic, but don’t feel left out if that’s not your niche, there are also some interesting non-mobile options, or options that can be combined with mobile if you like.

Here’s the full list with some thoughts after the ones that stick out.

Continue reading

Google Enhanced Campaigns and Keyword Level URLs

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.

Getting Query Data from Google Webmaster Tools to Correlate with SEO Query Data in Google Analytics

As most marketers are painfully aware, In Oct 2011 Google stopped providing keyword referral data in Google Analytics for searchers who are logged into Google or for searchers using Secure Search (which Firefox has more recently adopted as the default for Google searches).

As a result of the loss of this valuable keyword data source, online marketers have become very creative about designing ways to recapture some details on the search behavior of these visitors. One approach has been to extract more information out of the Google Webmaster Tools (GWT) data which so far isn’t affected by the not provided restriction.

The query data in GWT is limited. The reports provide impressions and click information, but no conversion or other site engagement data. As a result, the data is good for keyword research and to find terms that are relevant to your site, but you’ll likely still have to test the terms in PPC to gain actual conversion information about the terms.

If you have your Google Analytics and your Google Webmaster tools accounts linked you can view the GWT query information directly within Analytics. Google has a section called Search Engine Optimization that displays data sourced directly from GWT.

Not a Discrepancy, a filtering Inconsistency

If you have looked at the SEO data in Analytics and then logged into your GWT, you probably noticed that the queries don’t correlate well. The reason for the list of queries being different is due to the default filtering being different in the two reports.

In Google Webmaster Tools, the queries are filtered to show search query impression and click data from Web searches only by default. You can see a snapshot of the query filtering options below. Notice the Filters button and to the right of it the default is Web.

If you click on Filters you can chose between Web, Mobile, Images, Video, or All. In GWT they list queries filtered for Web by default.

If you then go over to Google Analytics, you will notice that the SEO queries are not filtered. You essentially get the All option. If you want to compare the default list in GWT, you will need to tell Analytics to include “Google Property” and filter for Web.

Then assuming you have the same date range in both Google WT and GA and that you have the data sorted by the same metric, the lists should correlate. Please note that there may be latency reasons for the data not matching if you select a too recent date.

Once I realized the filtering was different the query data made a lot more sense. Hope this helps a few who like myself, was puzzled over the lack of consistency in the query data.

Google+ Communities offer Help, Opportunity

Still in their infancy, Google+ Communities are growing quickly.  First available in early December 2012, they’re quickly becoming an asset to any service, product or idea provider.

Don’t get me wrong, they can be horribly spammy.  I have participated in a few communities.  One of my favorites is a Food Photography community that has helped me learn how to take better pictures with my DSLR in a very short amount of time. Continue reading

Issues with Google Adwords Editor 10.0.0 and Enhanced Campaigns

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.

Making Use of Not Provided Data

Not Provided data is becoming a larger issue than Google first let on.  When they first started blocking referrer data, Google said that “Not Provided” would only affect 1% or less of queries.  That was a gross estimate.  “Not Provided” is relative to the sophistication of your audience.  Are they signed in?  What browser are they using?   Where are they coming from?  These behaviors all affect the amount of not provided results present in your Google Analytics.

You do have options.  You can Continue reading

SMX East New York – Day 3

Missed my coverage of Day 1 & Day 2 – read those first!

The third and final day of SMX kicked off with a session Moderated by KeyRelevance’s own Christine Churchill.  Beyond The Google AdWords Tool: Advanced Keyword Research Tactics covered ways to find keywords that don’t appear in the AdWords free tool.

My wifi was down for most of this session (seriously -how do we function without wifi at these things?  We don’t) but I did capture a few interesting tidbits at the end from Shawn Livengood (@slivengood) and Suren Ter-Saakov  (@seoquaketeam) He shared some great pieces of info centered around Continue reading

SMX East New York Recap – Day 2

Have you read my Day 1 Coverage of SMX East?  Check it out first, then come ready Day 2 Coverage followed by Day 3 Coverage!

Day 2 of SMX saw me speaking on a panel and Q&A Moderating another, it was a busy day and a HUGE amount of Microdata and Markup information was shared.

If you have access to the slides, you should take a look.  If you don’t have access to all of them, take a look at my slides via Slideshare.

I spoke on the Schema 101 – Why the new metadata matters panel – check out all of the tweets from my session – Continue reading

SMX East New York Recap Day 1

The KeyRelevance team recently returned from SMX East in New York City full of enthusiasm and ideas for moving into this next phase of online marketing.

Don’t forget to check out Day 2 and Day 3 coverage when you’re done here!

There was a ton of information shared on Microdata, SEO, Mobile Marketing and more – I thought I’d do a recap of the high points I found, or saw tweeted, while I was there, along with a little analysis and speculation about what it means to you, the marketer or website owner who is Continue reading