ResponsiveView Chrome Extension (#8)

This Chrome Extension falls into the same theme this week: it’s a quick and easy way to look at your site in lots of different sizes.

When you get to the Chrome extension store click “Add To Chrome”

Now visit the website you want to test and click the icon in the Extensions bar.


What I like about this one most is the extraordinarily helpful sidebar which lets you easily slide between the views. Check out how slick this interface is:

What a great tool. Use it today to check your website quickly for viewport responsiveness. Look how easily it slides back and forth as you choose different veiwports.


Am I Responsive? (#7)

You type your URL here, and the page barely reloads. The image of the existing computers stay as-is, but you see your website appear inside of them:

(keep in mind this is a screenshot of yesterday’s post)

Neat, eh?


Responsinator (#6)

Today I kick-off a mini-segment on responsive design tools — things to use while developing your website to make sure it works on both desktop and mobile browsers. In short, responsive means the CSS responds to the size of the viewport (which for mobile devices like iPads is the width of the device and cannot be changed). This enables the experience to be delivered seamlessly and without friction on any size screen— from small phones all the way up to wall-mounted television displays.

Today’s tool is Responsinator

Responsinator is a quick-little tool to show you your website on lots of different popular viewports: portrait and landscape for each of iPhone X, Android, iPhone 6,7,8, and iPad.

They’ve adoringly dubbed the iPhone X the “iPhone eXpensive” and the larger of the iPhone 6,7,8 models as “iPhone Plumo” in their display

Here you can get a quick view of how mobile responsive your website is.

Use it today to try to get a feel for how your site looks at different viewports — that is, the width (as measured in pixels) of the devices that will show your website.

Tomorrow we’ll continue to look at similar tools for checking your website for responsive design.

Won’t you subscribe to the newsletter? Be sure to LIKE and FOLLOW, just scroll down.


Litmus Email Testing (#5)

Sending emails? Testing your layouts in every email client is essential. Writing markup for emails is harder than writing markup for browsers (because it is more tedious).

The tool is pricey, but it is worth it and you can get a free trail for 7 days.

When you first sign-in you are presented with a screen that tells you to paste your HTML email content. However, it’s easier simply to send your test emails to the auto-accept address they provide you.

When you send off emails to this address, Litmus automatically just pulls them in and lets you look at them.

When you hover over an item in the inbox, buttons appear to let you navigate to a view specific to that email:

For this brief introduction we’re going to right to the “Checklist” view, which shows you how your email looks in every email client.

For macOS (Apple), it even shows you different versions for “dark” and “light” depending on if the user has dark or light set in their browser.

It shows you every email client in a small thumbnail view which you can easily scroll through to test all your emails.

Here’s yesterday’s blog post turned into an email and how it looks in Litmus:

Next check out the “First Impressions” and “Accessibility” sections, which will analyze and give you tips on your subject, name, preview text. Below you get an analysis for alt tags, missing HTML attributes, and things that make your content friendly to non-standard screen readers (for accessibility).

You can also use Litmus’s interactive builder to actually build out your email too.

Although a lot of email marketing tools abstract a lot of these concerns away from content creators, if you are hand-coding emails Litmus remains a strong and solid tool for anyone who wants to build their own custom HTML emails.


BrowserStack (#4)

BrowserStack is the herculean all-platform solution for cross-browser testing. You can see and test your browser, quite literally, in every web browser.

Cross-browser testing is super complex, and thankfully the advancements in HTML and browser implementation have made cross-browser implementation take less time than it used to.

Nonetheless, only a fool wouldn’t test their website in a cross-section of the browsers they know are visiting their website. How do you know who’s visiting your website? An upcoming post on Google Analytics will show you how to see your traffic in a pie chart by web browser. I recommend you test any browser that shows 5% of more of your traffic, as a good starting benchmark. [Sign up for the email list now to keep up-to-date.]

When you sign up for BrowserStack’s free trial, it asks you to set a preference if you are testing first for web or mobile (a trick question, so click “Skip”)

Now you come to the main screen. Here you will see the Platforms on the left: Android, iOS, Windows, Windows Phone, and Mac OS/macOS:

You’ll want to start by selecting the platform you want to test on the left.

Next on the right, you’ll see a bunch of devices if you are selecting a mobile platform.

Desktop Browser Testing

When you choose Windows or Mac (which are desktop platforms, not mobile ones), you’ll also need to select which version of the operating system.

Finally, choose the browser to test against. Here, let’s select Firefox version 78

Next, BrowserStack will actually startup a real (virtual) instance of macOS Catalina for you! Then it will launch Firefox browser where you can test your staging (or development) site.

Mobile Browser Testing

On mobile, the most important thing to note is that there are two kinds of testing: (1) Simulated, and (2) on-device. Simulated means a computer in the sky runs a virtual session of your mobile operating system. On-device means that a real device is actually being remotely controlled (they are controlled via connections to computers) available to you as you test. It is really the real thing— sitting in a giant data cluster somewhere— and when you load web pages on it you get the true results. Simulated results aren’t quite as good, so it’s often best to use real devices.

You can see the real devices because they have a tiny little blue “device” icon next to them:

To see the similuated environments, you click here:

see simulated environments

Local Testing, Screen Recording, and More

As a developer, you can use BrowserStack to connect to your local machine running at It’s quite easy actually, it’s called “Interactive Testing” and it works great. From any environment, you’ll have a small control panel that will let you control BrowserStack. Look for the “Local testing” option

Local Testing

You will then need to download and install some software on your machine.

Once installed, launch BrowserStackLocal

Once installed & launched, from back within BrowserStack, you’ll just go directly to

Here you can see I’m running the default Rails app on my local machine.

BrowserStack can even do screenrecording and more fancy things like Selenium testing against different browsers too.


Browseo (#3)

This tool will show you a hierarchy of particular elements as if you’re looking at your web page as though it is a web browser.

Start at

Let’s profile this website,, to see how good I am at SEO.

Browseo will tell us a whole bunch of meta-information, like our title, our Twitter card, our viewport settings. It’s good to review these because they are easily left off (which will hurt your SEO rank). You will see your SERP preview (“Search engine results pages”) — that’s how your website looks in Google and other search listings.

This tool is useful for a quick analysis to check if you’ve missed any important settings, but it doesn’t offer much in the way of content analysis.


Google Page Speed Insights (GPSI) (#2)

GPSI — Google Page Speed Insights is also a page speed optimizer, but it has fewer frills than WebPageTest and gives less information.

It does not show you all your endpoints individually, but instead gives you an aggregate score for your mobile and web speeds.

Let’s do a quick run through on the popular shoe website Zappos.

First load up and enter your URL:

Wait for Google to buid your report…

Now you will see the report:

A few things to note:

  1. GPSI uses several factors and shows you a composite score. You have separate scores for mobile & desktop, so be sure to switch to the “Desktop” tab to see your desktop score.
  2. Most websites score very low. Rarely do I see a site whose score is above 30, so if yours is low don’t feel bad. Google has very high standards for this tool.

You will see several important metrics. Here is a brief introduction.

Field data is a historical report of how a site has performed and represents “anonymized performance data from users in the real-world on a variety of devices and network conditions.” Lab data, on the other hand, is completely simulated and happens inside of Lighthouse, which is a tool Google is using to analyze your website. (A third metric is Origin Summary which aggregates all pages for the domain.)

First Contentful Paint (FCP) is the average time that it takes the browser to start painting (or rendering) the page. Largest Contentful Paint (LCP) is a measure of loading performance. First Input Delay (FID) is when your web page becomes interactive (known in other tools as “DOM Interactive”).

Read all about the details of GPSI here and be sure to read the details of the web vitals (which explains the meaning of the metrics).


Marketing July: 31 Marketing & Web Optimization Tools

July is marketing & optimization month. Every day this month I will introduce a new tool for marketing or web optimization. That’s 31 marketing, speed, QA, and automation tools!

To get these delivered right to your inbox, won’t you sign up for the email list? Hit “Page down” (or scoll all the way down) and look for “Sign up for Jason’s Newsletter.” Thank you so much!

Tools (#1)

July is marketing & optimization month. Every day this month I will introduce a new tool for marketing or web optimization. To kick things off I’m starting with the most valuable of them all: The ultimate benchmarking tool for site speed optimization.

You simply enter your URL into the bar and then wait. (Because it’s free, you are sharing the resources with everyone else. Sometimes it can take up to a minute or two to profile your site. The number of other people using the tool at the same time will determine how long it will take — like waiting in a queue while on hold on the phone.)

The first thing you’re going to see is a screen like this: — This is one of the secret tools for web page optimizers (like me!) who make your website really fast. This will break down your page’s load time (into a “waterfall” chart) showing you which external endpoints are taking longest, which ones are blocking the page, and how to speed up your site.

An excellent remote benchmarking tool with breakdowns of each of your external web requests, showing times for DNS, SSL Negotiation, TTFB (Time-To-First-Byte), Content Download. It includes critical five page-wide metrics that you need to pay attention to:

• First Byte

• DOM Interactive

• First Paint

• the all-important DOM Content Loaded (also known as $(document).ready in jQuery*)

• the also-important Content Download time (also known as $(window).load in jQuery*)  

You’ll often want to run it a few times (in fact by default it runs twice anyway). 

[*Note that jQuery is not required to be running on these websites. These are the corresponding jQuery hooks for the page rendering lifecycle associated with these events.]

This view shows you an aggregate summary. It actually runs the test three times, but usually, you get close results. In the area where you see the Network chart next to “First View,” click once.

Now you’ll come to the detail view for the measurements.

This screen is where the magic happens. There’s a lot of information on this page, and I could teach a whole course on this subject. The two most important measurements to learn about first are: First content paint (look for a light green line, not the dark green line) and the Document Complete (look for a blue line). Both are expressed as a number (and fraction) of seconds.

In a very simplistic summary: The First content paint is when the user will first see content, and the Document Complete is when they can interact with the page.

The First Byte time is largely dependent on your server architecture and your app and is beyond the scope of this article. If you have long First Byte times try New Relic as performance tool to find the bottlenecks in your app and figure out how to eliminate.

For the most part, DOM Interactive and First paint you don’t have control over, assuming your assets are correctly cached and delivered via a CDN. 

The DOM Content Loaded is what we believe to be the most significant factor in the GPSI score, but keep in mind that Google will punish you if above-the-fold content is not loaded by the DOM content loaded point, or shortly thereafter. Consider there are many seconds between the 4th and 5th measurements, your images and some Javascripts are downloading. What you want to do is prioritize the above-the-fold images first, so they appear for the user as quickly as possible.

If you do this, GPSI will favor you. If you don’t do this and your Content Download times ($(window).load) extend out several seconds, your GPSI score (and we believe Google PageRank) will drop. 

Next, you’ll need to understand how to load your Javascript, internal & external, using async and defer. Unfortunately, that’s beyond the scope of this post today.

Webpagetest is the gold standard for a reason: It gives you nice scores for: First Byte Time, Keep-alive Enabled, Compressed transfers, Compressed images, cached static content, and using a CDN. 

Caveats: I’ve noticed that WPT tends to list many ad pixels — which inherently cannot be cached– in the “Leverage browser caching of static assets” section and thus may give a lower score here if you have too many ad pixels. I’m not exactly sure why WPT isn’t smart enough to know that these are ad pixels, maybe it would be better if the ad industry moved over to AJAX requests via JSON endpoints instead (cough, cough, antiquated technology, cough, cough). Perhaps if more did then a tool like this wouldn’t see ‘pixels’ (non-visible image files that serve only to communicate with foreign servers but aren’t actually images the user sees) as cacheable resources. 

Although this optimization tool is a little complex for non-technical users, laymen marketers and site builders can easily run their site through WPT to get a sense of how fast their site is performing. Remember, it can publicly profile any website so you can run tests on your competitors’ websites too.


Found in the Twilio TOS

Presented without comment

Twilio Terms of Service
Twilio Terms of Service