DEV Community: John Demian

Making my Laravel Development simple with Forge

John Demian — Wed, 01 Oct 2025 14:30:21 +0000

Look, I’m the type of person who likes to mess around with different side projects that never end up seeing the light of day. My GitHub looks like a graveyard of half-finished projects, and over these years of building these forgotten side projects, I’ve learned one crucial lesson: time spent on DevOps is time not spent on building cool stuff.

That might be because I am really bad at provisioning and managing my servers, or because right now it seems to be a full-time job.

That's where Laravel Forge comes in – and honestly, it's been a game-changer for developers like me who'd rather write code than wrestle with server configurations.

The Problem with Traditional Deployment

Let’s call a spade, a spade. Most of us developers didn't sign up to become Linux sysadmins. We want to build applications, not spend hours figuring out why our SSL certificate isn't working or why our database connection keeps timing out.

I used to deploy my Laravel apps the "traditional" way: spinning up a DigitalOcean droplet, SSH-ing in, installing PHP, MySQL, Nginx, configuring everything manually, and inevitably breaking something in the process. Then spending another few hours Googling error messages and questioning my life choices.

Granted, while I’m spending more time on ChatGPT rather than Stackoverflow, I still find myself searching for the same solutions to weird memory limitations, obscure firewall rules, SSL, or project settings that take the entire app down, and the list goes on. It’s just not fun.

I love this representation because I feel it's pretty accurate. Reddit Agrees

Enter Laravel Forge

Forge is basically Taylor Otwell saying "Hey, I know you just want to deploy your app without losing your sanity." It's a server management service that handles all the boring stuff so you can focus on what actually matters - your application.

LaravelForge offers a few things out of the box like zero-config server setup, dead simple deployments, stuff that you don’t want to think about like backups, server monitoring and alerts, SSL renewals, and much more.

Now I know what you are thinking, Forge is not the only solution out there. And that’s true, it’s not necessarily the right fit for everyone. Let me break down what’s actually happening in the server provisioning world and why so many of us Laravel devs keep running into the same headaches.

The DIY Route

The real issue isn’t that server management is impossible; it’s that there are about 50 different things that can silently break, and you won’t know about most of them until 2 AM and you have a flight leaving at 6:30 AM the next morning. Ok, maybe that’s just me.

The security minefield is another issue. Think about it, you spin an Ubuntu server, and out of the box, it basically screams “Hack me!”. Default SSH config, open ports you never knew existed, firewall rules that make no sense. I once spent an entire weekend figuring out a database accessibility issue that turned out to be a misconfigured bind address, so my machine kept throwing “localhost refused to connect” errors.

Then there is the environment hell where your machine runs PHP 8.2, but your server defaults to 7.4, and some obscure dependency won’t work on a newer version of PHP. File permissions are either too restrictive or too permissive. Going from “I can’t access my own photos” to “now, everyone can see my selfies” in an instant.

And even when everything else works great, there’s a dance that happens with every deployment, SSH in, Git pull, run composer, clear cache, restart queue workers, pray nothing breaks, etc. Miss one step and your app is down for good. Automate it wrong, and you’re debugging shell scripts just like our ancestors.

Saving my Sanity

The real question isn't "what's the best deployment strategy" but rather "what lets me focus on building instead of maintaining?”

It comes down to my priorities. Am I building projects because I want to learn DevOps or am I ok being ignorant and just focusing on my app?

I figured out that I spent about 25-30% of my time on operational tasks and not coding, which I did not enjoy at all.

So it became clear.

I just want things to work. I don’t care to learn the intricacies of server management as long as it just works. Forge does just that: Laravel bliss without the drama.

The New Forge

There’s a new version of Forge that’s a game-changer for developers like me.

This video covers most of the cool new things.

Instant VPS Provisioning

The biggest time saver is Laravel VPS - you can create a server directly from Forge without ever touching DigitalOcean’s interface. What took me about an hour or two is now done in 10 seconds.

This means that I can go from an idea to a live server faster than I can finish making my coffee.

Zero-Downtime Deployments

This now comes out of the box. Previously, you needed to use a separate service like Envoyer. This means that I can deploy updates during peak traffic without breaking the experience for anyone. No more scheduling deployments around user downtime periods or being scared of pushing code to production.

Enhanced Deployment Visibility

You’ll also get better tracking of what’s happening during deployments with clear visibility into which commits are being deployed, the order of the deployments in queue, and the real-time status of each deployment. And you also get full rollback capabilities if something goes wrong.

Here’s a quick video on what the setup looks like:

The new Forge essentially removes the last friction points in Laravel deployment. You're not just getting faster server provisioning - you're getting a deployment experience that matches the speed of your development cycle.

For side projects where time is your most valuable resource, these improvements mean more time building features and less time babysitting deployments. The zero-downtime feature alone makes your side projects feel more professional and reliable to users.

My two cents

Look, I'm not saying Forge is magic (though it feels like it sometimes). If you're a DevOps engineer or you genuinely enjoy server management, maybe Forge isn't for you. But if you're like me, a developer who just wants to build cool stuff without the operational overhead, then Forge is absolutely worth every penny.

Planning to launch a SaaS? You need to know this one little thing.

John Demian — Mon, 20 Mar 2023 22:47:26 +0000

While this concept I'm about to explain applies to everyone running a software as a service business, it will be of real importance to developers.

It's developers like you and I that don't really take in consideration feedback from users and kind of create this idea in their minds of how the product should feel like and then go knee deep in it without too much hesitation.

I've done this, and paid a steep price for my ignorance.

After I started Eyelet.io it got some great feedback right off the bat so I raised some money and then doubled down on the development of the product.

I wanted to build this extensive, over the top segmentation feature that would make Eyelet.io a force to be reckoned with.

Or so I thought.

There was a huge flaw in my plan. Only I was interested in that level of segmentation.

Fast forward 6 months and an outrageous amount of money spent and my segmentation feature did nothing for us.

The cruel thing about this whole story is that I knew how to avoid it, I was warned about this becoming a possibility yet I still did it anyways.

The only thing I had to do is: ask for user feedback.

Doubling down on user feedback

Once I've figured out that there a lots of other people like me I figured out how to use Eyelet in order to wrong my own wrongs, and who knows, maybe I'll ensure that one less SaaS founders follows in my steps.

Using the Eyelet bots, I've created a simple NPS survey that doubles down on the feedback aspect.

Instead of collecting a simple numeric score that represents the NPS, I'm using the actual feedback of all the previous users. This way I can gauge the satisfaction with the product or feature but also create a way to offer help depending on the most popular issues.

So if they offer a good feedback, I can ask for a review on G2 or Capterra, but if they have a bad experience, instead of ending the survey there I can provide help in the form of a product tour, a link to a roadmap or perhaps give them the option to schedule a call with our support team.

Clever, right?

Here's a video I've made on this subject, if you find it useful consider dropping a like.

Good luck, and I really hope you'll be smarter than I was.

Website speed testing - is this still a thing?

John Demian — Fri, 29 Jan 2021 14:00:40 +0000

While it might not be on the top of your to-do list, speed testing is an important part of your development process. Most people do understand this but at the same time don’t have a clear grasp of what it actually involves, what to look for and how to fix these issues.

One of the most common and obvious issues with our website is the resources that take too long to load. These can be anything from fonts and Images to different plugins and javascript files that slow down the loading of your website.

There are several ways to measure these load times and I’m going to get to these but first I’d like to cover some of the “lingo” that you might already be aware of.

Time to first byte and first meaningful paint

TTFB and FMP. Time to first byte and First meaningful paint are two very important metrics that you need to pay attention to. They will show you when your website starts loading and the second your website starts displaying information.

Load times

One of the most important aspects of optimization is the speed at which your website loads. There are lots of reasons why your website is loading slowly and one of them is your server. Measuring your** time to first byte** will let you know if you have an issue with the response time of your server.

Render-blocking code

Another reason why your website loads slowly is that you have code that blocks the rendering of your website. This could be Javascript, CSS or any other type of code that might block the rendering of the current webpage. This is one place you can’t afford to cut corners as it will directly impact the experience your users have on your website.

HTTP Requests

The next thing to look for is your requests. Every time you load a website, there are a series of requests being made to the servers. Every request will have a response and each server will have a set number of concurrent requests it can handle. The more requests you have, the more requests your server will have to deal with, and the longer it will take to respond.

These requests can be hard to track and most often than not the number of requests fluctuates up and down especially if you are working with any third-party services. To measure and keep track of these requests you’ll want to use a synthetic monitoring service like Sematext Synthetics (and here’s the shameless plug).

Getting rid of the issues

Here’s where things really get complicated. There’s no one-size-fits-all solution when it comes to website speed. Every example will have its own particularities that will make them very different from one another.

Usually, this is where I shamelessly plug the awesome tools that Sematext.com - the company I work for - offers but I’m going to try to talk about a few general ways that can help you decrease those long load time and increase your website speed.

Lower the load times

Big long times are the most popular issues that you’ll run into. Sometimes something as easy as using a CDN might help you out, other times you’ll have to start compression images and minify large CSS and JS files.

Of course, there are going to be times when even if you did this, your site will load slowly regardless, in which case you’ll have to dig a little deeper, benchmark your DNS response time and monitor your server resources.

Get rid of the render-blocking code

There are a number of ways to defer render-blocking code and I’m going to cover the top two scenarios: Javascript and CSS.

For Javascript, we can run a little script that will defer the scripts that would otherwise block the rendering of our pages. Here’s a little example:

<script> 
function deferLoadingTheCode() { 
var element = document.createElement("script"); 
element.src = "delayTheCode.js"; document.body.appendChild(element); 
} 
window.addEventListener("load", deferLoadingTheCode, false); 
</script>

All you need to do is drop this somewhere in your <head> tag of your HTML and you should be good to go.

Excessive HTTP Request

While this may not be as popular as the other issues, this too can cause a lot of head akes. Having loads of JavaScript, CSS, and image files can lead to too many HTTP requests. When a user visits your web page, the browser performs several requests to load each of these files – which can significantly reduce the page load speed.

To fix this issue you can merge the files that are going to be used on a specific page like CSS or JS files. For images there’s a simple way to optimize this using sprites.

With tools like CSSspritetool and Sprintegen, you can combine multiple images into one and display them based on CSS variables.

What’s next?

Identifying these issues is usually more difficult than it seems. While your website might be loading fine on your end, people that have different machines, connections, are from different countries might have a different experience.

The best way to go about fixing these is by using a monitoring tool that will keep an eye out for you. There are lots of different ones available from open source to SaaS, expensive to more affordable ones and features usually vary quite a bit. I’d recommend you take the time to shop around before you commit to any one tool. Here’s a little list I’ve made of the top tools for testing your website’ speed I’ve tried and how they stack up to each other.

Website Benchmarks - Everything you need to know

John Demian — Wed, 26 Aug 2020 16:39:52 +0000

Time to first byte, first contentful paint, DNS response time, round-trip time, and the list goes on and on. With all of these metrics, how are you supposed to know which are the most important ones that you should monitor?

To understand what those numbers are supposed to look like, you’ll have to get a reference point. Something that’s supposed to give you a starting point. A number that you’ll be able to compare to future results to understand if your performance improved or degraded over time. This process is called website performance benchmarking.

Why Benchmark Your Website?

You’ll want to run benchmarks on your website because having insights on how it performs will allow you to make decisions that will ensure a competitive edge. It will paint a clearer picture of where you stand compared to your competition and what areas can be improved or need your immediate attention.

What Metrics To Benchmark

Indeed, each metric can provide insights into performance and where you stand in relation to other similar-sized sites in the same industry. However, there are dozens of metrics to look at, which can make users lose focus on those that are important. To help you get started, I selected the main metrics I recommend you should monitor for benchmarking purposes:

TTFB – time to first byte, a website performance metric that tells you how fast your server responds with the first package.
Page size – the total size of all your CSS, javascript, images, HTML.
Number of requests – each time you load a file, image, or script, you’ll create a request. The more you have, the more time the server will take serving them.
First Contentful Paint – the moment your hero section is visible and fully loaded
TTI – time to interactive, the metric that tells you the moment the site can respond to user input.
Page speed and load time – this is the point where every single resource is fully loaded and can respond to user input.

I could go on for a while, but I think these are the ones you should start with. They give you a solid baseline for benchmarking and provide intel as far as any performance issues you might be having and give data to compare with your competitors.

I’d suggest making a note of the first benchmark and the values you are seeing. You’ll want to come back periodically and check against them to understand where you stand as time passes.

How To Benchmark a Website: Benchmarking Example

This process first involves finding a benchmark website to gather results against. As a starting point, HTTP Archive offers some interesting statistics about the average website’s size by content, individual response time, HTML document transfer size, and so on. However, this information is quite generic and not specific to a particular industry which may be known for fast loading sites.

This is where benchmarking tools come into play. Tools like Sematext Synthetics, our synthetic monitoring software, can help you run a wide range of tests on your website like load times, third party APIs stability, web performance across multiple devices, and much more.

Getting Sematext Synthetic set up is quite easy. After you’ve signed up for a free account, you can start adding the properties you want to monitor.

You either create a project or use one that’s already there. For this example, you’ll go with Browser Monitors. Select the regions you want your website the request to come from and hit next.

On this step, you’ll describe precisely the type of action you want to request. It can be basic such as “open the site and take a snapshot,” or go as deep as “sign in and add to cart.” Sematext offers many pieces of code as examples, so there’s not going to be a lot of fidgeting around trying to figure out the right code.

For my example I went with:

<script>

// This script loads the webpage and takes a screenshot of the loaded page.

async function testPage(page) {

  // Replace &lt;YOUR-WEBPAGE-URL> with URL of the webpage to be monitored

  await page.goto("&lt;YOUR-WEBPAGE-URL>");

  await page.screenshot({ path: 'screenshot.png' });

}

module.exports = testPage;

</script>

The last step before going Live with the monitor is setting up the alerts. These are thresholds that will trigger notifications whenever certain conditions are met.

You can have multiple conditions here and, as you might have figured it out, you have to set a threshold value for each one and hit “Create.”

And with that, you’ve got yourself all set up and ready to start benchmarking your website at a preset interval. The alerts you have set up based on the criteria selected above will send you a message the second your website starts “Acting up.” This will ensure you’ll get to have an early warning system that will let you tackle issues before they impact your users and their satisfaction level.

The dashboard will give you a bird’s-eye view of all the websites you monitor and details on their current status, latest failures, average response time, and other valuable information.

But it’s only when you start digging a little deeper that you get into the more impressive parts of Sematext Synthetics. You can look at individual tests and see how the website performed and if they meet the criteria you’ve previously established. You’ll get to see the loaded resources, the logs that were sent back and forth, details on page size, response time, number of requests, and many more.

Website Benchmarking Best practices: The Do’s and Don’ts

Just like pretty much everything else, there are certain benchmarking pet peeves that you should be aware of, little details that you should keep in mind when performing a benchmark analysis.

1. Compare with similar web pages

When picking pages, you want to benchmark against, make sure you pick similar ones. Testing a product page vs. a category page of an ecommerce website will get you some really skewed results and might not provide the valuable information you were looking for.

2. Test multiple locations and devices

Your users will use your website from different locations around the world and your website needs to be able to serve people in India just as fast as people in the US. Some may use mobile devices while others will use laptops, so keeping this in mind will provide a better understanding of how latency affects their user experience.

3. Benchmark against competitors instead of averages

Averages can be misleading when you compare sites from different industries. If you take the average page speed of google.com and compare it against your e-commerce store that has 100K+ products, it will make you think your site is way off in terms of performance even though this might not necessarily be the case.

Instead of just looking at averages, you should compare your performance with that of your competitors. This provides a real industry average that what you are probably used to.

4. Dig deeper

Load time is a good general indicator of website performance, but it might not be the right thing to look at. You’ll want to dig a little deeper to understand how your users are experiencing your website, and the first metrics to look at are time to first byte and time to interactive. After you’ve’ established these two, you can move on to others like round trip time, request numbers, etc.

5. Understand what your site “does” when you are not looking

You can’t run manual tests on your website all the time. Instead, you want to schedule these tests to make sure your performance remains consistent throughout the day. Scheduling tests at specific times and from different locations will give you a better idea of how your website performs.

6. Monitor third-party APIs

Actually, they can be trusted but as the Russian proverb goes, “Trust but verify.” So, make sure you monitor your APIs because they can heavily impact how users experience your website.

Conclusion

As I’ve already mentioned, website benchmarking, while sounding complicated, is a rather simple process that will help you establish a starting point for your performance. It will let you know the baseline you’ll have to work with and help evaluate your website with that of your competitors.

A thorough benchmark analysis gives you all the information you need to optimize your site by pinpointing exactly where the problem areas are.

Sematext Synthetics is an awesome benchmarking tool that will help you figure out where you stand compared to your competition, figure out performance vulnerabilities, and prevent bad user experience. All this starting at just $2/month and a 30 days trial period for you to test it out!

Read this blog post to learn more about how Synthetics works and why you should use it. Furthermore, we’ve created a few articles that will shed more light on how to speed up and improve your site’s overall performance:

Previously published at https://sematext.com/blog/website-benchmarking/

Website Speed Optimization: Tools & Best Practices

John Demian — Tue, 11 Aug 2020 10:37:39 +0000

There are a lot of reasons why people choose to shop at one online store over another or pick one streaming service over another from the type of service they are getting to pricing, quality and, you’ve guessed it from the title, speed. The speed to which I’m referring is the speed at which the website loads and reacts to user input and in one of my previous articles I’ve talked about how big of a difference even a two-second extra delay makes.

In this article, I will go over some of the speed testing basics like the metrics you need to watch out for and the tools you’ll need to test and track speed issues and performance. The list will include the best website testing tools that are both free and paid and I’ll be sure to mention which is which.

How Can Website Speed Testing Tools Help?

I believe it’s important to understand exactly how speed testing can help you in delivering a better experience for your users so I figured I’d come up with a list of the most common metrics to measure for and issues to measure.

Resources that take too long to load. These can be anything from Fonts and Images to different plugins and JS files that slow down the loading of your website.

TTB and FMP. Time to first byte and First meaningful paint are two very important metrics that you need to pay attention to. They will show you when your website starts loading and the second your website starts displaying information.

Load time, number of requests, and page sizes. You’ll want to keep an eye on these as they can dramatically increase the load time of your website.

HTTP Headers. HTTP headers is how servers communicate with the server by sending information back and forward via a request or response. You’ll need to test these responses and requests to make sure you are getting and sending the right message between the two. This also comes in handy when you are trying to debug different errors you might have.

Website Speed 101: Basic Concepts to Get Started

Before we dive in the list of tools we’ll use to optimize our website, I think we should take a second look at the basic concepts behind website speed optimization.

Big load times

One of the most important aspects of optimization is speed at which your website loads. There are lots of reasons why your website is loading slowly and one of them is your server. Measuring your time to first byte will let you know if you have an issue with the response time of your server and if that’s the case then I might suggest you look towards a CDN to help you solve this particular problem.

Render-blocking code

There are a number of ways to defer render-blocking code and I’m going to cover the top two scenarios: Javascript and CSS.

For Javascript, we can run a little script that will defer the scripts that would otherwise block the rendering of our pages. Here’s a little example:

<script> function deferLoadingTheCode() {
var element = document.createElement("script"); 
element.src = "delayTheCode.js"; 
document.body.appendChild(element); 
} 
window.addEventListener("load", deferLoadingTheCode, false); </script>

All you need to do is drop this somewhere in your <head> tag of your HTML and you should be good to go.

The next part to tackle is CSS. With your CSS the goal is to get it as small as possible and there are two ways to do it, one would be to remove all the unnecessary classes and either remove them altogether or move them to a different CSS file that can be loaded on other pages or after the critical content of the page has loaded.

The second thing you could do is minify your CSS file. This is a process where you take the unnecessary characters from your files that would otherwise take up space thus taking longer to load. Minifying doesn’t only apply to CSS, you can also remove the unnecessary characters from Javascript and HTML too. The characters I’m referring to as unnecessary are whitespace characters (thing spacebar and the enter key), comments, and block delimiters. Most often then not developers use a piece of software to get this done.

HTTP Requests

These requests can be hard to track and most often than not the number of requests fluctuates up and down especially if you are working with any third party services. To measure and keep track of these requests you’ll want to use a monitoring service like Sematext Synthetics. With a simple setup, you can track the overall number of requests, load time, responses, and much more. We’ll talk more about Sematext Synthetics in a second.

But it’s time to get to the main event. The reason why you are here in the first place, the top website speed testing tools you can use right now. Without further ado, let’s jump right in.

The 10 Best Website Speed Testing Tools

Now that you got the basics of website speed testing, here are some of the best tools to help you test page load and improve website performance.

1. Sematext Synthetics

While still being new to the Sematext Suite, Synthetics has quickly become a favorite amongst our users. It’s simple yet reliable and you can monitor the availability of your APIs and websites from multiple locations across the globe, measure performance across devices and browsers, and identify issues with third-party resources.

Getting started is really easy and only takes a couple of minutes before you start to actually monitor your resources with the help of the intuitive UI. You can set up different conditions that will trigger an alert so you’ll be immediately notified when something goes wrong.

Sematext Synthetics comes with a 14-day trial and plans start from $29/month and offers 40 HTTP and 5 browser monitors with data retention of 30 days. Of course, this can all be customized to fit your needs but that’s not all. You can also choose to go with the Pay-as-you-go plan which lets you set up individual monitors for $2/month.

Read more about how Sematext Synthetics can help monitor your APIs and website.

2. Google PageSpeed Insights

For years Google PageSpeed Insights has been the goto tool for testing and grading your website. It’s a simple tool created by Google that benchmarks websites and grades them on a scale of 1 to 100 for both mobile and desktop. The higher the number, the faster the website is.

The UI is quite easy with only one input field for the URL. Once the test is run you’ll get detailed information about things like render-blocking code, TTFB, page sizes, and more. Under each section, you’ll get a list of recommended paths of action that should help speed up the website.

While many other tools in this list allow you to customize requests, set up alerts, and select different locations to run your tests, Google PageSpeed Insights will not give you those options. On the other hand, it’s completely free and doesn’t require registration.

3. Pingdom Speed Test

Pingdom is another well-known website speed test tool that’s been around for ages. It requires no login to use and the reports are less detailed then what you’d get from Google PageSpeed Insights. The site’s performance is graded from 0 to 100 and then has a breakdown of the response codes, content size, request types, requests by domain and a waterfall chart that lets you see details on your files load times.

Their free tool allows you to run a single test from any of their 70 locations and if you sign up to their Synthetics solution which starts at $10/month for 10 uptime checks you can set up page speed monitoring as well as alerting.

4. WebPageTest

WebPageTest.org is an open-source website performance testing tool that allows you to benchmark your website from one of their 40 locations and a wide range of devices. You can also choose to simulate your tests over a slow mobile network or a fast 4G network. The result will be graded from F to A and will include information on compression, TTFB, caching, waterfall charts for the resources load speed and more.

It also features a rather special test where they run a test 3 times and displays all three data sets. This helps figure out if the DNS or CDN might cause any delay and if the server can respond to all requests.

5. GTmetrix

GTmetrix allows you to get detailed information on your page speed, timings, performance score and much more. GTmetrix also provides information about how to fix the issues that were exposed by the test.

Without registering you can only run a test from one location Vancouver, Canada but after you sign up for a free account you’ll get to choose your location, different browsers and even the connection type. This should paint a better picture of how your website works in different scenarios.

6. Varvy Pagespeed Optimization

Varvy PageSpeed Optimization is a free tool that tests your website performance and provides tips on how to create a better experience for your users. It was created by Patrick Sexton, who also created Getlisted.org.

Varvy PageSpeed Optimization breaks down your report in 5 sections describing the general summary of the test, a resource map, details on CSS delivery, Javascript usage, and a number of separate information on Image Optimization, browser caching, compression and server response.

7. Uptrends

Uptrends offers a straightforward test from one of 10 locations and you can configure the test to run either from a mobile device or a desktop. For the desktop test, you can also pick the resolution of the screen one of four browsers ( Chrome, Firefox, PhantomJS, and IE) and bandwidth throttling to test the site under different speed scenarios.

There usually is a little quiet and there are no alerts that can be set up with the free version of the test but if you sign up for their Uptrends Synthetics product, you’ll get all of those plus more for $12 a month for 10 basic monitors, RUM and 60 message credits.

8. dotcom-monitor

With dotcom-monitor, you get 25 different locations and 7 different browsers that include Blackberry, which should make me think they really need to update their service or perhaps they are historians.

After you run the test you’ll get graded based on your load time and get details on your server responses. You’ll also be able to check what a repeat visit looks like for someone that comes to your website a second time and has already cached resources on their machine. You’ll also get a detailed page speed insight report generated by Lighthouse.

9. Site 24×7

Site24x7 is a simple product that offers a free alternative to Pingdom. Their “Free Forever plan” offers 5 monitors with email notification which is probably enough for any small website.

Their premium plans start at $9/month (paid annually) and get you 10 monitors and 1 synthetic web transaction, status pages, 500mb of logs, 100K RUM views, and over 110 testing locations scattered across the world.

10. Google Chrome DevTools

If you are developing your website with Chrome then most likely you are already familiar with it. It’s a simple tool that lets you see a waterfall timeline with all your resources and details on what’s costing you precious load time.

To access it you need to have Chrome installed (dooh) and then you open it up pressing F12 if you are on a windows machine or CMD + Option + I if you are using a MAC.

There’s no alerting, no fancy location picking options but it’s free and comes with your browser and requires no login or registration whatsoever.

Conclusion

As you can probably there are a lot of options to choose from, each with their unique feature and it’s up to you to test them and figure out which one works best for you. I think it’s worth noting that speed testing is something you should be doing long after you’ve finished developing the website. Over time things will change especially if you are using third parties APIs and you’ll want to stay on top of any changes that might happen in the meantime.

Once you know where the bottlenecks are you can begin to fix them. Check out our post with tips to help improve website speed performance to get started. For full range visibility, explore our curated selection of the best website monitoring tools available today and check out Guide to alerting and monitoring to learn how to pick the best monitoring software for your particular use case.

Originally posted on Sematext.com, July 23rd 2020

20+ User Experience (UX) Metrics Every Product Manager Should Measure

John Demian — Mon, 18 May 2020 00:41:32 +0000

User experience (UX) is everything today. Poor digital experience can easily and quickly reflect in your client list and thus, your bottom line. It starts from the first user interaction with your website or webapp and ends with… well, it never quite ends. User experience is, in fact, a continuous process that goes on and on until the user decides to stop using your product. That’s probably why the number of potential UX metrics is ever-growing and now there’s a lot that you can track.

To successfully measure user experience you need to monitor both usability and business KPIs, from real user to engagement, usability, adoption, as well as retention. Still, while looking at the bigger picture, the key is to select the right metrics to keep tabs on and optimize to improve user interactions and overall satisfaction with your website or webapp. With the help of UX performance indicators, you can quantify and calculate the ROI of the changes you’ve brought to your product in terms of experience, which is otherwise impossible.

In this post, we are going to explore what are the most important UX metrics you should monitor to ensure flawless user experience.

How Are UX Metrics Defined?

There’s no universal recipe for what metrics are best. It all depends on the industry you are in and your business goals. You need to choose the ones that will help you measure your progress and that impact the decisions the most.

UX metrics measure a product’s user experience. Unlike other types of metrics such as sales, finance, or marketing, they are difficult to quantify since they reflect human behavior and attitude. Big brands such as Google, Airbnb, or YouTube use UX metrics to improve the user experience of their products to keep their customers happy.

This data is hard to translate into numbers, but there are some useful frameworks that made it possible such as Forrester’s Customer Experience which groups these metrics into three main categories:

Descriptive metrics that provide information on what happened and include usability and real user monitoring metrics.
Perception metrics that show how customers perceived what happened and are illustrated by engagement metrics.
Outcome metrics that describe what customers did or expected to do based on their perceptions. This category includes adoption and retention performance metrics.

Here is an example breakdown of the most important UX metrics to track, impacting each category:

1. Real User Monitoring Metrics

Real User Monitoring (RUM for short or end-user experience monitoring), which you can read all about in our RUM guide, is a technology that allows you to monitor and analyze your customers’ experience throughout your website or application and see exactly how they interact with it. It enables you to see everything from HTTP requests, crashes, timeouts to Apdex scores that speak to your users’ satisfaction with your product or service.

There are many benefits to using a RUM solution as every little deviation from optimal performance across locations or devices can have major consequences to your bottom line. Not only that, but by implementing RUM in your business will help your developers have an early warning system that will tell them when things start to go sideways by setting alerts for things like Apdex metrics, page load times, timeouts, and errors, etc.

You’ll have actionable insights about what’s affecting your users’ experience with your product and have the option to fix the issue before you have a catastrophic failure.

There are several important RUM metrics you need to consider for your webapp in order to ensure optimal performance for all your users:

Apdex and User Satisfaction Score

User Satisfaction Score or Apdex is a measurement of your users’ level of satisfaction based on the response time of request(s) when interacting with your website or application.

The way you calculate it is quite simple based on the Satisfied count which is the number of requests, the tolerating count which is the number of requests, and the Total samples is basically all your requests.

HTTP Requests

Load times are extremely important to monitor as they directly impact how your users perceive your service and that will influence their decision whether or not to become customers.

Based on the number of your separate requests and their response time, the load time for your webapp can be influenced dramatically.

Sematext as a RUM solution

Sematext Experience, our RUM solution, will give you insights into your load times by breaking them down into small components, providing a birds-eye view of what influences your app speed.

A simple screen will tell you exactly where your system is underperforming and where is the most room for improvement.

Apdex is also a big part of Sematext, it’s how we tell if the website is raising to customer expectations. You’ll be able to set up simple alerts that will notify when your users’ satisfaction is below a certain threshold so that you can take the necessary steps to correct the issue.

Learn how Sematext compares to other tools from our blog post where we covered the best RUM solutions available today.

Understanding how your service caters to your worldwide audience is going to be a crucial aspect of your business. Within the Geography tab, you’ll be able to tell exactly which regions your users are having a difficult time loading the app or what type of device/connection isn’t working as expected.

2. User Engagement Metrics

Different user experience engagement metrics give you great insight into how hooked users are with your website, from the frequency of usage to depth and volume of usage. They show what users are or aren’t interested in so that you can make quick changes and avoid mistakes that could drive them away. Check out some of the most important engagement metrics you should keep track of to improve user experience.

Unique Visitors

Unique visitor is a term used to describe a person that visits a website at least once during the reporting period. The unique visitors metric is the number of distinct visitors visiting a page or multiple pages on your website in a given time.

New vs Returning Visitors

New visitors are users who are navigating to your website for the first time on a specific device.

Returning visitors are those who have previously visited your website. Google considers returning visitors as those who have returned from the same device within a two-year time frame. If a user visits a website after more than two years, then it’s counted as a new visitor. A low number of returning visitors can be a sign of poor user experience or that your product fails to deliver to its promises.

This metric is presented as a pie graph, comparing the ratio between the two. You should always have an influx of new traffic – 50-70% is a good range, but as usual, it depends on the industry you are in and what are your website goals. A higher level of new visitors equals higher revenue – as long as your returning customers are returning.

Pageviews

When it comes to measuring website traffic, you want to look at pageviews.

Pageview is the engagement metric measuring how many times users have accessed a particular page on your website within a given time frame. A higher number of pageviews could be a sign of interest, but it can also indicate that people are surfing your website without finding what they’re looking for. That’s why you need to look for context and correlate pageviews with other engagement metrics that we’ll discuss below.

Time on Page

There are two ways to look at time spent, both just as important: time spent on page and session length.

Time spent on page measures the time a user spends on a page on your website. It indicates interest, the more time users spend on the page, the more engaged they are and the better they like your content.

Session length is the amount of time a user spends on your website from the moment they land on a page until they exit, or in between the first interaction the last on that they perform. Longer sessions indicate higher engagement. However, shorter session duration is not necessarily a bad sign. Ir could actually be a good thing, indicating that users have found what they were looking for. As mentioned earlier, it’s important to look at the bigger picture and see what other engagement performance metrics tell you.

Pages per Session

Pages per session is the average number of pages viewed during a session on your website. More pages visited means that users are exploring more of your site and are more engaged. Knowing what users are doing on your website and what pages they are looking at makes it easier for you to detect user experience issues and see how certain parts of your website or webapp are performing.

Conversion Rate

Customer engagement is key for driving conversions and overall profitability. So if your website or app feature desired actions you want users to take, such as signing up, filling up a form, making a transaction, etc., you’ll want to measure how many users are completing these steps or are getting converted.

Thus, the conversion rate is the percentage of users that follow a set of directions you want them to perform. This metric also allows you to see where users are dropping off in various stages of their experience navigating your website.

3. Usability Metrics

Usability metrics reflect users’ behaviors, telling you what they actually do on your website, as well as how easy it was for them to accomplish what they were set to do. This is the most common category of success metrics that UX teams are already tracking. Let’s see which are the main usability metrics you should use to monitor user experience:

Task Success Rate

Task success rate, or task completion rate, is the percentage of users who have successfully executed a task. You can only measure the success rate if you are very specific as to what the end goal is, whether it’s to fill out a form, buy a product, etc.

Although it says nothing about why users fail, task success rate is a good indicator to start measuring user experience.

Naturally, users may have some difficulties when first using your product. It’s best that you measure success rate on going as they gain more experience. It will give you an idea about your product’s learning curve, which is a great indicator of user experience success. You want the success rate to be as high as possible.

You can calculate task success rate by dividing the number of correctly completed tasks by the total number of attempts.

Time-on-Task

Time on task, or task time, or task completion time, is the average time a user needs to complete a task successfully. It’s a useful metric as it tells you how certain actions affect user productivity, which usually plays a big role in how satisfied customers are. Needless to say, the shorter the time, the better the user experience.

This metric helps you understand how efficient your architecture and navigation are. The navigation bar is one of the most important elements of a website or webapp and should be intuitive enough so that people can easily and quickly reach their destination. If that’s not possible and they get lost, they turn to the search bar. In most cases, the less the search function is used, the better.

You can calculate the Navigation vs. Search ratio by dividing the number of tasks accomplished via navigator or search by the number of completed tasks.

User Error Rate

The user error rate is the number of users who made a mistake while doing a task, such as navigating to the wrong part of a website or an unsuccessful attempt to enter the email address in the contact form. It’s a good indicator of user performance as well as for how user-friendly your website or webapp really is. Errors are closely related to usability issues. In fact, usability is the source of errors, so a high error rate means that you have serious usability problems. However, you need to be very specific as what actions are perceived as errors,

There are two ways to calculate the error rate, depending on the number of error opportunities a task allows and what you need to measure. For example, filling in a form has many opportunities for failure.

If your task has only one potential error or there are many error opportunities but you want to track only one of them – for example when entering the email address in the “Repeat email address” field – you want to measure the error occurrence rate by dividing the total number of errors that occurred for all users by the number of error opportunities for all users.

If there are multiple error opportunities per task or you want to measure multiple errors, you can calculate the error rate by dividing the number of errors by the total number of attempts.

System Usability Scale (SUS)

The System Usability Scale (SUS) is one of the most popular tools used to assess the usability of a product. It’s a questionnaire consisting of 10 statements that users need to rate on a five-point scale from strongly agree to strongly disagree. SUS is a way to quantify qualitative data, like a user’s perceived satisfaction of a product or service following a usability testing or after they have used the product.

At the same time, you can use it as a benchmarking tool against the product before improvement or in comparison to competitors. Based on the answers, you get a score between 1 and 100. The higher the score, the better the usability.

Source: The Journal of Usability Studies

4. User Adoption Metrics

By measuring adoption metrics, you can see how often customers are using your product, which features they are using and what they are doing with those features. In a nutshell, you are trying to see if users are experiencing value from their investment. This is critical information for successful customer management and for product managers as it helps them understand how to evolve the offerings. Needless to say, a higher adoption rate means that more individuals are adopting the product than abandoning it.

Here are the most important adoption metrics that measure customer product engagement:

Active Users

The number of active users is the most basic – and straightforward – of adoption metrics. For a better understanding of your product or service usage, you should go further and measure Daily Active Users (DAU), Weekly Active Users (WAU), Monthly Active Users (MAU), and stickiness (DAU/MAU).

As a rule, the number of active users should be higher than the number of new users, indicating that you have returning users. However, first you need to define what “active users” mean as in how many times do users need to interact with the product within a certain time frame.

Stickiness is another key metric. Combined with the feature adoption rate (see below), you can easily identify which features make your product addictive, which drive the most engagement.

Product Access

The most immediate way to see if your product or service is bringing value to customers is if they incorporate it into their everyday lives or, in other words, how often do they access said product.

You can track product usage through license utilization. By measuring the number of daily product logins against the number of licenses purchased by a customer you can determine how often they are using your product on a regular basis. This helps your customer success team identify active and at-risk customers so that it can quickly intervene with personalized and more rewarding experiences.

Average Time Spent with Product

Another way to measure adoption is the average time spent with the product. You can calculate this metric by dividing the amount of time spent in the product by the number of logins within a specific time period.

Feature Adoption Rate

Besides tracking overall product usage, you can zoom in and focus on the time spent using specific features to identify how helpful said feature is for a certain customer or for your entire client database. You can calculate the feature adoption rate by dividing the number of times a feature was used by the number of logins.

5. User Retention Metrics

Retention refers to how many customers keep using your app, product, or service. Thus, retention metrics reveal how well you are meeting user needs and whether you are providing a good customer experience.

Check out which are the key customer retention metrics you should keep track of.

Customer Churn

Customer churn rate is the percentage of customers that have stopped using your product or service over a given period. There is no universally accepted “good” churn rate. It depends on the industry your business is in. If you’re a SaaS and servicing B2B customers, you’ll likely experience lower churn rates. But if you’re offering consumer services such as entertainment services, your churn rate can be significantly higher especially if your offering is not seen as essential.

One thing is for sure: regardless of your industry or market, you want your churn rate to be as low as possible. Otherwise, a high churn rate indicates that your product or service fails to meet customers’ expectations or goals, whether it’s in terms of features, user experience, or something else.

Net Promoter Score

Net Promoter Score (NPS) is a qualitative retention metric that measures general satisfaction and loyalty to your product or service. It tells you if your current customers are happy and how willing they are to promote you to their network. A high NPS guarantees visibility in front of potential customers, while a poor score is an opportunity to tackle satisfaction problems and improve customer satisfaction before it’s too late.

You measure NPS by asking your customers a simple question: from a scale of zero to ten, how likely are you to recommend our product or service to a friend or colleague, with zero being ‘not likely at all’ and ten being ‘extremely likely’?

Users giving a rating of 6 or below are called detractors, while the 9’s and 10’s promoters. Then, you calculate NPS subtracting the percentage of detractor responses from the percentage of promoter responses.

Customer Retention Rate

Customer retention rate is the percentage of customers that have stayed with you over a given period of time. This is perhaps the most important straightforward retention metric showing whether your retention strategy is working or rather if users are satisfied enough by your product to come back. Of course, the higher the retention rate, the better.

To calculate the customer retention rate, you subtract the number of acquired customers throughout a period from the number of customers at the end of the period, then divide it by the number of customers at the beginning of the period.

Average Order Value

Average order value (AOV) is the average amount of money a customer spends per purchase. If you provide a good UX, the average order value can increase, with more services or products being shopped for together.

To calculate AOV, you divide the total revenue by the number of purchases.

Customer Lifetime Value

Customer lifetime value (CLV) is a revenue metric that projects how much revenue the average customer will bring you over the course of their relationship with your product or service. You want your CLV to increase or at least stay constant.

This metric is important because it enables you to understand not only how much revenue your product returns, but it also offers valuable insight into user engagement and user retention.

CLV is a bit harder to measure than other metrics as it involves multiple steps. First, you need to determine the average order value you can expect from a customer over the course of a year by dividing the annual gross revenue by the number of purchases.

Step two is to calculate how many times a customer will purchase from you within a year by dividing the number of orders by the number of customers. You then estimate how long you expect a customer to stay with you in terms of years.

The final step is to multiply the average order value by the number of purchases.

Why You Should Measure UX Metrics

There are many reasons why you should rate your website or webapp user experience metrics. We’ve identified some of them:

Alerting

UX metrics act as an early warning system that something is off with your product or service. When combined, you have tons of accurate and valuable information at your disposal that makes it easy for you to spot the weakest points so that you can quickly intervene, as well as your strongest so that you can leverage them.

RUM tools, such as our Sematext Experience can help stay ahead of problems. You can define threshold time for website performance metrics such as page load times, HTTP requests, individual on-page transactions, etc. and be notified in real-time whenever these move past their limits.

Context

UX metrics provide context for the numbers from analytics. They allow you to track and map customer journeys and make correlations between user interactions, thus filling in the how, why, when, and where things went wrong.

Final Thoughts

User experience is more than how user-friendly is your website. It looks at what people see and experience with your product, how they perceive and engage with it, and finally, what they do, and how that reflects in your ROI.

It may prove difficult to measure and the metrics will vary from business to business. However, you should be looking at metrics coming from each step of the framework (descriptive, perception, and outcome).

It all starts with real user metrics – a solution like Sematext Experience can help detect early on when users experience issues due to poor website performance. If their first interaction with you leaves much to desire, most likely they’ll bounce and all your previous marketing efforts would be in vain. Make sure you look at the bigger picture and include all types of UX metrics in your UX strategy, choosing the right ones for your business. Make sure you understand and correlate them to determine the context, and then optimize accordingly. This list should be a nice starting point.

However, we recommend you don’t stop there. Website performance is a complex topic that can be a pain without the proper monitoring tools. Dive even deeper and correlate your UX metrics with other critical site performance metrics to get the full picture of factors that can negatively impact customer experience and, ultimately, your business.

Photo by Miguel A. Amutio on Unsplash

How Server Location Affects your Users’ Experience

John Demian — Mon, 13 Apr 2020 13:50:00 +0000

So you finally launched your service worldwide, great! The next thing you’ll see is thousands and thousands of people flooding into your amazing website from all corners of the world expecting to have the same experience regardless of their location.

Here is where things get tricky.

Delivering the same amazing service to different regions of the world is a challenge that most companies face, a challenge that’s difficult to solve without proper tooling, such as Sematext

Sematext Experience is a RUM solution that provides insightful data about how your webapp is performing in all the different corners of the world by measuring data in real-time directly from your users. Read more about real user monitoring and how it can help improve customer experience in our RUM guide.

In this post, we are going to see how server location affects your website performance and how you can measure it to ensure a flawless experience for all your users.

Server Location and Application Performance

There are no two ways about it. Your app will react differently based on your user’s location and it has to do with something we call server latency.

The experience of your customers living in a different part of the world will be vastly different from what you are seeing in your tests. It’s crucial to gather data from every location that your users live in, that way you can take the necessary steps to fix the issue.

What Is Latency?

Latency is the time it takes for a request to travel from the sender to the receiver and for the receiver to process that request. In other words, it’s the time it takes for the request sent from the browser to be processed and returned by the server.

Consider a simple e-commerce store that caters to users worldwide. High latency will make browsing categories and products very difficult and in a space as competitive as online retailing, the few extra seconds can amount a fortune in lost sales.

Why Should You Measure Network Latency?

Providing an overall good service across the world is not just good for your image, it’s good for your business. You’ll soon come to realize that bad user experience will affect your bottom line directly.

Source: fastcompany.com

To use the eCommerce example again here is a little quote from Yoast that will put things into perspective:

79% of online shoppers say they won’t go back to a website if they’ve had trouble with load speed.

And let’s not forget that fast-loading sites have higher conversion rates and lower bounce rates. So it’s not a matter of whether you should or shouldn’t invest in optimizing your load speed across multiple regions, but rather if you can afford not to.

What Causes Network Latency

There are thousands of little variables that make up your network latency but they mainly fall under one of these 4 categories:

Transmission mediums - Your data travels across large distances in different forms, either through electrical signals over copper cabling, light waves over fiber optics. Every time it switches from one medium to another a few extra milliseconds will be added to the overall transmission time.
Payload - The more data gets transferred the slower the communication between client and server.
Routers - Take time to analyze the header information of a packet and, in some cases, add additional information. Each hop a packet takes from router to router increases the latency time. Furthermore, depending on the device there can be MAC address and routing tables lookups.
Storage Delays - Delays can occur when a packet is stored or accessed. This results in a delay caused by intermediate devices like switches and bridges.

How to Measure Network Latency?

Network Latency is always measured in milliseconds (ms) and exposed through two metrics - Time to First Byte and Round Trip Time. You can use either of them for the test on your network. However, regardless of what you choose, make sure to keep all records in the same test category. It’s important to monitor any changes and address the culprits if you want to ensure a smooth user experience and keep your customer satisfaction score high.

Time to First Byte

Time to First Byte (TTFB) is the time the first byte of each file reaches the user’s browser after a server connection has been established.

The TTFB itself is affected by three main factors:

The time it takes for your request to propagate through the network to the web server
The time it takes for the web server to process the request and generate the response
The time it takes for the response to propagate back to your browser.

Round Trip Time

Round Trip Time (RTT), also called Round Trip Delay (RTD) is the duration it takes for a browser to send a request and receive a response from a server. RTT is perhaps the most popular metric involved in measuring network latency and it is measured in milliseconds (ms).

RTT is influenced by a few key components of your network:

*Distance *– The bigger the distance between server and client the longer it takes to get the signal back
Transmission medium – The medium used to route a signal
The number of network hops – Intermediate routers or servers take time to process a signal, increasing RTT. The more hops a signal has to travel through, the higher the RTT.
Traffic levels – RTT typically increases when a network is congested with high levels of traffic. Conversely, low traffic times can result in decreased RTT.

Using RUM Tools to Reduce Latency

So you’ll be dealing with a userbase that’s spread across multiple continents, you understand the importance of keeping your performance in good standing regardless of the user location and you even understand what you need to look for. All there’s left is the “how” part.

In the past few years, the popularity of RUM tools grew exponentially as a byproduct of the increased number of companies that took their services and products globally. An ever-growing need to monitor and understand user behavior led to a lot of monitoring companies switching from just monitoring server resources to looking at how users experience the website.

We’ve created Sematext Experience as a response to that very need. The tool offers a real-time overview of your users’ interactions with the website, allowing you to pinpoint exactly where your system is underperforming. Here’s a little youtube video of the Sematext Experience demo.

Besides providing key information on how the website is performing across different locations, it will also provide intel on how the website loads on different devices running at different connection speeds.

Final thoughts

Understanding how the users’ experience is always going to be crucial as it will influence whether or not they will return to the site or not which in turn, will directly impact your bottom line.

In case you’re interested in some other important metrics that affect website performance, you can check out this blog post.

Is everybody switching to serverless in 2020?

John Demian — Fri, 10 Jan 2020 18:24:46 +0000

Probably not, but at least a handful of Fortune 500 will take the serverless route.

2020 is already well underway and businesses all over the world are gearing up for a new year full of unpredictable moments. Now these last years we've seen technology change at a rapid pace and it seems like we are getting bombarded with new things before we even got a chance to get used to the "old" stuff.

AWS Lambda is still new to most of us and while we do understand how it can save companies a lot of money or how it's a great way to develop applications faster and with less risk, and how serverless mitigates the technical debt that plagues so many companies, there are still plenty of unknowns and to top it off, there are new services being released all. The. Time.

Here are some of the most important things to happen in the serverless space back in 2019

Source

Serverless adoption is growing at an alarming speed and we have companies like Amazon to thank for that. Their continued effort to improve and develop this space as well as the new tools we get is what draws in thousands of developers. Here are the ones that were announced only last month.

Lambda: Provisioned Concurrency

Cold Starts have been an issue since Lambda was launched, years ago. Many attempts by the development community have tried to mitigate it with various degrees of success. Now AWS launched Provisioned Concurrency.

S3: Access Points

Instead of concentrating all bucket access policies in a single place, AWS S3 now allows distributing access rules across multiple Access Points.

Fully Managed Cassandra

Although DynamoDB is a perfect fit for serverless applications, many teams and companies have been wary of using it due to lock-in fears.

API Gateway: HTTP APIs

On top of an HTTP proxy service, API Gateway offers a wide range of features: API Keys management, SDK generation, throttling, etc. All these extra features come with a cost, until now. This new feature will have users pay a third of the price they used to pay while still getting all the amazing features that they have grown used to.

Serverless Machine Learning

AWS announced three new serverless machine learning offerings. Click on the links below to read more details in the official announcements.

My buddy Renato made a detailed post on all of these plus many more here.

2019 was amazing but I suspect this year we'll get to see even more companies switching to serverless and even more developers building amazing things.

How to enjoy these holidays like a pro.

John Demian — Thu, 19 Dec 2019 13:49:20 +0000

The holidays are coming and between dinners with the entire family and shopping for last-minute gifts, there will be less and less time for keeping your eye on those precious Lambdas, especially with all that delicious eggnog laying around.

So what are you to do? Easy. Set up alerts.

Sure you can use Cloudwatch to set up alerts and it will probably do the job, at least for the most part but if you are to really enjoy the holidays you need to know beyond a doubt that your app is not only running but running at peak performance.

This is where Dashbird comes in. It will give you the peace of mind of knowing your precious applications are running smoothly the entire time and the best part, you can start using it right now, for free!

Here’s how you set it up.

1. The signup

This is obvious but I feel like I should go through this step in order to make this little guide as complete as possible. To begin with, you should jump over on the registration page and fill your information.

The next step is probably the most complicated step of this entire thing and it’s where you deploy Dashbird’s client-side code to your AWS account.

It sounds more complicated than it actually is and the import process should be around 2 minutes but in some rare cases, it may take more time to discover resources.

2. Understanding how Dashbird alerts work

I want to take a second to explain how our alerting system works. The first thing you do is you set up a policy for the type of alert you want. After you’ve created a new policy there are certain criteria that you select that will trigger the alert when those parameters are met.

You can configure your alerts based on these parameters:

Type of request (invocations in general, cold starts, errors, etc)
Metric (cost, duration, memory usage, etc)
Inequality operator (above or below a certain threshold)
A given number to compare against the metric monitored
Aggregation factor (sum, average, minimum, maximum)
Time-period to look for the comparison (last minute, 5 or 10 minutes, for example)
Target Lambdas (to which functions this policy should apply - can be all your Lambdas)

3. Set up your first Alert

You add a new Policy from the right side of the screen with the “+ ADD” button. Select either a function or a project depending on what your target is and then you go through the parameters and you are done.

When selecting the target, keep in mind that you can target a project rather than Lambdas. This is especially helpful when having multiple microservices. With Dashbird’s Projects, you can bundle multiple functions, effectively allowing you to track a subset of your infrastructure like a microservice, for example.

4. Selecting the alerting channel

As of today, Dashbird Alerts can be received via two channels: Slack and email. You can pick the one that works for you from the top section of the Policy screen.

I've made this little video that will guide you through the entire process.

5. Enjoy the holiday

That’s it. Now you’ll get notified whenever something goes sideways or if you’ve set up your alerts correctly when something is about to go wrong.

Technical debt is changing the way we build applications

John Demian — Tue, 26 Nov 2019 23:50:13 +0000

“Technical debt” is a term that scares even the most experienced developers because they know, it’s something they will eventually have to deal with at one point in the future. It’s not a matter of if, it’s a matter of when. Paul Johnson put it very plainly in an article earlier this year.

*Today’s code is tomorrow’s technical debt *- Paul Johnson

The technical debt we’re talking about is the price you pay for choosing to go the faster route rather than to spend the extra time to write the code that would be more flexible and more manageable. The debt is the time it takes to rewrite and reiterate parts of your applications.

Just like financial debt, technical debts accrue interest over time. That interest is manifested in a number of ways and can be consequences.

An example would be the lack of inability to use certain npm modules because you worked with an outdated one and didn’t want to spend time making the upgrade with everything it involved. So you figured you’d keep it as is and deal with it later.

But now you are stuck with an old Hugo version and can’t upgrade because it will break your circleCI integration and you won’t be able to deploy to production and make all the other modules useless. And there’s the documentation that’s outdated just like everything else and now you are stuck in a hole that takes a lot of modification to make to the point you might want to start from scratch, but that ain’t happening because there’s no “budget for something like that”.

That. That is technical debt interest manifested into a little project that a “friend” of mine is dealing with.

Technical debt changed the way we build applications

I started working as a developer at a small company that didn’t really worry about technical debt(at first). We eventually ran into an issue where we had to swap out our entire application that was built on Action Script 3.0 and have it migrated over to a whole new Javascript-based application.

In that particular example we had to make the switch because Flash was dying fast but most of the time, technical debt comes in a more unexpected way. Even if you started out planning ahead for it, even if you took all the necessary precautions to avoid it, technical debt is going to bit you in, as the French call it, rear-end.

There are certain ways to mitigate the technical debt in an application, more or less effective. One of these solutions to this issue is serverless computing as an alternative to the traditional model of building applications.

Here are a few reasons why your development team should consider using serverless architecture in your next mobile app or web application in order to manage the technical debt.

A fully managed service will remove any infrastructure debt

That’s right! Services like AWS Lambda, Azure Functions, or Google Cloud functions are just a few of the function as a service options out there that will completely manage everything for you, which might not sound extraordinary to everyone but it’s amongst many others, a great reason to switch to a serverless architecture.

That means not having to worry about any orchestration, any hardware maintenance or upgrades of any kind. It basically allows developers to abstract the infrastructure altogether while being 100% sure this lack of involvement will not end up hurting them in the long run.

Serverless applications scale gracefully

Trying to meet demands with an application that wasn’t designed to scale is an absolute pain. Not being able to scale in order to meet user demand is more often than not a deal-breaker and will put any company at a huge disadvantage. Not being able to scale is more like a technical bankruptcy rather than just a technical dept.

Nevertheless, building your application using serverless will ensure that scaling is taken care of by the service provider who makes sure to spawn extra containers to meet demand.

Time to market and operational costs

Having that ever-impending deadline looming over you and your team will surely cause them to cut corners or skip certain steps resulting in something Dag Liodden likes to call “deliberate tech debt”. It basically happens when your software development team knows there’s a better way to write that particular function, module or service but for the sake of saving time or cutting costs chooses to go a different route, a quicker route. Check out this article on the different types of technical debt.

The way serverless handles these two pain points is by having the developer focus on the code and business logic and taking care of all the heavy lifting by provisioning, managing and scaling the infrastructure to fit the current neet.

Flexibility in choosing providers

Of course, we had to talk about vendor lock-in while talking about serverless. While there are lots of serverless benefits there are also a few things that might scare people from taking the serverless approach to building web services and applications.

Vendor lock-in is a problem that developers face but this too can be resolved by using platforms like the Serverless platform that allows you to move your infrastructure from one provider to another with relative ease.

Monitoring and debugging a serverless application can be very time consuming but there are solutions. Tools like Dasbhird take care of just that by facilitating that missing observability into your architecture in real time.

In conclusion

Technical debt is always going to be something we’ll have to deal with but while there’s no way to guarantee you won’t have to deal with it, serverless is proving to be a long term solution that many developers, as well as big corporations, are adopting so it stands to reason that there might just be something to this crazy new concept besides the hype that’s been surrounding this subject int he past few years.

I want to clarify one thing that might have been a bit misleading. When I was talking about how with serverless technology there's no need to upgrade or manage I was referring to the infrastructure itself and the code. That part is still up to you.

Going serverless? Here’s what you need to know

John Demian — Mon, 28 Oct 2019 12:58:23 +0000

Major companies have embraced this new innovation that is serverless and are changing their entire mindset of what the backend is. But amidst all the buzzwords flying about, comes a very important concern - how can I be sure I am using serverless in a secure way?

Serverless or Function-as-a-Service (FaaS) has a lot of benefits and one of them is the fact that the security of the infrastructure powering the applications has been moved to the platform providers like AWS Lambda, Azure Functions, IBM Cloud Functions, Google Cloud Functions etc. and denial of service will no longer be as a result of hacker attempts but more of a billing issue. This results in the focus of attackers shifting from the infrastructure as it was in the past, to the application.

Serverless applications are structured as a combination of small functions that execute your code returning a simple result. Depending on the number of open source repositories this kind of architecture widens the surface area and likelihood of cyber attacks making planning and building secure serverless applications an important point at the top of your todo list.

Here are several steps or best practices that should consider in order to build a secure serverless application.

Function-level Security

The first of on the list of security best practices for serverless is to implement function-level security. As serverless allows you to run your applications through a series of functions that can be triggered, it is important to implement security at the functional level. A good practice is to take note of all your functions and check out what each function is meant(or allowed) to do against what it is currently doing.

A rule of thumb according to Hillel Sollow is to define separate roles for each function which prevents you from giving certain functions access to data that they don’t need or performing actions that aren’t necessary thereby eliminating security loopholes in your code that can be exploited by attackers.

AWS Lambda allows you to do this in two distinct ways:
Through Identity-based policies - with this approach, you can either attach policies with permissions to a user or group in your account or you attach a policy to a specific IAM role thereby granting cross-account access to your Lambda function

Through Lambda Function policies - this approach allows you to grant cross-account permissions to your lambda functions without using identity-based policies with IAM roles.

Security audits on all dependencies

Most serverless applications use a lot of dependencies from Node.js, Python and many other repositories with open-source code. To ensure your application isn't leaving any backdoor to attackers, you need to check all dependencies for vulnerabilities.

This can pose to be a very hard task in a scenario where you’re running serverless applications with lots of functions but not to worry, there are various solutions like:

RetireJS - an open source vulnerability checker where developers can check if a Javascript library has any known vulnerabilities through a site-checking service
Npm - an open source Javascript registry that acquired Node Security Project. Npm runs vulnerability checks through the npm audit command which is available in npm@6.
Snyk - a commercial vulnerability checker with its own vulnerability database (VD). Snyk works with .NET, PHP, GoLang, Java, Python, Scala, Ruby and Node.js
Greenkeeper - a commercial dependency management tool that automatically manages, updates and tests npm dependencies.

Other solutions exist with the ability to help check dependencies with many of them relying on the NIST’s National Vulnerability Database (NVD) others rely on both the NIST NVD and their vulnerability databases as well so you will be doing yourself a big favour by searching them out and making good use of them.

Eliminate all ‘Dead’ Functions

In serverless, ‘dead’ functions are functions that have not been invoked for a very long time. As we all know that serverless gives room for unused functions to lie around thereby increasing the clutter (remember that you don't pay unless a function is invoked). There is a very high chance that you will have lots of unused functions with various permissions and privileges lying around.

Now, this can pose a very serious challenge to the developer as you can’t know what functions are not in use if they aren’t running and from a security point of view, functions that haven’t been used for a long time run a risk of having outdated libraries and dependencies.

So what do you do?

Well, besides having a well thought out plan from the get-go you'll have to use a proper monitoring tool for your application. There's no going around it. I'd recommend using Dashbird.io. It's easy to use, doesn't add any latency to your execution time and is very secure since it connects directly to your AWS account.

Don’t write bad code

This really can’t be stressed enough. Even with all the best practices mentioned earlier put in place, if you write bad code, you’ll be opening up your application to exploitation by attackers. Therefore, as a rule of thumb, ensure that your developers are continuously trained on coding best practices and all tools and libraries are constantly updated.

Also, make sure your code goes through extensive code reviews and lots and lots of tests as a small bug in one function can lead to a good enough opening for attackers to infiltrate your application.

Conclusion

As with all applications (serverless or not), security is and will always be a very important factor to consider.
Even though serverless makes the work of cyber attackers harder as the server infrastructure assigned to a function is almost always reset once the function is no longer active, it is still of great importance that your individual functions have been fortified enough to avoid illegal penetration.

How to set up alerts for your Lambdas

John Demian — Mon, 21 Oct 2019 12:01:07 +0000

In this article, we’ll make a brief introduction, and we’ll also talk about the differences between CloudWatch alerts vs. Dashbird alerts. Which one is better and why?

What Is Amazon CloudWatch Used For?  

Amazon CloudWatch is built for system operators, site reliability engineers (SRE), IT managers and developers as well. CloudWatch allows you to monitor your applications via data access and insights it provides. It can also recognize, understand and respond to all changes happening throughout the entire system.

CloudWatch is also collecting monitoring and operational data through metrics, events, and logs which further provides you with a unique view over the AWS resources, services and apps that run on AWS as well as in the localized servers. CloudWatch enables you to set alarms (or alerts), troubleshoot for issues, and discover the insights for application optimization which will ensure that the application runs smooth.

  The CloudWatch Alerts Explained

A CloudWatch alert (a.k.a. alarm) can watch over a single CloudWatch metric or even a result of math expression found in CloudWatch metrics.

Alerts will perform single or multiple actions based on the value of metric or expression which is relative to a threshold over a number of time periods. Adding alarms to CloudWatch dashboard is enabled and that way you’ll be able to monitor them visually. There are three alarm states:

OK - meaning that the expression or metric is found inside the already defined threshold;
ALARM - implies that the expression or metric are located outside of the specified threshold;
INSUFFICIENT_DATA - this alert is shown when the alarm has already started but the metric is not available, or there’s not enough data for the metric to realize in which state the alarm is.

When creating an alarm, you are able to specify three settings which will allow CloudWatch to evaluate when to change the alarm state:

Period - will enable you to evaluate the time length of metric or expression in order to create an individual data point for an alarm;
Evaluation Period - is the number of the recent data points you need to evaluate to be able to determine the state of the alarm;
Datapoints to Alarm - is the number of data points in the evaluation period which must be breached, so it’s causing the alarm to go to the ALARM state. These breaching data points must all be within the last number of data points which is equal to the Evaluation Period.

There are a lot of features that apply to all CloudWatch alarms, and we’ll go through some of them. For example, the number of evaluation periods for an alarm if multiplied by the length of every evaluation period can’t surpass the one day limit. Another feature worth mentioning is that ASCII characters must be included in alarm naming. You are also able to create 5000 alarms within every region per a single AWS account.

Dashbird Alerts Explained  

Dashbird’s instant alerting system will notify you if any issue shows up within any part of your application. Its system offers messages and realistic logs that can be easily read and understood by humans, which will save you and your company a lot of debugging time.

Dashbird monitors your application and is able to detect all kinds of errors by using various programming languages. Dashbird’s instant alert system will alert you about crashes, timeouts, runtime errors, cold starts, early exits, and configuration errors.

Dashbird interface also provides an option in the left navigation panel to press the “alert button” which will further take you to the alert page in the Dashbird app. There you have a showcase of all errors occurring in your system.

Everything mentioned above works for programming languages that are supported by AWS Lambda which also includes Java, Python, C#, and Node.js.

All the needed data to successfully go through troubleshooting event and resolve any issues inside your application are entirely at your disposal. A human-friendly interface will present you with any previous occurrences, stack traces, logs and trends for every issue or error are also available. You can also use a “more info” button for every single error you face, and that way you’ll see the error page with all the needed info for debugging the current issue.

Pro-active alerts are another one of Dashbird’s features. Basically, you could set up an email notification alert system, so when your functions are about to reach memory limitations, you will be notified about it. Dashbird provides seamless integration with Slack as well. If you wish to read more about the Dashbird alerts and serverless monitoring tools, how it all works compared to other services, follow this link to our blog.

As of January 2019, the new alerting system is out and with the new and improved design

Conclusion

Both CloudWatch and Dashbird have their pros and cons, and we’ll wrap up here after mentioning a few.

While Cloudwatch is mostly an excellent choice for users who are already inside the AWS ecosystem, it's right there the second you need it but as we established Cloudwatch can be difficult to work with. The alerting options for CloudWatch are not as boundless since they’re available with third-party services.

Cloudwatch doesn’t offer pre-configured alerts, but you need to create custom alerts on your own which further means you must be very familiar with how everything works in order to create them properly.

On the other hand, Dashbird’s alert notification system is automated and instant which surely provides you comfort and ease in case something happens within your application.

If you have any ideas, questions or thoughts, feel free to share them in our comment section below.

DEV Community: John Demian

Making my Laravel Development simple with Forge

The Problem with Traditional Deployment

Enter Laravel Forge

The DIY Route

Saving my Sanity

The New Forge

Instant VPS Provisioning

Zero-Downtime Deployments

Enhanced Deployment Visibility

My two cents

Planning to launch a SaaS? You need to know this one little thing.

Doubling down on user feedback

Website speed testing - is this still a thing?

Time to first byte and first meaningful paint

Load times

Render-blocking code

HTTP Requests

Getting rid of the issues

Lower the load times

Get rid of the render-blocking code

Excessive HTTP Request

What’s next?

Website Benchmarks - Everything you need to know

Why Benchmark Your Website?

What Metrics To Benchmark

How To Benchmark a Website: Benchmarking Example

Website Benchmarking Best practices: The Do’s and Don’ts

1. Compare with similar web pages

2. Test multiple locations and devices

3. Benchmark against competitors instead of averages

4. Dig deeper

5. Understand what your site “does” when you are not looking

6. Monitor third-party APIs

Conclusion

Website Speed Optimization: Tools & Best Practices

How Can Website Speed Testing Tools Help?

Website Speed 101: Basic Concepts to Get Started

Big load times

Render-blocking code

HTTP Requests

The 10 Best Website Speed Testing Tools

1. Sematext Synthetics

2. Google PageSpeed Insights

3. Pingdom Speed Test

4. WebPageTest

5. GTmetrix

6. Varvy Pagespeed Optimization

7. Uptrends

8. dotcom-monitor

9. Site 24×7

10. Google Chrome DevTools

Conclusion

20+ User Experience (UX) Metrics Every Product Manager Should Measure

How Are UX Metrics Defined?

1. Real User Monitoring Metrics

Apdex and User Satisfaction Score

HTTP Requests

Sematext as a RUM solution

2. User Engagement Metrics

Unique Visitors

New vs Returning Visitors

Pageviews

Time on Page

Pages per Session

Conversion Rate

3. Usability Metrics

Task Success Rate

Time-on-Task

Use of Search vs. Navigation

User Error Rate

System Usability Scale (SUS)

4. User Adoption Metrics

Active Users

Product Access

Average Time Spent with Product

Feature Adoption Rate

5. User Retention Metrics

Customer Churn

Net Promoter Score

What Is Amazon CloudWatch Used For?  

  The CloudWatch Alerts Explained

Dashbird Alerts Explained  