100 on Desktop, 98 on Mobile: Semitexa’s PageSpeed Case

Four 100s on the page people actually visit

Open the September 30 desktop report for semitexa.com. Performance: 100. Accessibility: 100. Best Practices: 100. SEO: 100. The measured Largest Contentful Paint is 0.3 seconds.

This is the public homepage, with its product sections, navigation, typography, and paths into documentation and the blog. It is a useful example of a Semitexa application delivering a complete first screen efficiently. That first screen belongs to a larger goal: a complete workflow for the first customer.

Now switch to the mobile report. Under an emulated Moto G Power and Slow 4G, performance is 98, with the other three categories still at 100. Largest Contentful Paint is 1.4 seconds, and measured layout shift is zero. The slower-device result makes the case much more useful for a product team deciding how its first impression should behave.

The numbers, with their conditions attached

The saved report is dated September 30, 2026, at 12:14 PM GMT+3. It uses Lighthouse 13.5.0 and Headless Chromium 153.0.8010.36, testing an initial load of https://semitexa.com/. Desktop uses desktop emulation with custom throttling; mobile uses the device and network simulation stated above.

The individual measurements add substance to the headline. Mobile content appears early, the largest element follows shortly afterward, and the measured load has little main-thread blocking. Speed Index is slower on mobile, so the headline score should be read together with the timing details.

These are laboratory results. The report has no Chrome User Experience Report data available. A real-user Core Web Vitals assessment remains unestablished here. Google’s PageSpeed documentation explains the distinction between a controlled run and field measurements collected from actual visitors.

The browser receives the content in its first HTML response

In the application, SiteHomeHandler prepares the page data. SiteHomeResource selects the Twig homepage template. The template renders the hero and product sections on the server. This gives the browser meaningful content it can parse and display as soon as the response arrives.

We checked the live homepage separately with JavaScript disabled on September 30. It returned HTTP 200, the heading “Software. Beautifully connected.” was present, and all three product sections were in the document. The initial content therefore has no dependency on running the interface scripts first.

The page also loads JavaScript, including Semitexa Platform UI components. Server-rendered content lets those scripts enhance an already meaningful document. It reduces the work required before a visitor can read the proposition and choose a destination. The request-to-HTML walkthrough explains the application boundaries in more detail.

Give the headline’s font an early start

The hero headline uses Syne. Its Latin WOFF2 file is hosted on the same site, and the homepage explicitly preloads that file in the document head:

<link rel="preload"
      href="/assets/semitexa-site/fonts/syne-latin.woff2"
      as="font" type="font/woff2" crossorigin>

That declaration lets the browser discover the font before reaching its reference in the stylesheet. The local font CSS uses font-display: swap and Unicode subsets. Its weight-specific declarations share the same file URL, allowing the browser to reuse that resource across those weights. Hosting the font locally also removes an external font stylesheet from this page’s loading path.

These are concrete decisions in the Site module. The preload URL was also present in the live HTML we inspected. They address a resource the first screen actually needs; the saved report alone cannot tell us how many milliseconds each decision contributed. The SSR 2.0 guide explains how slower regions can arrive after useful initial HTML.

Schedule analytics around the first screen

The analytics partial prepares the data layer but delays fetching the external Google Analytics library. The load is triggered by the first pointer, keyboard, scroll, or touch interaction, or four seconds after the window load event. Where available, an idle callback schedules the insertion, with a timeout.

Our production HTML inspection confirmed that scheduling code and the absence of an initial external gtag.js script tag. This moves that third-party download away from the immediate rendering path. It is an application policy, implemented explicitly in the template.

It also has a product tradeoff: a short visit without interaction may end before analytics starts, and early conversion events need careful handling. A team adopting this timing should verify its measurement and event delivery. The reported Total Blocking Time describes the audited loading window; responsiveness after interaction still needs its own measurement.

Compression and caching have explicit rules

Semitexa’s SSR static asset handler negotiates gzip for eligible text resources and uses content-based ETags. It distinguishes versioned asset URLs from unversioned ones. A URL carrying a content version can receive a year of immutable caching; an unversioned URL must revalidate.

We verified the distinction against the live site. The versioned Platform UI core script returned gzip with Cache-Control: public, max-age=31536000, immutable. The unversioned Site script returned gzip with Cache-Control: public, max-age=0, must-revalidate. Both included an ETag and Vary: Accept-Encoding.

Compression reduces the transferred representation of these text assets. Versioned caching helps subsequent visits reuse unchanged files, while revalidation protects an unversioned URL from remaining stale after an update. The PageSpeed snapshot is an initial-load test, so repeat-visit caching is a useful delivery property rather than an explanation for that first-load score.

Here the responsibility is shared: the framework supplies the asset delivery behavior, and the application chooses its assets and loading policy. This case demonstrates those parts working together on a deployed page.

A strong result with a claim you can defend

A deployed Semitexa homepage achieved four 100s on desktop and 98 mobile performance in this public test. Its source and live HTML expose practical choices supporting efficient delivery: content in the response, early font discovery, scheduled third-party work, compression, and deliberate cache rules.

The report covers this URL, this version of the page, and these test conditions. It does not benchmark a booking transaction, database throughput, or every application built with Semitexa. We did not run a comparison against competing frameworks or an experiment that isolated each optimization. The later code and live-page inspection also cannot establish the exact deployment revision used by the saved test.

The perfect category scores have defined scopes. Accessibility covers the scored automated checks; manual checks are excluded from that score. SEO checks do not establish a search ranking, and Best Practices is not a complete security audit.

There is still work visible in the desktop diagnostics: an estimated 27 KiB of JavaScript minification savings, a non-composited animation, and a long main-thread task. Lighthouse’s performance score is calculated from weighted metrics, so a 100 can coexist with optimization opportunities. Zero Total Blocking Time also does not mean no JavaScript executed.

For a team building a product, the useful conclusion is concrete: Semitexa can support a fast public experience, and this application provides a measurable example. The engineering choices are visible enough to inspect, repeat, and improve.

Follow the evidence into your own product

Start with the saved desktop and mobile reports. Compare their environments and individual metrics. Then inspect the live page’s source, font requests, script timing, and asset response headers in your browser.

A fresh test may produce different values as the page, infrastructure, browser, and test conditions change. Run more than once when making engineering decisions. Add real-user measurement when traffic permits, and test the interactions that matter to your product.

Performance belongs alongside the ability to deliver useful business workflows. For that side of the story, read the Apartspace delivery case: a rental platform whose developer reports a 32-hour initial implementation. Together, the cases show what to ask of a foundation: how quickly a team can build the workflow, and how efficiently customers can reach it.