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.
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 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:
Local Testing, Screen Recording, and More
As a developer, you can use BrowserStack to connect to your local machine running at 127.0.0.1:3000. 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
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 127.0.0.1:3000
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.
Let’s profile this website, blog.jasonfleetwoodboldt.com, 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.
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.
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”).
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:
WebPageTest.org — 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.
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.
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.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.