{
  "title": "Lighthouse Scores Are Not the Same as Perceived Performance",
  "description": "What I learned after implementing CSS View Transitions on my static blog — how measured performance and perceived speed can tell very different stories.",
  "locale": "en",
  "slug": "performance-and-transition-ux",
  "url": "https://engineer-blog.tomoki-ttttt.workers.dev/en/articles/performance-and-transition-ux/",
  "publishedAt": "2026-05-16T17:00:00.000Z",
  "tags": [
    "performance",
    "frontend",
    "astro",
    "ux",
    "web"
  ],
  "projectIds": [],
  "markdown": "## Introduction\n\nRecently, I rebuilt my personal tech blog.\n\nFor this blog, I have been paying a lot of attention to performance.\n\nI wanted it to be lightweight, fast, and free from unnecessary client-side JavaScript.  \nThat is why I chose Astro and built the blog as a mostly static website.\n\nAt first, I cared a lot about Lighthouse scores.\n\nFCP, LCP, TBT, CLS, Speed Index.  \nSeeing those numbers improve felt good, and it made performance improvements feel visible.\n\nBut while building the blog, my thinking started to change.\n\n**A good Lighthouse score and a good user experience are not always the same thing.**\n\nThe moment that made this concrete for me was when I added SPA-style page transition animations to the blog.\n\nIn this article, I want to write about what that experience taught me — specifically, the gap between measured performance numbers and how fast a site actually feels.\n\n## At first, I cared a lot about Lighthouse\n\nWhen working on performance, Lighthouse is one of the easiest tools to start with.\n\nIt gives you a score.  \nIt shows metrics.  \nIt tells you what can be improved.\n\nEspecially in personal projects, it is easy to get lost and wonder what to improve first.  \nIn that sense, Lighthouse is very helpful.\n\nI also started by looking at Lighthouse quite a lot.\n\n- What is the Performance score?\n- How fast is FCP?\n- How fast is LCP?\n- Is there any TBT?\n- Is CLS close to zero?\n- Is Speed Index acceptable?\n\nI checked these numbers while reducing CSS, removing unnecessary JavaScript, and reviewing images and fonts.\n\nThat itself was not a bad thing.\n\nIn fact, Lighthouse was very useful for improving the initial page load.\n\nBut after a while, I started to feel that something was missing.\n\n## Good scores, but not always a good feeling\n\nThe Lighthouse score was good.\n\nThe initial load was fast.  \nLCP was fine.  \nTBT was almost zero.  \nCLS was not a problem.\n\nBut when I actually used the site, sometimes it did not feel as good as the numbers suggested.\n\nFor example:\n\n- There was a slight delay after clicking a link.\n- Page transitions felt too abrupt.\n- Clicks did not always feel responsive.\n- Going back and forward felt a little stiff.\n- The numbers looked fast, but the experience did not always feel fast.\n\nThese things are hard to notice if you only look at Lighthouse.\n\nLighthouse is mainly useful for evaluating page load performance.  \nIt is especially helpful for understanding the first load.\n\nBut users do not only experience the first load.\n\nThey move from the article list to an article.  \nThey move from one article to another.  \nThey go back to the homepage.  \nThey open tag pages.  \nThey navigate around the site many times.\n\nThat kind of experience cannot be fully measured by Lighthouse alone.\n\n## Initial load speed and page transition feel are different things\n\nI think there are several kinds of “speed” on the web.\n\nFor example:\n\n- How fast the first page appears\n- How fast the main content becomes visible\n- How quickly the site responds after a click\n- How fast page transitions complete\n- How smooth scrolling and interactions feel\n- Whether the site feels pleasant to use\n\nThese are related, but they are not exactly the same.\n\nLighthouse is good at evaluating the initial loading experience.\n\nAnd of course, that matters a lot.  \nFor a blog, many visitors come directly from search engines or social media, so the first page load should be fast.\n\nBut if you also care about visitors moving around inside the site, the first load is not enough.\n\nDoes the page transition feel good?  \nDoes the site respond immediately after a click?  \nDoes the screen change naturally?  \nDoes the transition interrupt the reading flow?\n\nI started to feel that these things matter a lot too.\n\n## MPA can be faster, but SPA can feel faster\n\nThis blog is basically built like an MPA.\n\nAstro generates static HTML, and the site does not ship more client-side JavaScript than necessary.  \nFor a blog, I think this is a very natural architecture.\n\nMPA is simple and strong.\n\nEach page can be delivered as an independent HTML document.  \nIt is easier to make the first load fast.  \nThere is less dependency on JavaScript.  \nIt is more robust.  \nIt is also easier to handle SEO and accessibility.\n\nFor a personal blog, MPA is a very good fit.\n\nOn the other hand, SPA also has its own strengths.\n\nThe entire page does not reload during navigation.  \nOnly the necessary data or components are replaced.  \nIt is easier to give immediate feedback after clicking a link.  \nIt is also easier to add smooth transition animations.\n\nAs a result, even if the actual network or processing time is not always shorter, an SPA can sometimes **feel faster**.\n\nI think this is an important point.\n\nFor example, even if an MPA is faster in raw numbers, users may feel a delay if the page suddenly turns blank before the next page appears.\n\nOn the other hand, in an SPA, even if some processing is happening in the background, the experience can feel faster if an animation starts immediately after a click and the screen changes smoothly.\n\nIn other words, there is **measured speed** and **perceived speed**.\n\nThese two are related, but they are not the same.\n\n## I actually implemented CSS View Transitions\n\nI added SPA-style page transitions to this blog to see what would happen.\n\nThe tools I used were Astro's `ClientRouter` and the browser-native View Transitions API.\n\n`ClientRouter` is Astro's client-side router. It removes full-page reloads during navigation, giving the site SPA-like behavior. Combined with the View Transitions API, it makes it possible to animate elements between pages using nothing but CSS.\n\nThere were two main things I set up.\n\nFirst, I assigned `view-transition-name` to the header, main content area, and footer.  \nThis tells the browser which elements to treat as distinct layers during a transition.\n\n```css\n.site-header { view-transition-name: site-header; }\n.site-main   { view-transition-name: site-main; }\n.site-footer { view-transition-name: site-footer; }\n```\n\nSecond, I disabled animation on the header and footer — keeping them instant — and only animated the main content area.  \nIf the header fades in and out on every navigation, it becomes distracting. Animating only the content creates a natural sense of \"the page changed\" without the chrome feeling unstable.\n\n```css\n::view-transition-old(site-header),\n::view-transition-new(site-header),\n::view-transition-old(site-footer),\n::view-transition-new(site-footer) {\n  animation: none;\n}\n```\n\nBefore and after this implementation, I ran Lighthouse again.\n\nThe scores barely moved. Performance, FCP, LCP, TBT, CLS — the numbers looked the same.\n\nBut the experience of clicking a link felt noticeably different.\n\nBefore: click a link, the page flashes white, the next page appears.  \nAfter: the content fades out, the next content fades in. The header stays exactly where it is throughout.\n\nIt was not that the site felt \"faster\" in a measurable sense.  \nIt felt more like the friction was gone.\n\nThat was the clearest example I found of the gap between measured performance and perceived speed.\n\nLighthouse had nothing to say about it. The improvement was real, but invisible to the tool.\n\n## Animation is not the enemy\n\nWhen working on performance, it is easy to think that animations should be removed because they can make a site heavier.\n\nOf course, excessive animations are not good.\n\nFor example:\n\n- Too many scroll-linked animations\n- Heavy JavaScript calculations\n- Animations that trigger layout recalculations\n- Janky motion on low-end devices\n- Animations that interrupt reading\n\nThese can make the experience worse.\n\nBut animation itself is not bad.\n\nIn fact, I think appropriate animation can improve perceived performance.\n\nFor example, animation can help when:\n\n- The site responds immediately after a click\n- A page transition feels natural\n- The change on the screen has context\n- The user does not lose track of where they are\n- Waiting time feels less like waiting\n\nIf you only look at performance numbers, animation may look unnecessary.  \nBut from a UX perspective, it can sometimes be useful.\n\nWhat matters is not whether to use animation or not.  \nWhat matters is **why the animation exists**.\n\nIf it is only decoration, maybe it should be removed.  \nBut if it gives feedback or makes page transitions feel more natural, it may be worth the small cost.\n\n## A fast site and a pleasant site are not exactly the same\n\nWhile building this blog, I realized that a fast site and a pleasant site are not exactly the same.\n\nA fast site can be measured to some extent.\n\nFast FCP.  \nFast LCP.  \nLow TBT.  \nNo CLS.  \nSmall JavaScript.  \nLight HTML.\n\nThese things are important.\n\nBut a pleasant site needs more than that.\n\nIt responds quickly when clicked.  \nTransitions feel natural.  \nScrolling is smooth.  \nThe screen does not change in a confusing way.  \nThe reading experience is not interrupted.\n\nThese things do not always appear clearly in performance scores.\n\nThat is why I think performance work should not rely only on Lighthouse.  \nActually using the site is just as important.\n\nEspecially on mobile.\n\nTap links.  \nMove between pages many times.  \nUse the back button.  \nOpen an article from the article list.  \nFinish reading one article and move to another.\n\nBy repeating these normal actions, you can find discomfort that numbers alone do not reveal.\n\nIt is a small and manual process, but I think it matters a lot.\n\n## How far should a personal blog go?\n\nThat said, I do not think a personal blog should always become a rich SPA-like application.\n\nA blog is mainly a place to read.\n\nIf the initial load becomes slower, JavaScript increases too much, or the site becomes fragile, that defeats the purpose.\n\nSo my current thinking is something like this:\n\n- Make the initial load as static and fast as possible.\n- Keep the basic architecture simple and MPA-like.\n- Still care about page transition feel.\n- Add lightweight animations when they improve UX.\n- Use prefetch carefully and only where it makes sense.\n- Bring in SPA-like behavior only where it is actually useful.\n\nThere is no need to make everything a SPA.\n\nBut just because a site is an MPA does not mean page transition UX should be ignored.\n\nEven on a static blog, CSS View Transitions and limited prefetching can make the experience feel somewhat closer to an SPA.\n\nWhat matters is not the technical category.  \nWhat matters is how the site feels when people actually use it.\n\n## Lighthouse is a starting point, not the goal\n\nLighthouse is useful.\n\nI still trust it as an entry point for performance work.  \nI will keep using it.\n\nBut I think it can be dangerous to treat the Lighthouse score itself as the final goal.\n\nA site can have a good score but still feel unpleasant to use.  \nYou might remove useful feedback just to protect the score.  \nYou might focus only on the first load and forget about navigation and browsing experience.\n\nThat can happen.\n\nSo now I see Lighthouse as a starting point, not the goal.\n\nFirst, use Lighthouse to find obvious problems.  \nThen, actually use the site.  \nLook at both numbers and experience.\n\nI think that balance is important.\n\n## Conclusion\n\nWhile building my personal tech blog, I spent a lot of time thinking about performance.\n\nAt first, I mostly cared about improving Lighthouse scores.  \nBut as I built and used the site, I started to feel that page transition UX and interaction feedback are just as important.\n\nWeb performance is not only about numbers.\n\nFCP, LCP, and other metrics are important.  \nBut how the site feels when users interact with it also matters.\n\nI want this blog to be not only fast, but also pleasant to read.\n\nI will keep improving it while balancing initial load performance and page transition experience."
}