Things I’d like to see Next.js/Vercel address/fix.

The changes I’d like to see are geared towards ‘quality of life’ issues as it relates to their interface/dashboard.

Analytics should be Partitioned by environment.

Analytics should not be one giant basket of all repos deployed. By doing so, it conflates the overall legitimacy of “real usage” on production apps performance. Also, if someone introduces a change that has detrimental effects to performance, you wouldn’t see it right away. How could you? All the data is conflated.

If “preview/staging” had its own “Analytics” it would be obvious immediately. Production & Preview should have their own Analytic Dashboards, at a minimum.

Inclusion/Exclusion of pages in WebVitals.

We should be able to omit/declare pages to webVitals. I am incrementally moving a site to Next.js, as such, I should only care about these pages performance. Some pages with literally nothing on them are being “hit” (bots or indiscriminate traffic) and thus registering near perfect scores, but these are conflating the overall “Analytics score”. This is not legit.

Deployments should be partitioned by environment.

No cloud provider I have worked with mixes concerns like this. I should be able to cleanly & quickly be able to look at all my Production/Preview deploys, separately. I have preview, production, ‘cancelled’, irrelevant deploys all mixed together.

Stop trying to deploy every single git push.

I’m super confused about this one. I create dummy branches, experimental branches, they all get deployed. Ok, I think this could be useful in a small subset of pages that don’t deal with cors issues and such. But for someone like me, going to a deploy: “companyname-client-fwpm15pky-companyname.vercel.app”, is useless as I use an external backend, so none of the apis work. Sure there are workarounds, but I don’t need it. It’s not a bad feature, just not something I need. But it has the side effect of making my dashboard a complete mess.

Yes, I use this (see code snippet below) to minimize the deploys. It works, but now I have dozens of “cancelled” deploys I have to “delete” every day or week. Why all the clutter?

#!/bin/bash

echo "VERCEL_GIT_COMMIT_REF: $VERCEL_GIT_COMMIT_REF"

if [[ "$VERCEL_GIT_COMMIT_REF" == "staging" || "$VERCEL_GIT_COMMIT_REF" == "main"  ]] ; then
  # Proceed with the build
    echo "✅ - Build can proceed"
  exit 1;

else
  # Do not build.
  echo "🛑 - Build cancelled"
  exit 0;
fi

If you are not gonna address this item, allow me to delete a deployment from the Overview page.

There really shouldn’t be a reason I have to click into a deployment to delete it. Especially given the issue mentioned above. In the dropdown, let me delete it from there. But, the question begs — why even surface “cancelled” deploys? If you need to surface them, put them in their own bucket.

Even with that script above, as mentioned, I get “cancelled” deploys. I obviously don’t want them deployed at all, not that I “cancelled’ them, I am trying to omit them altogether. Even better, why not have allow me to stipulate which branches I want to instigate a deployment?

Analytics should offer deeper information.

I understand you offer integrations to other third party entities, but with that comes additional downloads, performance hits etc.. For example, I integrated with DataDog, great info — but another 45k download script injection, when I’m already trying to min/max my performance.

You are obviously getting this data, what is the problem surfacing it? Maybe the performance bottleneck seems to be happening to a subset of users, or locations. You can’t surface userAgents, location etc..

Date Display

“16d ago” is not really helpful when I need to know specifically when a deployment occurred. I could look on github, but why, I have the Vercel dashboard for this sort of info.

These “{number}d ago” displays are on the main deployments list page, and also when you “view deployment”. If you have to keep that particular data point (‘44d ago’), also put the fully qualified date WITH minutes ie. Wed Dec 01, 2021 at 3:00pm. Doesn’t that seem way more useful? I can make a decent judgement if I see issues in production that could be related to a release “time window”.