Tag Archives: Web

We Tested How Googlebot Crawls Javascript And Here’s What We Learned

This study announces a big win for single-page apps that are concerned with SEO


Think Google can’t handle JavaScript? Think again. Contributor Adam Audette shares the results of a series of tests conducted by his colleagues at Merkle | RKG to examine how different JavaScript functions would be crawled and indexed by Google.


1. We ran a series of tests that verified Google is able to execute and index JavaScript with a multitude of implementations. We also confirmed Google is able to render the entire page and read the DOM, thereby indexing dynamically generated content.

2. SEO signals in the DOM (page titles, meta descriptions, canonical tags, meta robots tags, etc.) are respected. Content dynamically inserted in the DOM is also crawlable and indexable. Furthermore, in certain cases, the DOM signals may even take precedence over contradictory statements in HTML source code. This will need more work, but was the case for several of our tests.

Read more from the source: Search Engine Land

Tagging content effectively

It seems like most people don’t understand tags very well. I’m not the best at tagging content effectively, but below¬†are some great principles.

  • The goals of effective content tagging:
    • Allow users to see the subject matter of the post before reading the body (Right Intel doesn’t facilitate this)
    • Allow users and editors to browse and search for content (In Right Intel you can search on the intel tab, email edit screen and story edit screen)
    • Allow search engines to properly index content (Not applicable in Right Intel)
    • Function like an index in the back of a book
  • Some principles of effective tagging
    • A tag should be specific yet likely to be used again
    • A good tag should be short, usually a word or two
    • Use between 2 and 4 tags per article
    • Consider that a tag may be a word that does not appear in the content
    • Use plurals only when appropriate
    • Use only letters, numbers, and spaces
    • Think about what text people might search for
    • Revise and merge your tags periodically
    • Codify tagging guidelines for all editors

Sources: The Next Web, Zemanta, NPR

And ironically, this post is not a great example of tagging because the subject matter is unusual for my blog. :)

CloudFlare blames today’s downtime on South American backbone Internet provider Internexa

With the heartbleed bug, shellshock, and now this BGP route leak incident, 2014 is exposing the fragility of the Internet


Route leak incident on October 2, 2014

This downtime was the result of a BGP route leak by Internexa, an ISP in Latin America. Internexa accidentally directed large amounts of traffic destined for CloudFlare data centers around the world to a single data center in Medellín, Colombia. At the same time Internexa also leaked routes belonging to Telecom Argentina causing disruption in Argentina. This was the result of Internexa announcing via BGP that their network, instead of ours, handled traffic for CloudFlare. This miscommunication caused a flood of traffic to quickly overwhelm the data center in Medellín. The incident lasted 49 minutes, from 15:08UTC to 15:57UTC.

In the past, we’ve written about the inherent fragility of the Internet’s core routing system, and the problem of “route leakage”. Throughout 2014, we’ve seen numerous high profile leaks. In April an Indonesian ISP leaked routes for large swathes of the Internet for a two hour period. Then in September portions of the Internet went offline because of a route leak when a hosting company leaked 400,000 routes, and back in March Google’s DNS was inaccessible in parts of the world because of a route leak. Route leakage is a hard problem that impacts every Internet service provider with no obvious or quick solution.

Read more from the source: cloudflare.com

perf.fail – do, learn, fail forward.

Even the big guys make mistakes. Learn from them through articles on perf.fail. Yes, that is the fail top level domain.


An excerpt from one article:

Twitter doesn’t optimize profile images submitted by users. Beyond the expected 73x73px JPEGs (~70kb, 13 bytes per pixel) there are images with embedded geolocation data and the truly bizarre…

For instance, one user’s profile JPEG is 16kb; 5kb of image and 10.5k of 0x20 octets hanging off the end. Twitter appears to have mitigated this problem somewhat by enabling GZIP when serving images… which, by itself, is a topic for another perf fail post!

Read more at perf.fail