DEV Community: Femi Akinyemi

Why PageSpeed says reduce unused JavaScript

Femi Akinyemi — Sat, 10 Oct 2026 10:51:36 +0000

PageSpeed watched the page open. It listed scripts the browser downloaded and barely ran. That is the whole warning. Here is how to read the list without breaking the page.

You already know the line. Reduce unused JavaScript. Under it, a stack of file addresses, and a size next to each one. The top file is the largest. It is easy to read that as “delete these.” That reading is how pages get broken.

The line is still worth taking seriously. A phone on a slow connection has to fetch every one of those files before it can get on with the picture, the words, and the button the person came for. Code that never runs is still a download.

What the line actually measured

PageSpeed Insights loads one address, in a lab, the way a first visit might look on a phone. While that load is happening it keeps a record of which script code actually ran. Code that was downloaded and did not run on that pass is marked unused.

That record stops when the page has settled. It does not sit there and use the site the way a person would. It does not open a menu, send a form, start a chat, or scroll to a map. Anything that waits for those moments can look unused and still be the reason the page works.

So “unused” here means “not run during this one load.” It does not mean “safe to throw away,” and it does not mean “this file is why the site feels slow.” It means the browser fetched code it did not need yet.

Why a file that never ran still costs the visit

The wait happens before the code runs. The phone has to ask for the file, receive it, and read it. A large script takes time on a weak connection even if most of the code sits idle after that. While that transfer is going on, the picture the person is waiting for is sharing the same connection.

This is why a chat box you never opened can still show up on the list, and why the page can feel late before anyone taps anything. The file arrived. The feature did not. The visitor paid for both.

A small unused file is rarely the story. PageSpeed puts the largest waste at the top for that reason. A tiny helper is not the same problem as a script hundreds of kilobytes long that came along for one button.

The three kinds of files on the list

Yours, and this page never needs it. A slider script on a page with no slider. A booking script on a page with no booking. A theme file that loads on every page because that was easier than deciding. These are the ones worth removing from this page. The rest of the site can keep them where they are actually used.

Yours, and a person needs it a moment later. The menu, the search box, the form, the gallery that opens on tap. PageSpeed did not tap. The file looks idle. Take it off the page and the first real visitor finds a dead control. If the file is huge, the useful question is whether that control can load when the person asks for it, not whether the control should disappear.

Someone else’s file. Ads, chat, a tag that loads other tags, a map, a review widget. The address is on their server. You cannot edit the file. You can take their tool off your page, or you can keep it because the tool is doing a job you want. Those are the only two honest choices. A speed plugin that claims to “fix unused JavaScript” often just delays these files. The download still happens. It happens a little later.

What to leave alone

Do not clear the list in one afternoon. I have watched people turn plugins off in a pile, run PageSpeed again, and treat whatever number comes back as proof. The score also moves when nothing changed. A real cut can look small on the grade, and a lucky second run can look like a victory. One file, then another look. I wrote about that wobble in Why your Lighthouse score changes when you did nothing.

Do not treat the homepage as the whole site. The homepage can be quiet while the page people actually use, a product, a booking form, a long post, pulls a much larger script. Test the address that felt slow.

And do not assume this line is the main wait. A huge picture, or a server that is slow to answer, can be what people feel while this list sits underneath it. On a WordPress site those show up together, because themes and plugins are happy to add scripts to every page. I wrote that up in What usually slows a WordPress site.

How to read one row

Take the top row only.

Read the address. If you recognise the name, a plugin, a theme, a tool you installed, you know who put it there. If the name is a hash of letters and you do not recognise it, it is often a file the site built, or a tag. The folder in the address usually gives it away: a plugin folder, a theme folder, or another company’s domain.

Then ask one question. Does this page need this file before anyone taps? If the answer is no, that file does not belong on this load. If the answer is yes, leave it and look at the next row. If the answer is “only after they tap,” the file can wait for the tap, but only if you can make that change without losing the control.

Chrome can show the same thing in more detail. Open the page, open the Coverage panel, and reload. It colours the code that ran and the code that did not. Use that when you already know the file and you want to see how much of it was idle. You do not need it to decide which row to open first. The top row is enough for that.

Where to start

Stay on the page that felt slow. Open the top file if it is yours. Leave the rest of the list until you know whether that file was the wait. If the top file belongs to a tool you do not care about, remove the tool, not five other plugins.

Then run the check again on the same address. Read the new score next to how far the score moves when you change nothing. If the file is gone from the list and the page still works when you use it, that was the right cut. If the score jumped and the page feels the same, you measured noise.

A free check on PafCore is that first look without the long list. Paste the public address. No account. You get the score, how far that score moves when nothing changed, the slow file when it can be named, and a few of the problems. Sign in for the full report, including what to try. PageSpeed remains a good snapshot of the warning. Use it for the list. Use a named file when the list is too long to trust.

Try it: Check my site. Paste a public address. Free check. No account.

Why a website feels slow on a phone

Femi Akinyemi — Sun, 27 Sep 2026 14:25:35 +0000

A website feels slow on a phone when the page asks a small screen and a weaker radio to do the same work your computer already finished. Large pictures. Busy scripts. Files the phone has not saved yet. You sit on fast wifi with a wide window. They sit on a phone. They feel a blank screen, a late picture, or taps that do nothing.

This is common. It is not a mystery. You checked the site on your computer and it felt fine. A client or a friend opened it on a phone and said it was late. Both can be true.

This piece is the plain version of that gap, and a free way to check the page the way a visitor does. PafCore loads a public URL like a slow phone. When it can, the report names the file.

What people feel on a phone

They do not talk about scores. They talk about the wait.

The screen stays blank after they tap the link.
The first picture shows up late.
Buttons ignore the first tap.

Those moments decide if they stay. A number on a lab report can miss them. A score is still useful. It is not the whole story. I wrote about that in Why a performance score is not enough.

Why your computer hides the wait

Your computer is a kind visit. A phone is a harder one.

The screen is smaller, the file is not. A large picture can look sharp on your computer. On a phone it is often bigger than the space it fills. The phone still downloads the whole file. The visitor waits.

The radio is weaker. Home wifi is usually fast. A phone on mobile data is not. The same scripts and pictures take longer to arrive.

You already had the files. You open the site every day. Your computer saved pictures and scripts from last time. A new visitor starts from scratch. Their first load is the one that matters.

The page stays busy. Chat widgets, booking tools, and tracking scripts keep the page working after it looks ready. On a phone that extra work shows up as taps that do nothing.

Keep it honest: a phone is not always slower. A lean page can feel sharp on both. Guessing which file hurt wastes a day. Measure the page the way a visitor opens it.

Why the usual check misses it

People test on the same computer they build on. Fast wifi. A wide window. Files already saved. The page feels fine. They stop.

Google PageSpeed Insights is useful. It can show a phone view. Many people still paste once, glance at the number, and close the tab. A single run also wobbles. The number moves even when you changed nothing. See Why your Lighthouse score changes when you did nothing.

Home can look fine on a phone too. A product page or checkout can still wait. That is a different trap. I wrote it up in A fast homepage can still hide a slow site.

What a useful phone check does

A useful check should do four simple jobs.

Load the page like a slow phone, not like your computer.
Run it more than once so you see a middle score, not one lucky result.
Say what the person felt: blank screen, late picture, taps ignored.
Name the slow file when the measurement can find it.

That is what PafCore is built for. Paste a public URL. You get a free report. No signup. Three runs. A middle score. The quiet gap. The file when we can see it.

How to check a page today

Pick a real page. The home page, or a page people pay on.
Open it once on your phone on mobile data. Notice the feel.
Paste the full address at pafcore.site.
Read the middle score first. Then open the top finding. If a file is named, start there.

Use the live public URL. A page behind a login will not load the same way for a free public check. Start with what visitors already see.

If you send sites to clients

Clients live on a phone. You live on a computer. That is how arguments start. “It feels fine here.” “It feels late to me.”

Send a report that names the feel and the file. Talk in plain words. What they saw. Which file hurt. What you will change next. Run one quiet check after the fix so you do not celebrate noise.

If you manage many sites and need schedules, that is Pro Watch. The free report stays free for a one off paste.

FAQ

Why is my website slow on a phone but fine on my computer?

Your computer has a wide screen, fast wifi, and files already saved from the last visit. A phone has a smaller screen, a weaker radio, and often starts from scratch. The same large picture and busy scripts cost more there. People feel a blank screen, a late picture, or taps that do nothing.

Should I test website speed on a phone?

Yes. Most visitors use a phone. A check on your computer can hide the wait they feel. Use a phone on mobile data, or a report that loads the page like a slow phone.

Does a high score on my computer mean the site is fast?

No. A high score on a computer only describes that visit. The same page can feel late on a phone. Check the page the way a visitor opens it.

Does PafCore test on a phone?

PafCore loads the public page three times on a slow phone connection. You get a middle score, how far that score moves on its own, and the slow file when the report can name it. Free. No signup.

Try it: Check my site. Paste a public URL. Free report. No signup.

A fast homepage can still hide a slow site

Femi Akinyemi — Fri, 25 Sep 2026 12:57:50 +0000

Originally published at pafcore.site/a-fast-homepage-can-still-hide-a-slow-site.

A homepage score is the speed score for the home URL only. It is not a score for the whole site. I have seen a shop home sit near 88 and checkout sit near 41. Same host. Same theme. Different files. People still share the home screenshot and call the job done.

This piece is the plain version of that mistake, and a free way to check a real page with PafCore. When we can, we name the slow file.

What people feel that you miss

You live on the home page. Visitors do not.

They tap a product and wait on a blank screen.
They reach checkout and the first tap does nothing.
They open a campaign page and the big picture arrives late.

Home can feel fine. The wait shows up one click later. A score on home will not warn you. I wrote about why a number on its own is thin in Why a performance score is not enough.

Why the usual tools stop at one URL

Google PageSpeed Insights checks the address you paste. One address. Lighthouse does the same. That is useful. It is also easy to misread.

People paste the home page because it is the one they remember. The report looks serious. The number is high enough. They stop. The rest of the site never gets a turn.

Each page loads its own pictures and scripts. A chat widget on a help page. A big gallery on a product page. A payment script on checkout. Home never asked for those files. So home never paid for them.

Keep it honest: a strong homepage score is still good news. It is not a pass for the site. Treat it as one page you measured, then measure the next one people use.

Pages that hide the wait

These are the ones I would open after home.

Checkout or a form. Extra scripts. Extra fields. The page that should feel sharp often feels late.

A product page or a busy post. Large pictures. Reviews. Related items. The template looks like home. The files do not.

Search results. A list that builds itself after the page opens. The first screen can sit empty.

A campaign landing page. Heavy video. Heavy animation. Built for a click, then forgotten in the speed check.

Same site. Different wait. Start with the page that costs the most points.

What a useful check does

A useful check does not stop at home.

Run a page more than once so you see a middle score, not one lucky screenshot.
Show how far the score moves on its own (the quiet gap).
Name the slow file when the measurement can find it.
Let you compare pages so the worst one is obvious.

That is what PafCore is built for. Paste a public URL. Free report. No signup. When we can see the cost, we name the file. When we cannot, we still tell you what to try first.

You can also scan a whole site. Up to 20 pages. Worst first. That pack costs 20 credits and emails you when it finishes. Start with the free one page check if you have not used credits yet.

How to check more than your homepage

Paste the home URL at pafcore.site. Note the middle score.
Open a page people actually use. Checkout. A product. A form. A busy post.
Paste that full address. Wait for the middle score.
Fix the worst page first. If a file is named, start there.

Use the live public URL. A page behind a login will not load the same way for a free public check. Start with what visitors already see. Scores also move when you change nothing. Learn that quiet gap before you celebrate. See Why your Lighthouse score changes when you did nothing.

For freelancers and agencies

Clients send a home screenshot. They ask if the site is fast. The honest answer is “I have not checked the page they pay on.”

Send two links. Home and the page that matters. Talk in plain words: what the visitor felt, which file hurt, what you will fix next. A named file is easier to explain than a long tip list. More on that split in When PageSpeed Insights is enough (and when it is not).

PafCore can carry your name on the report when white label is on. If you manage many sites and need schedules, that is Pro Watch.

FAQ

Does PageSpeed Insights check my whole website?

No. It checks one URL at a time. A homepage score is not a score for every page on the site.

Why is my homepage fast but checkout is slow?

Those pages load different files. Checkout often pulls extra scripts, forms, and pictures the home page never uses. Measure checkout on its own.

Should I only test my homepage?

No. Test the pages people actually use. Home, a product or post, and the page where they pay or send a form.

Can PafCore scan a whole site?

Yes. It can read up to 20 pages and show the worst first. That pack costs 20 credits and emails you when it finishes. A one page check is still free.

What usually slows a WordPress site

Femi Akinyemi — Sun, 20 Sep 2026 11:29:18 +0000

Originally published at pafcore.site/what-usually-slows-a-wordpress-site. Prefer the canonical link for sharing and SEO.

Blank screen. Late picture. Taps that feel ignored. Then a long tip list that still does not name the file. Here is the plain version, and a free way to find what to fix first.

WordPress runs a large share of the public web. That success also means a lot of sites feel slow for the same reasons. Owners open Google PageSpeed Insights. They get a score and a scroll of advice. They still leave unsure what to change today.

This piece is not a plugin hall of fame. It is what people usually feel, what a tip list misses, and how a free PafCore report helps you name the slow file when it can.

What people feel first

Before anyone talks about scores, visitors notice the site.

The screen stays blank longer than they expect.
The big picture shows up late.
Buttons and menus ignore the first tap.

Those moments matter more than a grade on a lab report. A score is useful. It is also incomplete on its own. I wrote about that gap in Why a performance score is not enough.

What usually slows WordPress

Every site is different. Still, the same patterns show up again and again.

Large pictures. Hero images, galleries, and blog photos that were never resized for the web. The browser waits. The visitor waits.

Heavy theme and plugin scripts. Themes and plugins often load JavaScript and styles on every page, even when that page does not need them. One quiet plugin can cost more than the rest of the theme.

Fonts. Several font files, or fonts that block text until they finish loading. The page looks empty even when the words are already there.

Ads and embeds. YouTube, maps, chat widgets, and ad scripts pull work from other servers. Your page waits on them.

Weak hosting. Cheap shared hosting can make every request slower. It is real. It is not always the first place to look. Measure the page before you buy a bigger plan.

Keep it honest: none of these is always the villain. A lean plugin can be fine. A big image can be fine if it is the right size. Guessing wastes a week. Measuring names the file.

Why a tip list is hard to use

PageSpeed Insights and Lighthouse are free and useful. The tip list is long on purpose. Many tips do not move the score much. Some are already fine for your page.

People change three things. They run the check again. The number moves. They still cannot tell if the fix worked, or if the page just wobbles from one run to the next. That quiet swing is common. See Why your Lighthouse score changes when you did nothing and Why getting faster barely moves your Lighthouse score.

Left: a scroll of tips. Right: a named file and a clear next step.

What a useful report does

A useful speed report for WordPress should do four simple jobs.

Run the page more than once so you see a middle score, not one lucky screenshot.
Show how far the score moves on its own (the quiet gap).
Say what to fix first by points, not by how scary the tip sounds.
Name the slow file when the measurement can find it.

That is what PafCore is built for. Paste a public WordPress URL. You get a free report. No signup. When we can see the cost, we name the file. When we cannot, we still tell you what to try first.

How to try it on your WordPress site

Pick a real page. The home page, or a busy post or product page.
Paste the full address at pafcore.site.
Read the middle score and the quiet gap first.
Open the top finding. If a file is named, start there.

Use the live public URL. A staging site behind a login will not load the same way for a free public check. Start with what visitors already see.

For freelancers and agencies

You already sell WordPress speed work. Clients ask “did we get faster?” A long tip screenshot is hard to explain. A report that names a file is easier to send.

PafCore can carry your name on the report when white label is on. Share the link. Talk in plain words: what the visitor felt, which file hurt, what you will fix next. Keep one quiet recheck after the fix so you do not celebrate noise.

If you manage many sites and need schedules, that is Pro Watch. The free report stays free for a one off paste.

FAQ

Is PageSpeed Insights enough for a WordPress site?

It is a strong free snapshot of one URL. Use it to learn. When you need a named file, a middle score from a few runs, or a report for a client, add a clear report like PafCore. More on that split in When PageSpeed Insights is enough (and when it is not).

Is slow WordPress always a hosting problem?

No. Weak hosting can hurt. Large pictures, heavy theme and plugin scripts, fonts, and embeds often cost more than people expect. Measure the page before you buy a bigger plan.

Do plugins always make WordPress slow?

Not always. Some plugins add little. Others load big scripts on every page. The honest answer is to measure and see which file costs the most points.

Does PafCore replace WordPress speed plugins?

No. Caching and image plugins can help. PafCore measures the live page, shows how far the score moves on its own, and names the slow file when it can. Use both: measure first, then choose a fix.

Try it: Check my site — paste a public WordPress URL. Free report. No signup.

When PageSpeed Insights is enough (and when it is not)

Femi Akinyemi — Wed, 09 Sep 2026 10:31:43 +0000

Introduction

PageSpeed Insights is free. It is official. For one URL, right now, it is often the right tool.

You paste a link. You wait. You get a Lighthouse performance score, lab timings, and field Core Web Vitals when Google has enough Chrome visits. That is a strong snapshot.

A snapshot is not a watchman.

This guide is for people who ship websites and still live in PageSpeed tabs. It says when that habit is fine, when it starts to fail you, and what to add without turning every check into a science project.

By the end you will know:

when a manual PageSpeed Insights run is enough
why one lucky score is a weak proof of a fix
when scheduled checks and alerts earn their keep
a simple hybrid you can run this week

Chrome and PageSpeed Insights stay in the mix. I also run a free three run check at pafcore.site when you want the quiet swing and what to fix first without babysitting six tabs.

What PageSpeed Insights is good at

Use PageSpeed Insights when:

you are learning Largest Contentful Paint, layout shift, and the performance score
you are checking one page before or after a change
you manage one or two sites and can afford to click by hand
you need field data from the Chrome UX Report on a busy enough URL

For those jobs, do not add a tool for the sake of a tool. Open the page. Read the wait in seconds. Read the grade. Move on.

Where a single run fools you

Even on one site, a single PageSpeed Insights screenshot is a weak proof.

Lab scores move when the code does not. Machine load, third party tags, and plain luck all show up. I have seen a quiet page score 60, then 51, then 57 with nothing deployed. Nine points of weather.

So before you celebrate a fix:

Run three quiet checks with no deploy. Learn the gap between best and worst.
Ship the change. Run three more.
Compare middle scores. Only call it a clear score win when the rise beats that quiet gap.
Write the wait you meant to fix in seconds next to the grade.

That habit works in Chrome DevTools, in PageSpeed Insights, or in a free three run report. Same idea. More than one sample. Seconds and score together.

I wrote the full quiet gap steps in Why your Lighthouse score changes when you did nothing. Read that when the number moves with no deploy.

A real wait can also drop while the Lighthouse performance score barely moves. That is the scoring curve, not a broken tool. See Why getting faster barely moves your Lighthouse score.

Manual checks fail you twice: at scale, and when you trust one lucky run.

When manual checks stop being enough

You have crossed the line when one or more of these are true.

You watch more than a handful of pages

Ten sites, a few key URLs each, mobile and desktop: that is a long afternoon of paste, wait, copy, switch. By the time you finish, the first numbers are stale. Miss a week and you have no recent trail when a client asks why search or speed felt worse.

A deploy can break speed overnight

A new script, a heavier hero image, a font change. With only weekly PageSpeed Insights checks, you may learn on Friday. Or when the client calls. Scheduled lab checks (daily, or hourly on a few critical pages) shorten that blind spot. An alert should find you, not the other way around.

You need history, not only today’s screenshot

PageSpeed Insights does not keep your before and after for you. Trend lines, month to month notes, and “this page got worse after Tuesday’s release” need storage. Screenshots in a folder do not scale.

You need budgets and alerts

“LCP should stay under 2.5 seconds on mobile home” is a budget. PageSpeed Insights will not email you when you cross it. A watch with a threshold will.

You need something a client can read

Raw PageSpeed output is for builders. Clients want a short story: what got better, what still hurts, what you will do next. That story is easier when history and middle scores already exist.

A plain comparison

Need	PageSpeed Insights	Scheduled checks
One URL, right now	Yes	Yes
Mobile and desktop	Yes	Yes
Lab score and timings	Yes	Yes
Field Core Web Vitals when available	Yes	Sometimes (depends on the tool)
Many sites without tab hell	No	Yes
Daily or hourly runs	No	Yes
History and trends	No	Yes
Budgets and alerts	No	Yes
Honest before / after (more than one run)	You must do it by hand	Still your job to demand it

Same Lighthouse family of lab maths in many tools. The workflow is what changes. Scheduling does not make a single run more truthful. It makes misses rarer.

Use both. Split the jobs.

PageSpeed Insights or Chrome for learning, quick peeks, and one off audits.

Three quiet runs (by hand or a free report) whenever you claim a fix worked.

Scheduled Watch when pages matter every week: home, pricing, checkout, key landing pages. Prove you own the domain. Set a budget. Let email or a webhook tap you when the score or a wait crosses the line.

That is the hybrid. Not “throw away PageSpeed Insights.” Not “buy a dashboard and stop thinking.”

A week one checklist

List the pages that would hurt if they got slow (home, money pages, signup).
For each, run three quiet mobile checks once. Write the gap and the middle score.
Keep using PageSpeed Insights for random questions.
Put the money pages on a schedule if you already juggle more than a few sites, or if a bad deploy would cost you a client call.
After the next speed fix, compare middle scores to the quiet gap, and write Largest Contentful Paint (or your target wait) in seconds.

If you want the three run spread and “what to fix first” in one paste, use pafcore.site. If you want daily or hourly checks, history, and alerts on pages you own, that is Pro Watch at $19/mo. Credits on the site buy lab checks on a report. Watch runs are separate.

Conclusion

PageSpeed Insights is enough when you need a clear snapshot of one URL. It is not enough when you manage many pages, when you must catch a bad deploy fast, or when you confuse one lucky grade with proof.

Automate the watch. Keep the honest measure. Talk in seconds and in scores. That mix scales better than living in twenty PageSpeed tabs, and it stays truer than a dashboard that only stores one run a day.

FAQ

When is PageSpeed Insights enough?

One or two sites, learning the metrics, or a one off audit. Once you cannot keep up by hand, or once a missed week would embarrass you, add schedules.

Does a scheduled tool use different maths than PageSpeed Insights?

Many lab tools sit on the same Lighthouse style checks. Field Core Web Vitals still come from real Chrome visits over time. Do not expect one lab run to match Search Console the same afternoon.

Why three runs if I already have daily monitoring?

Daily monitoring catches surprise drops. Three runs answer “did this fix beat the quiet weather?” You still need both ideas.

Can I keep PageSpeed Insights for some clients?

Yes. Low stakes pages stay manual. High stakes pages get schedules, budgets, and a quiet gap written down once.

Why your Lighthouse score changes when you did nothing

Femi Akinyemi — Mon, 07 Sep 2026 06:10:41 +0000

Introduction

If you ship websites for a living, you have seen this.

You change one thing on a page. You open Chrome, run Lighthouse, and the performance score goes up a few points. You take a screenshot. You tell the team the fix worked.

Later the same day you run the same URL again. No new deploy. The score drops. Sometimes it drops below where you started.

That is not you failing at your job. Lab scores move even when the code does not. CPU load, network jitter, third party tags, and plain luck all show up in a single run. One number is a sample. It is not a verdict.

This article gives you a short, repeatable way to read that movement so you stop celebrating noise. By the end you will know:

why a quiet page can still swing several points
how to measure that swing in Chrome in about fifteen minutes
when a fix is real enough to put in a pull request
how to talk about wins without overselling the score

Chrome DevTools is enough for every step. I also built a free three run check at pafcore.site when you want that quiet gap without running Lighthouse by hand. The habit below is the same either way.

Why the number moves

Lighthouse loads your page in a controlled browser with throttling. That setup is useful because it is harsh and repeatable enough to compare days. It is not a perfect copy of every visitor.

Small differences stack up:

the machine was busier on one run
a third party script answered slower
an image raced and won or lost the “largest content” slot
the score itself sits on a curve, so the same time change is worth different points at different speeds

So two runs of an untouched page can land far apart. I have seen a public site score 60, then 51, then 57 with nothing deployed in between. Nine points of weather.

If you only look at the first run after a deploy, you will misread luck as skill.

What you will set up

You need:

Chrome
the live URL (or a stable preview URL)
a note app or the PR description
the same Lighthouse mode every time (mobile or desktop). Pick one and keep it

Turn extensions off, or use a clean window. Do not scroll or click while the audit runs.

Step 1. Measure a quiet page

Run Lighthouse three times on the same URL. Do not deploy between runs. Write down the three performance scores.

Find the highest and the lowest. Subtract. That gap is how far this page already moves when you change nothing.

Example:

Run	Score
1	60
2	51
3	57

Gap: 9 points.

Some pages only move two or three points. Some move more. You cannot guess your gap. You measure it once per important page (home, pricing, checkout) and you refresh it when the page shape changes a lot.

Doing those three quiet runs by hand is boring, which is why people skip it. I got tired of skipping it on client work, so I built a free report at pafcore.site that loads the page three times and shows how far the score moves on its own. Use Chrome if you want full control. Use that report if you want the quiet gap filled in for you. Either way, the idea is the same: learn the swing before you celebrate.

Step 2. Ship the change, then measure again

Deploy your fix. Run Lighthouse three more times with the same settings.

Sort each set of three scores and take the middle one. Compare middle after to middle before.

Clear win: the middle score rose by more than the quiet gap.

Not clear yet: the rise is smaller than the gap.

No win: the middle score did not rise, or it fell.

A four point bump on a page with a nine point quiet gap is not a story. It is still inside the swing you already saw.

Step 3. Write the slow thing in seconds

The score is curved. A real wait can get better while the grade barely moves, especially on a slow page.

In the same note, track the metric you meant to fix:

	Before (middle of 3)	After (middle of 3)
Performance score	56	60
Biggest picture time	4.8s	3.1s

Now you can say something honest: visitors should feel a clearer first picture, and the score is still noisy. That is better than claiming “we gained four points” when those four points never cleared the quiet gap.

If both the score and the target time sit inside the quiet swing, do not call it a performance win. Keep the change if the code is cleaner. Leave the victory lap for later.

Step 4. Do not drown in the tip list

Lighthouse will hand you a long list of opportunities. Most rows are not direct score inputs. The grade comes from a small set of lab metrics (largest content paint, blocking time, layout shift, first content paint, speed index, and similar). Tips about unused script or cache headers can still help people. They only raise the grade if they improve one of those metrics.

Before you put a tip on the sprint board, answer out loud:

“If this works, which score metric gets better?”

No answer means cleanup. Cleanup is fine. Cleanup is not a score promise.

If two tips are the same heavy image with two labels, fix the image once. Do not add imaginary points from both rows.

Step 5. Put numbers in the pull request

Paste something like this so review stays calm:

Lighthouse, same mode, three runs before and three after.
Quiet gap (max minus min, no deploy): 
Middle score before: 
Middle score after: 
Target wait before / after: 
Clear win? yes / not sure / no

One screenshot of a lucky run starts arguments. This block ends most of them.

What you get from this habit

After you use this a few times you will:

Stop treating a single Lighthouse score as proof.
Know your page’s quiet gap, so small bumps stop wasting the team’s week.
Separate score went up from the wait got better, and report both.
Pick tip list work that maps to a real metric, instead of boiling the ocean.
Leave a PR trail other people can trust.

That is the value. Not a new theory. A filter for what you already run.

Conclusion

Your Lighthouse score changes when you did nothing because a lab run is noisy. That is expected.

Measure three quiet runs. Learn the gap. Only call a fix a win when the new middle score beats that gap, and check the wait in seconds too. Treat the long tip list as optional until it names a metric you can move.

Do this on your important pages once, then again after real releases. You will ship fewer fake wins and sleep better after you post the screenshot.

I built pafcore.site for the days when I did not want to babysit six Lighthouse runs myself.

Paste a public URL, get the three run spread, see what to try first by points, and keep the habit from this article either way.

Chrome alone still works. The site is there when you want the quiet check done in one pass.

What AI Still Misses in Production Next.js Apps

Femi Akinyemi — Mon, 22 Jun 2026 07:10:47 +0000

Introduction

You ask AI to fix a fetch. It does. Types pass. The component renders. You push.

Then dev crawls to a stop. Or prod serves a blank page. Or GitHub says conflict on a file you never touched. The model did its job inside the file. It did not see the repo around it.

That gap is where most Next.js pain actually lives. Not broken JSX. Wrong root folder. Wrong env layer. Wrong deploy model. Stale git ref on the remote.

This list is the stuff that keeps surviving AI refactors, green CI, and clean local merges.

1. Next dev watching the whole monorepo

The problem

Your app sits inside a bigger repo. There is another lockfile above it. You run next dev, see a warning about multiple lockfiles, and keep going.

Compile gets slow. CPU stays high. Sometimes the machine feels stuck for no clear reason. AI will suggest faster imports or smaller components. It will not notice Next is indexing the wrong tree.

The fix

Pin Turbopack to the app folder in next.config.ts:


import path from "node:path";
import { fileURLToPath } from "node:url";

const appRoot = path.dirname(fileURLToPath(import.meta.url));

export default {
  turbopack: { root: appRoot },
};

This applies to certain monorepo/workspace setups.
It is not the solution for every slow Next.js dev environment.

If that lockfile warning shows up, treat it as a bug, not noise.

2. Putting server secrets in `NEXT_PUBLIC_*`

The problem

AI puts API URLs and tokens in NEXT_PUBLIC_* because that is what client fetch examples use. Those values ship in the browser bundle. Anyone can read them in the built JS.

Or the opposite: server route handlers need an upstream URL that only exists as a public var pointing somewhere else. Local dev works with a hack. Prod does not.

The fix

Split by runtime:

Browser code → NEXT_PUBLIC_* only
Route handlers / server code → server env vars (no NEXT_PUBLIC_ prefix)

Upstream URLs and service tokens stay on the server. Client calls your BFF or the public API surface. Never both through one env var.

3. API address missing or duplicating `/api/v1`

The problem

One backend expects calls to https://api.example.com. Another expects https://api.example.com/api/v1. Your code adds paths on top of the base address. Get it wrong by one segment and every request 404s.

This often happens when you copy .env.local from another app in the same repo. AI copies the fetch code correctly. It does not check whether the base address matches this app.

The fix

Open that app's .env.example. See exactly how it builds URLs. Match that. Do not assume all apps in one company use the same address format.

4. Adding server API files to an app that deploys as static `HTML`

The problem

Some Next apps are built with output: "export". That means the output is plain HTML, CSS, and JS files uploaded to static hosting (like S3 or Amplify static). There is no Node server running your app in production.

You can add files under app/api/ and they may work in local dev. They will not exist after a static build. The hosting serves files, not your API routes.

AI often suggests "add an API route to hide the token" without checking how the app is deployed.

The fix

If you deploy as static files, the browser calls your backend directly and your backend must allow that origin (CORS).

If you need a server middle layer to hide tokens, you cannot deploy as a pure static export. You need hosting that runs Next.js server code.

Pick one. Mixing both without knowing it is a common break.

5. Local proxy setup that does not exist in production

The problem

In local dev, teams often add a proxy in next.config so calls to /api/v1/... get forwarded to a real server. Same website address, no cross-origin browser errors. Works great on your machine.

A static production build does not include that proxy. The browser still calls /api/v1/... on your static site address. Those requests never reach your backend.

AI adds the proxy config. It rarely asks how you deploy.

The fix

Use different setup for dev and prod:

Dev: proxy in next.config if you want
Prod: full backend URL in env, CORS enabled on the backend

Run next build the same way CI does before you call it done. next dev alone is not enough.

6. Server-only code imported in a client component

The problem

Next has a hard line between server code and client code. Files marked "use client" run in the browser. Things like reading request headers or secret env vars only work on the server.

One shared lib/api.ts file often gets imported everywhere. AI merges duplicate files and accidentally puts server code inside a client component. Build fails or you get strange runtime errors.

The fix

Keep two files:

One for the browser (simple fetch, public env only)
One for the server (secret env, used only in app/api routes or server components)

If it reads cookies, headers, or private env, it never goes in a "use client" file.

7. Login token is valid but for the wrong app

The problem

Some apps check two things: is the user logged in, and does their role match this specific product. You paste a login token into .env.local. It is not expired. The app still sends you back to the login page.

The token belongs to a different dashboard or role. AI tries to fix the redirect logic. The check is working. Your token is for the wrong app.

The fix

Make sure three things match: the role setting in env, the role inside the token, and what the app's auth guard expects. When testing locally, use a token created for this app specifically.

8. Fake login still turned on while shipping real auth

The problem

Many teams add a dev-only flag that skips real login so they can build UI faster. Useful. Easy to forget about.

You say auth is done. But callback, token refresh, sign out, and role redirect were never tested with real login. AI sees a user object in state and assumes auth works.

The fix

Use the skip-login flag only for UI work. Before merging: turn it off, log in for real, open a protected page, sign out.

9. Old dev server still running on the port

The problem

You run pnpm dev again without closing the last one. Port 3000 is busy. Next starts on 3001. You keep refreshing 3000 and see the wrong app or nothing useful.

AI will debug your React code. It will not check which process owns the port.

The fix


lsof -i :3000

Kill the old process. Start fresh. Confirm which port the terminal says before debugging anything else.

10. No conflict on your machine, conflict on GitHub

The problem

You updated your branch with the latest main locally. Merge looks clean. The pull request on GitHub still shows conflicts.

Your local branch and the copy on GitHub are not the same history anymore. GitHub compares the remote branch to main, not your rebased local copy.

AI says "pull main again." You already did. On your machine only.

The fix

After rebasing locally, update GitHub:

git push --force-with-lease origin your-branch

Only use this when you intentionally rebased or rewrote branch history.

Check they match:

git log origin/your-branch..HEAD

No output means local and remote are in sync.

11. Expired login token in your env file

The problem

For local development, some apps read a login token from .env.local and attach it to server-side API calls. Tokens expire. Handlers return 401 Unauthorized. The UI shows empty data or error states.

Looks like the API is broken. AI rewrites error handling. The token is just old.

The fix

Decode the token and check the expiry time. Get a fresh one from a real login. Treat dev tokens like passwords with an expiration date.

12. Public env vars set after the build, not during it

The problem

NEXT_PUBLIC_ values are written into the JavaScript at build time.

If you set them in your hosting dashboard after the build already ran, the live site still has the old values baked in.

Works on your machine with .env.local. Wrong API address or app setting in production.

The fix

Make sure public env vars exist before next build runs in CI. Some teams write a .env.production file in the build step. Check build logs, not just runtime settings in the host UI.

13. Copied env from the wrong app in the same repo

The problem

Two Next apps in one repo look similar. Same folders, same tools. Different env needs. Copy .env.local from one app into another.

The shell loads. The first API call or redirect fails. AI assumes env is fine because the file is there.

The fix

Every app has its own .env.example. Start from that file every time.

Env is per app, not per repo.

14. Login page and dashboard on the same local port

The problem

Login usually lives on one app. The dashboard on another. In local dev that means different ports (for example 3001 for login, 3000 for dashboard).

If both URLs in env point to the same port, redirects get confused. Loops, wrong landing page, sign out going nowhere useful.

The fix

Write down the flow: login address → callback → dashboard address.

Set env to match separate apps, even on localhost.

15. Green code review, nobody ran a production build

The problem

AI fixed the component in the prompt. Types pass. Review looks good. Nobody ran a full production build with real login and a real API call.

The fix

Before merge:

next dev starts without warnings
next build passes with the same config CI uses
One real login (skip-login flag off)
One API call that returns real data

Conclusion

AI is strong inside a single file. It is weak on repo layout, env setup, static vs server deploy, and whether your GitHub branch matches your local branch.

Those live outside the chat window. Check them yourself and a lot of "random" Next.js bugs stop being random.

Need Help With Your Next.js or AWS Project?

Over the last 5+ years, I've helped build and maintain production systems used by businesses across different industries. If you're looking for help with:

Next.js applications
React architecture
AWS deployments
AI integrations
Performance optimization

feel free to reach out.

LinkedIn: Femi Akinyemi
DEV: dev.to/femi_akinyemi
Portfolio: Femi Akinyemi

Wedding Memories: The Collaborative Wedding Album!

Femi Akinyemi — Fri, 11 Oct 2024 15:28:15 +0000

Wedding Memories

This is a submission for the The Pinata Challenge

What I Built

Wedding Memories is an app designed to capture, share, and cherish every unforgettable moment from your special day! It allows wedding guests to easily upload photos, creating a collaborative album that captures the essence of the celebration. By using Pinata's Files API, the app provides a seamless experience for secure and efficient media uploads and storage.

Demo

Check out the live version of the app here: Wedding Memories

Screenshots:

Upload Section - A user-friendly interface for selecting and uploading media files:

Gallery View - Displays all uploaded memories in a responsive layout:

Mobile-Optimized Design - Ensures smooth user experience across all devices:

Download Options - Guests can download their favourite moments to keep memories forever.

My Code

You can explore the full code for this project on GitHub:

More Details

Wedding Memories leverages Pinata’s Files API to build secure and efficient file uploads. Below is a brief breakdown of the integration:

File Uploads: Guests can easily upload images directly from their devices. This is accomplished using the pinata.upload.file, which uses JWT-based authentication to ensure secure file handling. Once uploaded, the files are securely stored, and their unique identifiers (CIDs) are generated for retrieval.
Local Previews Before Upload: To enhance the guest experience, wedding memories generate local previews of images before uploading them. This feature allows guests to confirm their selections and make adjustments, ensuring only their desired image is submitted.

After successful uploads, the files are rendered using the file API. This guarantees rapid access to the content, providing guests with a seamless experience when viewing shared memories.

Download Feature: Guests can now download their favourite photos directly from the app, making it easy to save cherished memories to their devices. The app includes an API route that facilitates the secure downloading of files.

API Integration Breakdown:

The building includes several key API routes, each designed to handle specific functionalities:

File Upload Endpoint

This accepts file uploads and stores them using Pinata’s upload function. It then generates a signed URL for easy access to the uploaded file.

import { NextResponse, NextRequest } from "next/server";
import { pinata } from "../../../../utils/config";


export async function POST(request: NextRequest) {
  try {
    const data = await request.formData();
    const file: File | null = data.get("file") as unknown as File;
    const uploadData = await pinata.upload.file(file)
    const url = await pinata.gateways.createSignedURL({
        cid: uploadData.cid,
        expires: 3600,
    });
    return NextResponse.json(url, { status: 200 });
  } catch (e) {
    console.log(e);
    return NextResponse.json(
      { error: "Internal Server Error" },
      { status: 500 }
    );
  }
}

API Key Generation (/api/key/route.ts):

Creates a temporary API key with permissions to pin files to IPFS.


/* eslint-disable @typescript-eslint/no-unused-vars */
import { NextResponse } from "next/server";
import { pinata } from "../../../../utils/config";

export const dynamic = "force-dynamic";

export async function GET() {
    try {
        const uuid = crypto.randomUUID();
        const keyData = await pinata.keys.create({
            keyName: uuid.toString(),
            permissions: {
                endpoints: {
                    pinning: {
                        pinFileToIPFS: true,
                    },
                },
            },
            maxUses: 1,
        })
        return NextResponse.json(keyData, { status: 200 });
    } catch (error) {
        console.log(error);
        return NextResponse.json({ text: "Error creating API Key:" }, { status: 500 });
    }
}

List Files (/api/listfiles/route.ts):

Retrieves a list of uploaded files from Pinata, allowing users to view all shared content in the gallery

import { NextResponse } from "next/server";
import { env } from "process";


export const dynamic = "force-dynamic";

export async function GET() {
  try {
    const options: RequestInit = {
      method: 'GET',
      headers: {
          Authorization: `Bearer ${process.env.NEXT_PUBLIC_PINATA_JWT}`,
      },
      cache: 'no-cache'
    };

    const response = await fetch('https://api.pinata.cloud/v3/files', options);

    if (!response.ok) {
      return NextResponse.json({ text: "Error listing files" }, { status: response.status });
    }

    const { data } = await response.json();
    return NextResponse.json(data, { status: 200 });
  } catch (error) {
    console.log(error, "Error listing files");
    return NextResponse.json({ text: "Error listing files" }, { status: 500 });
  }
}

Image Proxy (/api/proxy/route.ts):

Acts as a proxy for fetching images from external sources, ensuring users can easily access and download their images.

import { NextResponse } from 'next/server';


export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const imageUrl = searchParams.get('url'); // Get the image URL from the query string

  if (!imageUrl) {
    return NextResponse.json({ error: 'Image URL is required' }, { status: 400 });
  }

  try {
    const response = await fetch(imageUrl);

    if (!response.ok) {
      return NextResponse.json({ error: 'Failed to fetch image' }, { status: response.status });
    }

    const contentType = response.headers.get('content-type') || 'application/octet-stream';
    const imageBuffer = await response.arrayBuffer();

    return new NextResponse(imageBuffer, {
      headers: {
        'Content-Type': contentType,
        'Content-Disposition': 'attachment; filename="downloaded_image"',
      },
    });
  } catch (error) {
    console.error('Error fetching image:', error);
    return NextResponse.json({ error: 'Error fetching image' }, { status: 500 });
  }
}

Signed URL Creation (/api/sign/route.ts):

Generates signed URLs for uploaded files.


import { type NextRequest, NextResponse } from "next/server";
import { pinata } from "../../../../utils/config";

export const dynamic = "force-dynamic";

export async function POST(req: NextRequest) {
  try {
    const data = await req.json();
    const mimeType = data.mime_type;

    let url;

    if (mimeType === 'video/mp4') {
      url = await pinata.gateways.createSignedURL({
        cid: data.cid,
        expires: 7776000,
      })
    } else {
      url = await pinata.gateways.createSignedURL({
        cid: data.cid,
        expires: 7776000,
      }).optimizeImage({
        width: 300,
        height: 300,
        format: "webp",
        fit: "contain",
        quality: 90,
        dpr: 2,
        sharpen: 1,

      });
    }

    return NextResponse.json(url, { status: 200 });
  } catch (error) {
    console.log(error);
    return NextResponse.json({ text: "Error creating signed URL:" }, { status: 500 });
  }
}

The app is built with:

Pinata: File API
Frontend: React, Next.js, Framer Motion
Styling: Tailwind CSS for responsive, beautiful layouts.
Hosting: Amplify for deployment.

Conclusion

Weddings are joyous occasions filled with love, laughter, and countless memorable moments. Capturing these precious memories is essential, and with the Wedding Memories app, it's now easier than ever!

This application allows every guest to take lovely pictures on the event day and share them seamlessly, ensuring that no moment is missed and everyone has access to the collective memories of the celebration.

The app harnesses the power of Pinata's Files API to provide a secure and efficient way for guests to upload and share their photos and videos, creating a collaborative album that beautifully encapsulates the essence of the day.

For more details on how the app integrates with Pinata and to explore its capabilities, please refer to the Pinata documentation.

Thank you.

How to Upload Files to Amazon S3 with React and AWS SDK

Femi Akinyemi — Mon, 04 Mar 2024 15:54:14 +0000

INTRODUCTION

Have you ever needed to upload files from your React application to the cloud?

Amazon S3 (Simple Storage Service) provides a robust and scalable solution for storing and managing various file types.

Using the AWS SDK, this article shows how to build a React application that allows users to upload files to S3.

In the article, you'll learn how to handle file selection, validate file types, and handle the upload process with error handling.

By the end, you'll have a basic understanding of integrating file uploads to S3 with React and AWS.

Prerequisite:

Basic understanding of React and JavaScript.
An AWS account and access credentials to configure the S3 connection.

Getting Started

Creating S3 Bucket

The first thing to do is start by creating an S3 bucket. Log in to the AWS S3 console and follow the instructions to create a new bucket, as shown in the image below.

Making the files publicly accessible

Next is to edit the bucket policy to make the file publicly accessible.

Here's how:

Open the bucket: Go to the AWS S3 console and navigate to your specific bucket.
Access permissions: Click on the 'Permissions' tab.
Edit policy: Locate the 'Bucket policy' section and click the 'Edit Policy' button.
Paste JSON code: Copy and paste the following JSON code into the policy editor.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicListGet",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:List*",
                "s3:Get*"
            ],
            "Resource": [
                "arn:aws:s3:::YOUR_BUCKET_NAME",
                "arn:aws:s3:::YOUR_BUCKET_NAME/*"
            ]
        }
    ]
}

Save changes: Review the policy and click 'Save'.

The policy above makes all objects in the S3 bucket named YOUR_BUCKET_NAME publicly accessible. Anyone online can list and download all files in the bucket and its subfolders.

The policy should be used cautiously as it can be a security risk.

Editing CORS Policy

Now, you must enable Cross-origin resource sharing (CORS).
The CORS configuration, written in JSON, allows clients to access resources in a different domain from applications within the same domain.

Scroll down a bit more, and you will see a section where you can edit CORS settings.

Paste the below JSON into it to enable the upload of files from the front end, or you will receive a CORS error while uploading files.


[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "PUT",
            "POST",
            "DELETE",
            "GET"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": []
    }
]

Uploading files to your AWS S3 bucket is now possible.

Next, we'll talk about the front end.

Run the command below to Scaffold your react application.


npx create-react-app filestorage
cd filestorage
npm start

Installing AWS SDK for JavaScript

You must install the AWS SDK for JavaScript, allowing your React JS application to communicate with S3.

Run the command below to install AWS SDK

npm install aws-sdk

Next is to replace the default code in the App.js file with the code below

import React, { useState } from 'react';
// Uncomment one of the following import options:
import AWS from 'aws-sdk'; // Import entire SDK (optional)
// import AWS from 'aws-sdk/global'; // Import global AWS namespace (recommended)
import S3 from 'aws-sdk/clients/s3'; // Import only the S3 client

import './App.css';

function App() {
  const [file, setFile] = useState(null);
  const [uploading, setUploading] = useState(false)

  const allowedTypes = [
    'image/jpeg',
    'image/png',
    'application/pdf',
    'video/mp4',
    'video/quicktime',
    'audio/mpeg',
    'audio/wav',
    // Add more supported types as needed
  ];

  const handleFileChange = (event) => {
    const selectedFile = event.target.files[0];
    if (allowedTypes.includes(selectedFile.type)) {
      setFile(selectedFile);
    } else {
      alert('Invalid file type. Only images and PDFs are allowed.');
    }
  };

  const uploadFile = async () => {
    setUploading(true)
    const S3_BUCKET = "your_bucket_name"; // Replace with your bucket name
    const REGION = "your_region"; // Replace with your region

    AWS.config.update({
      accessKeyId: "your_accesskeyID",
      secretAccessKey: "your_secretAccessKey",
    });

    const s3 = new S3({
      params: { Bucket: S3_BUCKET },
      region: REGION,
    });

    const params = {
      Bucket: S3_BUCKET,
      Key: file.name,
      Body: file,
    };

    try {
      const upload = await s3.putObject(params).promise();
      console.log(upload);
      setUploading(false)
      alert("File uploaded successfully.");

    } catch (error) {
      console.error(error);
      setUploading(false)
      alert("Error uploading file: " + error.message); // Inform user about the error
    }
  };

  return (
    <>
      <div className="">
        <input type="file" required onChange={handleFileChange} />
        <button onClick={uploadFile}>{uploading ? 'Uploading...' : 'Upload File'}</button>
      </div>
    </>
  );
}

export default App;

The React code above creates a simple file uploader app. Users can select a file that is uploaded to an Amazon S3 bucket.

Here's a brief breakdown:

State Management: It uses React's useState hook to manage the selected file and uploading state.
Allowed File Types: Defines an array of allowed file types.
File Change Handler: When a file is selected, it checks if the file type is allowed and updates the state with the selected file.
Upload Function: Constructs S3 parameters and uploads the file to the specified S3 bucket. It handles success and error cases, providing feedback to the user.
User Interface: Provides a file input field and a button for uploading—the button text changes based on the uploading state.
AWS SDK: Imports necessary modules from the AWS SDK to interact with S3 and configures it with credentials and region.

The code offers a basic file uploading functionality to S3 from a React app.

Conclusion

You've successfully uploaded a file to your S3 bucket with these steps! You can consult the documentation for tailored options that suit your specific requirements.

Build a simple project management app with Neon, PostgREST, and DigitalOcean

Femi Akinyemi — Tue, 27 Feb 2024 16:29:41 +0000

Introduction

Neon s erverless Postgres stands out in the world of databases. It provides a fully managed service for PostgreSQL with unique features like autoscaling, branching, and a great serverless experience. Its architecture makes Neon serverless Postgres different from how users set up Postgres databases by separating storage and compute.

In this guide, we'll leverage the strengths of Neon serverless Postgres to establish a PostgREST API on DigitalOcean. With PostgREST, a PostgreSQL database is turned into a RESTful API.

As a practical illustration, we’ll walk through creating a mini project management application with complete create, read, update, and delete (CRUD) functionality. This application will allow users to create new projects, view existing details, update information, and delete projects as needed.

Ultimately, you’ll have a fully functional PostgREST API powered by Neon serverless Postgres, seamlessly incorporated into your DigitalOcean environment.

Prerequisites

To fully grasp the concepts presented in this tutorial, you’ll need the following:

A Neon account
A DigitalOcean account
A basic understanding of PostgreSQL and REST APIs
Node.js installed on your local machine

Create a Neon project

To set up a Neon project, let’s begin by registering for an account, assuming you don't have one already. With that done, we’ll create a new project by selecting a Project Name. We will use (Project Management), Database name (managementdata), and Postgres version. For this demonstration, we’ll opt for 16 as the Postgres version and choose the region closest to where we would like to deploy our app.

Upon successfully creating the project, we will get a connection string for connecting to our database.

Project directory

To organize our project files and resources, let's create a new project directory using the following terminal command:

    mkdir neonprojectappfolder

Loading demo data into the database

With the project directory in place, follow these steps to load the demo data into the database.

To connect to our database, we will use the connection string provided by Neon and run it in the terminal:

    psql 'postgresql://xxx:xxxx@ep-xxx-xxx-01196450.us-east-2.aws.neon.tech/xxx?sslmode=require'

The command connects to the database using the provided connection string.

Now that we’re connected to the database, let’s upload our demo data by running the command below in the terminal:

    psql 'postgresql://xxx:xxxx@ep-xxx-xxx-01196450.us-east-2.aws.neon.tech/xxx?sslmode=require < projects.sql

The demo data (projects.sql) can be downloaded here.

The demo data must be downloaded in our project directory before running the command above.

Upon successfully loading demo data into the database, we’ll see a response like the image below:

The output CREATE SEQUENCE, CREATE TABLE, and INSERT 0 5 indicate that the sequence, the table, and five rows were inserted into the table, respectively.

Next, we verify the demo data is present using the following steps:

First, connect to the database again by running the command below:

    psql 'postgresql://xxx:xxxx@ep-xxx-xxx-01196450.us-east-2.aws.neon.tech/xxx?sslmode=require'

(Just a note that we’re connecting to the database again because we exited the database when we loaded the demo data into the database.)

Now, let us run the command below in our terminal:

    select * FROM projects LIMIT 1

The SQL command SELECT * FROM projects LIMIT 1 retrieves data from the "projects" table.

We should get a response like the one in the image below.

As a result, our demo data has been successfully uploaded to our database.

PostgREST setup

Now that we have set up our database, the next step involves setting up PostgREST. First, we install PostgREST by following this installation guide.

After a successful installation, we can confirm everything works perfectly by typing postgrest -e in the terminal. We should see a response similar to the image below, indicating a successful operation.

Granting CRUD access to a database user

Now, we can connect to the database using the connection string above.

(We’re connecting again because checking the PostgREST installation disconnected us from the database.)

After a successful connection, execute the command below:

    GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE public.projects TO femakin

The command grants femakin user permissions for SELECT, INSERT, UPDATE, and DELETE operations (CRUD) on the projects table in the public schema.

PostgREST connection setup

The next step is to establish a PostgREST connection. To do this, exit the database terminal by typing \q and then enter the following command: vi projects.config.

The command vi projects.config opens the projects.config file using the vi text editor.

We then edit the projects.config file by pasting the command below.

    db-uri = psql 'postgresql://xxx:xxxx@ep-xxx-xxx-01196450.us-east-2.aws.neon.tech/xxx?sslmode=require'
    db-schema = "public"
    db-anon-role = "femakin"

This configuration specifies a PostgreSQL database connection string URI with credentials and connection details. It also defines the default database schema as public and the anonymous role as femakin for authentication purposes.

To ensure the proper setup of the PostgREST connection, we can run postgrest projects.config in the terminal. This command should yield a response similar to the image below.

Testing the API routes

Now, let us employ a tool such as Postman to conduct tests. In the browser, navigate to the URL localhost:3000/projects.

The connection is working if we find something like this in the browser.

Otherwise, we must review all the steps and ensure everything is present.

Bootstrapping VueJS application

The quickest approach to get started with our VueJS application is to clone this Git H ub repository :

    git clone https://github.com/femakin/Neo-Demo-PostgREST-DigitalOcean-App

Follow the instructions in the README file: Run npm install to install dependencies and npm run dev to start the application.

The application will appear like this in the browser:

The code in the src/App.vue is a project management app using VueJS. It handles project data, loading status, and user interactions. It fetches project data and lets users view, add, update, and delete projects. The focus is on simplicity for managing projects in a web app.

Deploying to Digital Ocean

Thus far, we’ve created our database, set up PostgREST, and got our mini-application running in VueJS. Now, we need to deploy everything to DigitalOcean. To do this, log into the DigitalOcean dashboard and create a Droplet by following this guide.

DigitalOcean Droplets are Linux-based virtual machines (VMs) that operate on virtualized hardware.

Now, let’s access our droplet. First, copy the created droplet's IP address, as shown in the image below, and then use it to SSH into the droplet.

Note: Keep this IP address handy; we’ll need it for future steps.

Next, log into the droplet by using the copied droplet's IP and running the command below in the terminal:

    ssh root@copied_droplet_IP

This will prompt us to enter a passphrase for the key.

Next, we will update the apt cache to get the latest packages by running the below command:

    sudo apt update

A runtime library, an essential component of the PostgreSQL database system, must be installed. This library is a connection and communication interface for PostgreSQL database servers.

Let’s run the following command in the terminal to install the PostgreSQL runtime library, libpq5:

    sudo apt install libpq5

This command will ensure that the necessary runtime components for PostgreSQL are installed on the system.

Now, we’ll install PostgREST from the release page available here. Choose a version compatible with your operating system; for example, we will install postgrest-v11.2.0-linux-static-x64.tar.xz.

    wget 'https://github.com/PostgREST/postgrest/releases/download/v11.2.0/postgrest-v11.2.0-linux-static-x64.tar.xz'

Next is to extract the compressed file to obtain the executable. Run the command below in the terminal:

    root@project-management:~# tar vxf postgrest-v11.2.1-linux-static-x64.tar.xz
    postgrest

To ensure everything works, let's run the following command:

    ./postgrest -e

We should expect a response similar to the image below.

Configuring PostgREST on Droplet

Let us configure PostgREST by following the steps below.

Move PostgREST to usr/bin by executing the following command:

    sudo mv postgrest /usr/bin

Navigate to /usr/bin using the command

    cd /usr/bin

Confirm that everything is in order by running

    ./postgrest -e

Now, create a directory using the command

    mkdir projectsmanagement

Let's return to our local machine within the project directory and copy the config file using:

    cat projects.config

We previously created the config file in the section above. We’ll see a configuration similar to the one below:

    db-uri = psql 'postgresql://xxx:xxxx@ep-xxx-xxx-01196450.us-east-2.aws.neon.tech/xxx?sslmode=require'
    db-schema = "public"
    db-anon-role = "femakin"

Then, return to our droplet and create a new config using:

    vi projects.config

Paste the copied projects.config, and save the file.

Now, we can connect to our database using postgrest postgrest.config.

You should now see a response stating that the connection is successful, as shown in the image below:

Now, we can test the API using the command curl localhost:3000/projects, and observe a response from our database, like the illustration below.

Creating systemd

Now, let's create a system service for a PostgREST. We need to go back to PostgREST documentation here.

We can now go back to our droplet and create the system file using the command below:

vi /etc/systemd/system/postgrest.service and paste the code below:

    [Unit]
    Description=REST API for any PostgreSQL database
    After=postgresql.service

    [Service]
    ExecStart=/usr/bin/postgrest /usr/bin/postgrest.config
    ExecReload=/bin/kill -SIGUSR1 $MAINPID
    User=nobody
    Group=nogroup

    [Install]
    WantedBy=multi-user.target

Here, we’ll reload, start, and check the status of the systemd using the command below.

     sudo systemctl daemon-reload
     sudo systemctl start postgrest
     sudo systemctl status postgrest

Testing the API using curl localhost:3000/projects gives us our expected response, as shown below:

Uploading the Vue app into Droplet

It's time to upload our project management application into the droplet. Return to your local machine to upload the application into the droplet and run npm run build inside the project directory.

Now that we have our production Vue App, we can copy it into the droplet using the command below:

    scp -r dist root@copied_droplet_IP:/usr/bin/vueapp

Next is to install a web server to serve the files.

    sudo apt install nginx

Next is to create a virtual host using:

    sudo vi /etc/nginx/sites-available/copied_droplet_IP

Paste the code below and save.

We can now create a link using.

    sudo ln -s /etc/nginx/sites-available/copied_droplet_IP  /etc/nginx/sites-enabled/

Then reload nginx using

    sudo systemctl reload nginx

Testing deployment

We can now go to the browser and paste the copied_droplet_IP. We should see our project management app on the page.

However, we will see an error if we look at the console. This error is there because we have not set up the API server.

To take care of this, we must use nginx to proxy /API to the PostgREST instance running on our droplet, as described in this PostgREST documentation.

We can now edit our nginx configuration using

    sudo vi /etc/nginx/sites-available/Copied_IP

Then, update the configuration with the command below.

     location /api/ {
          default_type  application/json;
          proxy_hide_header Content-Location;
          add_header Content-Location  /api/$upstream_http_content_location;
          proxy_set_header  Connection "";
          proxy_http_version 1.1;
          proxy_pass http://localhost:3000/;
        }

Then reload nginx using:

    sudo systemctl reload nginx

We can now return to the browser and paste the copied Droplet IP. Now, we can see our application without any errors.

Congratulations! You successfully created a mini-project management application by seamlessly integrating PostgREST and DigitalOcean, backed by Neon serverless Postgres.

Here are a few recommendations to take it further.

Add a domain to the Droplet
Configure HTTPS
Add more features to the applications

The possibilities are endless when it comes to Neon serverless Postgres.

Conclusion

We covered a lot in this tutorial. Let’s recap! You accomplished the following:

Leveraged Neon serverless Postgres to establish a PostgREST API on DigitalOcean.
Transformed a PostgreSQL database into a functional RESTful API using PostgREST.
Created a mini-project management application as a practical illustration using VueJS.
Demonstrated seamless integration between Neon serverless Postgres, PostgREST, and DigitalOcean.

References

Understanding AWS Amplify Monitoring Metrics Definitions

Femi Akinyemi — Thu, 08 Feb 2024 12:52:21 +0000

One of the App settings provided by AWS Amplify is Monitoring, which allows us to monitor metrics like site traffic, configure alarms, and access logs for our Amplify applications in nearly real time.

In this article, we will look at the definitions of CloudWatch metrics in the AWS/AmplifyHosting namespace for monitoring our app traffic, errors, data transfer, and latency.

When we decide to monitor our app hosted on AWS Amplify, we navigate to the app settings sidebar and click on the Monitoring tab, which takes us to the monitoring page, as shown in the image below.

So, what do all these terms mean?

According to the Monitoring and CloudWatch section of the AWS Amplify Hosting, Here is what they mean.

Requests: This is the total number of viewer requests Amplify Hosting receives for all HTTP methods and HTTP and HTTPS requests, which means it is how often people visit our website hosted on Amplify, including all types of requests like clicking links or loading pages with HTTP or HTTPS.

Bytes downloaded: The total amount of data transferred out of our app (downloaded) in bytes by viewers for GET, HEAD, and OPTIONS requests, which means it shows the total data sent from our app to users when they download something, like images or files, through actions like clicking links or accessing pages.

BytesUploaded: This is the total amount of data transferred into our app (uploaded) in bytes using POST and PUT requests. Therefore, it represents the complete data our app receives when users upload files or submit forms, typically through actions like posting comments or uploading images.

4XXErrors: The number of requests that returned an error in the HTTP status code 400-499 range. This metric counts the requests that encountered errors on the user's end, like entering incorrect information or trying to access restricted content, resulting in an error response from the server.

5XXErrors: The number of requests that returned an error in the HTTP status code 500-599 range. This metric counts the requests that encountered errors on the user's end, like entering incorrect information or trying to access restricted content, resulting in an error response from the server.

Latency: This metric measures how quickly Amplify Hosting responds to a request, from when it receives it until it sends the first byte of data back to the network. It excludes the time the response travels to the viewer's device.
Key statistics include the average, maximum, minimum, and various percentiles (p10, p50, p90, p95, p100), providing insights into response times across different scenarios.

For more details about the metrics, we can access the CloudWatch metrics in the AWS Management Console here.

How to add Astro social share to your Astro application

Femi Akinyemi — Mon, 08 Jan 2024 05:44:36 +0000

Introduction

Astr o is a modern web framework that combines the best features of static site generators (SSGs) and server-side rendering (SSR) frameworks. It is designed to be fast, flexible, and easy to use, making it an excellent choice for building various websites, including blogs, portfolios, e-commerce sites, and more.

Astro offers several benefits, including:

Speed: Astro websites are typically very fast, thanks to server-side rendering and component islands.
SEO: Astro websites are also well-suited for SEO, as they are static and can be pre-rendered.
Flexibility: Astro is a very flexible framework, and many websites can be built.
User-friendliness: Astro is beginner-friendly and offers a gentle learning curve, making it accessible even for those new to web development.

One of the benefits of using Astro is that it makes it easy to add social sharing buttons to your website. Social sharing is essential because social sharing is a great way to increase traffic to your website and promote your content.

Social sharing is essential for web applications because it can help to:

Boost website traffic
Content promotion
Establish brand presence
Lead generation and sales

This article explains how to add social sharing buttons to your Astro application.

In this article, you will build an application that displays random jokes using the random dad joke API with a social share button using Astro social share.

The source code for the application is readily available here on GitHub.

By the end of this article, you will have a better understanding of:

What is Astro social share?
How to install Astro social share
How to use Astro social share # Understanding Astro social share

Astro social share is your Astro site's social media share button. It's also one of the recently added Astro integrations.

Astro social share comes with some good features, which are:

No dependencies or external scrips
Share buttons for:
- Facebook
- Hacker News
- LinkedIn
- Reddit
- Twitter
Icons included from https://simpleicons.org/ # Prerequisites

To fully grasp the concepts presented in this article, the following are required:

Basic understanding of JavaScript
Node.js installed, version v18.14.1 or later.
Code Editor - Preferably VS Code or another code editor. # Bootstrapping Astro application

To bootstrap your Astro application, you will use the create astro setup wizard following the steps below:

Install Astro by running the following command in your terminal:

npm create astro@latest

Confirm your choice by typing 'y' to install the create-astro package.
When prompted to specify the location for your new project, enter the folder name where you'd like to create a new project directory. For example, you can type. /Astro-Social-Share.
You'll be presented with a list of starter templates. Use the arrow keys (up and down) to navigate to the "Empty" template, and then press the Return or Enter key to select it.
When asked if you want to install project dependencies, type y.
If you are asked whether you plan on using TypeScript, type n.
When prompted about initializing a new git repository, type y.

Now, you can navigate to your Astro-Social-Share directory to begin and preview your application by running the command below in your terminal:

cd cd Astro-Social-Share

npm run dev

Click the localhost link within your terminal window to view a real-time preview of your brand-new Astro website!

This is how the browser preview of the Astro 'Empty Project' starter website should appear:

Setting up API page

Now, you need to set up the Home Page. The home page will be the entry point for your application's home page. In the src/pages/index.astro, paste the code below:


    ---
    import {GET} from "../pages/api/fetchdata";

    import { TwitterShareButton, SocialShare } from "astro-social-share";
    const TwitterBUTTON = [TwitterShareButton];

    let response = await GET();
    const data = await response.json();
    ---

    <html lang="en">
      <body>
        <div class="h-screen flex flex-col items-center">
          <h1 class="text-3xl font-bold mt-12 mb-12">Share Your Daily Joke on X</h1>

          <p
            id="joke-btn"
            class="bg-blue-500 hover-bg-blue-700 text-white font-bold py-2 px-4 rounded">
            Click on the X icon below to share your daily joke
          </p>

          <div class="mt-12" id="joke-container">{data.joke}</div>

          <SocialShare
            buttons={TwitterBUTTON}
            description={data?.joke}
            via="akinyemi_t"
            title={data.joke}
          />
        </div>
      </body>
    </html>

Here is the explanation of the code provided above:

The first line imports the GET function from a file at ../pages/api/fetchdata. It suggests that you are making a GET request to fetch some data.
Next, you import components related to social sharing using Astro. Specifically, you import the TwitterShareButton and SocialShare components from the astro-social-share library.
You define TwitterBUTTON as an array containing the TwitterShareButton. This variable plays a role later when configuring social sharing.
The code then awaits the result of the GET request, assigns it to the response variable, and parses the JSON content from the response into the data variable.
The HTML section starts with the opening <html> tag and defines the web page's structure.
Inside the <body> tag, the content of the web page looks as follows:
- A <div> element with the class h-screen flex flex-col items-center is used to center the content vertically in the viewport.
- An <h1> element with the text Share Your Daily Joke on X is displayed at the top of the page.
- A <p> element with the ID joke-btn displays a message encouraging the user to click an X icon below to share a daily joke.
- Another <div> element with the ID joke-container displays the content of the data.joke property, which contains the daily joke fetched from the API.
- The <SocialShare> component enables sharing on social media. Configured with the buttons prop set to TwitterBUTTON (likely to display a Twitter share button), the description assigned to the data.joke set to akinyemi_t (the Twitter username), and the joke's title. Text.

Testing and debugging

Follow the steps below to test your application:

Navigate into your directory and run

npm run dev

Your application is now running at localhost:4321

To view your homepage, visit localhost:4321 in your browser. You should see the homepage.

Now, you can share your joke on social media by clicking the X icon.

What's next?

There are so many other things you can do with Astro social share. You can integrate other social buttons, like

Facebook
Hacker News
LinkedIn
Reddit
Twitter

Also, you can make the application more interactive by adding more features like changing the jokes.

Conclusion

Astro is a fast and flexible web framework suitable for various website types. Adding social sharing buttons to your Astro application enhances traffic, content promotion, brand presence, and lead generation.

This article has shown how to integrate social sharing buttons using the Astro social share component, using a random joke application as an example.

The provided GitHub source code serves as a practical reference.

By following the article, you've gained the ability to empower your web applications with Astro social share, making your content more shareable and engaging.

DEV Community: Femi Akinyemi

Why PageSpeed says reduce unused JavaScript

What the line actually measured

Why a file that never ran still costs the visit

The three kinds of files on the list

What to leave alone

How to read one row

Where to start

Why a website feels slow on a phone

What people feel on a phone

Why your computer hides the wait

Why the usual check misses it

What a useful phone check does

How to check a page today

If you send sites to clients

FAQ

Why is my website slow on a phone but fine on my computer?

Should I test website speed on a phone?

Does a high score on my computer mean the site is fast?

Does PafCore test on a phone?

A fast homepage can still hide a slow site

What people feel that you miss

Why the usual tools stop at one URL

Pages that hide the wait

What a useful check does

How to check more than your homepage

For freelancers and agencies

FAQ

Does PageSpeed Insights check my whole website?

Why is my homepage fast but checkout is slow?

Should I only test my homepage?

Can PafCore scan a whole site?

What usually slows a WordPress site

What people feel first

What usually slows WordPress

Why a tip list is hard to use

What a useful report does

How to try it on your WordPress site

For freelancers and agencies

FAQ

Is PageSpeed Insights enough for a WordPress site?

Is slow WordPress always a hosting problem?

Do plugins always make WordPress slow?

Does PafCore replace WordPress speed plugins?

When PageSpeed Insights is enough (and when it is not)

Introduction

What PageSpeed Insights is good at

Where a single run fools you

When manual checks stop being enough

You watch more than a handful of pages

A deploy can break speed overnight

You need history, not only today’s screenshot

You need budgets and alerts

You need something a client can read

A plain comparison

Use both. Split the jobs.

A week one checklist

Conclusion

FAQ

Why your Lighthouse score changes when you did nothing

Introduction

Why the number moves

What you will set up

Step 1. Measure a quiet page

Step 2. Ship the change, then measure again

Step 3. Write the slow thing in seconds

Step 4. Do not drown in the tip list

Step 5. Put numbers in the pull request

What you get from this habit

Conclusion

What AI Still Misses in Production Next.js Apps

Introduction

1. Next dev watching the whole monorepo

2. Putting server secrets in NEXT_PUBLIC_*

3. API address missing or duplicating /api/v1

4. Adding server API files to an app that deploys as static HTML

5. Local proxy setup that does not exist in production

6. Server-only code imported in a client component

7. Login token is valid but for the wrong app

8. Fake login still turned on while shipping real auth

2. Putting server secrets in `NEXT_PUBLIC_*`

3. API address missing or duplicating `/api/v1`

4. Adding server API files to an app that deploys as static `HTML`