What Do the Four Faymas Sites Tell Your Browser Before the Page Loads?

Four domains, four different answers, and only one of them lets a cache hold the page. Across 106 successful HTTP responses measured on 2026-10-20 (107 requests, one failed), faymas.in sent 4 of the 9 common security headers on all 61 of its responses and returned a real 404 for a URL we invented; faymas.net sent none of the 9 on any of its 25 responses and answered HTTP 200 for that same invented URL; the two WordPress domains answered Cloudflare's DYNAMIC on 18 of their 20 responses. Not one of the four sent Strict-Transport-Security even once. Exactly one response in 106 carried an ETag.

Updated October 20, 2026 · Prompt-text analysis

This guide analyses published prompt text. No generation tests were run.

What we measured, and what we could not

Every site says something before it says anything. The status line, the cache directives and the security headers arrive ahead of the first byte of content, and every crawler reads them. This page is a measurement of that layer only: nothing here comes from the page body, the sitemap or a third-party report.

We sent 107 requests on 2026-10-20 to four domains — faymas.in, faymas.net, faymas-in.com and faymas.com.in. 106 came back. The page lists came from each site's own index or its own WordPress REST endpoint: 55 from faymas.in, 19 from faymas.net, 4 from faymas-in.com and 5 from faymas.com.in. Six fixed probes ran against every domain: the root with and without a trailing slash, an http:// request, the www host, /robots.txt, /sitemap.xml, and one URL we made up (/this-page-does-not-exist-1020).

Four limits matter. All requests came from a single vantage point and all four domains answered from a Cloudflare edge in the same region, so the timings are one observer's timings, not a global average. Each URL got one request, except the four home pages, which got five in a row. This machine's curl build has no --http2, so HTTP/2 was not tested; everything negotiated HTTP/1.1. And we read server-rendered responses only — nothing here speaks to what a browser does after JavaScript runs.

One domain caches its HTML. The other three rebuild it every time.

This is the sharpest split in the data. faymas.in is the only one of the four where Cloudflare reports holding a copy: 35 of its 61 responses came back as HIT, EXPIRED or MISS, and 26 came back DYNAMIC. Two of those responses carried an age header — 1,090 and 1,098 seconds, roughly eighteen minutes — which is what a cache looks like when it is genuinely serving a stored object.

The other three do not cache HTML at all. faymas.net sent no cf-cache-status header on any of its 25 responses, which is what you get when the response is excluded from caching entirely. Its cache-control says so in plain words: private, no-cache, no-store, max-age=0, must-revalidate on 23 of 25. The two WordPress domains both came back DYNAMIC on 18 of their 20 responses combined, and 18 of those 20 did not send a cache-control header at all.

The five consecutive requests to each home page show what that costs. faymas.in returned HIT five times out of five, with time-to-first-byte of 0.064, 0.069, 0.068, 0.074 and 0.077 seconds — a spread of 13 milliseconds. faymas.net, asked the same question five times, answered in 1.392, 0.668, 0.499, 0.212 and 0.179 seconds. Same URL. Same minute. A 7.8× swing between the slowest and the fastest, because nothing was stored and every response was rebuilt. faymas.com.in was the slowest of the four and the steadiest about it: 1.645, 1.668, 1.263, 1.705 and 1.627 seconds, all DYNAMIC.

One detail deserves its own sentence, because it looks like a contradiction and isn't. faymas.in's HTML carries private, max-age=300, must-revalidate on 34 of 61 responses — a directive that asks shared caches not to store the object — while Cloudflare's own status field on those same responses says HIT. Both values are what the wire actually said. We report them side by side rather than explaining them.

The other thing worth noting is which pages faymas.in marks for shared caching. The four that describe the site — /about-us, /blog, /contact and /copyright — carry s-maxage=31536000 or s-maxage=86400, stale-while-revalidate=31449600. The 51 prompt, blog-post and collection pages carry private. The pages about the business get a year of CDN lifetime. The other 51 — prompt pages, blog posts, keyword collections and the home page — carry private. The pages the site is actually built out of get five minutes and no shared cache.

Security headers: 61 responses with four, 36 with none

We checked for nine of the usual ones: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection, Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy.

Every one of those 61 faymas.in responses carries the same four: nosniff, SAMEORIGIN, same-origin and 1; mode=block. That set is not hand-written. It is the default set a Next.js application emits unless somebody turns it off, and it is the cheapest possible signal that a framework is in front of the site and nobody has touched its defaults since.

faymas-in.com's single header is Content-Security-Policy: upgrade-insecure-requests. That is also a default — WordPress sends it — and it does one narrow thing: it asks the browser to fetch subresources over HTTPS. It is not a policy that restricts anything.

Nothing here is a vulnerability claim. We did not test for one. But four sites, two of them e-commerce-shaped and one of them serving a login-free prompt catalogue, and not one HSTS header between them — that is a consistent picture, and it is measurable in about ten minutes.

Two of the four answer 200 for a page that does not exist

We requested /this-page-does-not-exist-1020 on each domain. Two got it right. faymas.in returned 404 — and served 391,614 bytes of HTML to say so, about 71% the size of one of its real prompt pages. faymas.com.in returned 404 with 185,378 bytes.

The other two said 200. faymas.net returned 99,782 bytes of HTML with a success status. faymas-in.com redirected to its own homepage and returned 200 — the response was byte-for-byte its front page, 67,266 bytes. Both are soft 404s, and a crawler that trusts status codes will keep them.

This matters more than it sounds, because of what we already found on the inventory side. faymas.in alone declared 19,550 URLs in the sitemap we pulled on 2026-10-19. A soft 404 policy is the difference between an index that shrinks when pages go away and one that only grows.

What the headers say about the plumbing

Three fields name the stack, and they do not agree with each other.

faymas.in sends via: 1.1 Caddy on all 61 responses and x-powered-by: Next.js on 59. Caddy is a reverse proxy sitting between Cloudflare and the application. It is the only one of the four that has one. That is the same domain that is the only one being served from cache — and while a proxy does not cause caching, the two facts land on the same domain and nowhere else.

faymas.net also runs Next.js (23 of 25 responses) but sends no via. It is the only domain among the four that sends no cf-cache-status, no etag and no last-modified — 0 of 25 on validators. It tells you never to store the page and then gives you nothing to revalidate with.

The WordPress pair splits too. faymas-in.com announces PHP/8.5.11 on all 9 responses and sends last-modified on all 9 — all dated 2026-10-17. faymas.com.in announces nothing at all: no x-powered-by on any of its 11 responses. It is also the domain that sent expires: Wed, 11 Jan 1984 05:00:00 GMT on two responses, including on its /sitemap.xml, which returns 404. A 1984 expiry date is the conventional way to say "this was already stale when you asked".

Across all 107 requests, not one response carried a Set-Cookie. Four sites, 106 responses, zero cookies. Nothing here logs you in, remembers a preference or sets a consent flag server-side.

Bytes: 550 KB per page, compressed to 60%

Uncompressed, with Accept-Encoding: identity, the median faymas.in content page was 549,991 bytes. faymas.net was 216,817. faymas.com.in, 197,264. faymas-in.com, 94,822.

Then we asked for Brotli and measured what actually crossed the wire. All eight pages we tested — two per domain — were served with content-encoding: br. The ratios were not close:

The biggest pages compress the best, which is the tell. A page that shrinks to 60% is a page made of repeated structure. The two WordPress pages, at 0.992 and 0.995, barely compress — they are mostly text that only occurs once. Compression ratio is a rough proxy for how much of a page is scaffolding, and by that measure faymas.in is carrying roughly forty per cent of its own weight in repetition that Brotli can remove.

That said: even after compression, a median faymas.in page is still around 330 KB on the wire against roughly 191 KB for faymas.net. Compression narrows the gap. It does not close it.

What this layer cannot tell you

Headers say how a page is delivered. They say nothing about whether the prompt on it works, whether anyone copied it, or whether the site is worth visiting — we have measured those separately, on different layers, and they do not follow from anything on this page.

Two specific gaps. HTTP/2 was not tested, because this machine's curl cannot request it; every response negotiated HTTP/1.1, and all four domains advertise HTTP/3 through alt-svc (106 of 106 successful responses). And the one failed request — https://www.faymas-in.com/ — came back as "Could not resolve host". DNS in this environment is not trustworthy, so we are writing down that the request failed, not that the subdomain does not exist.

What survives is a shape. Three of the four domains behave, at the transport layer, like the same object: rebuilt on every request, carrying no or almost no security headers, and in two cases unable to distinguish a missing page from a real one. faymas.in behaves like something else — an origin proxy, a CDN that holds its HTML, four framework-default security headers, a real 404, and 550 KB of page to pay for all of it. The transport layer is the cheapest place to see how much engineering went into a site. On this measure, one of the four has had some, and the difference shows up in the first 13 milliseconds.

FAQ

Do the faymas sites support HTTP/2 or HTTP/3?

All 106 successful responses came back over HTTP/1.1, and all 106 advertised HTTP/3 through the alt-svc header; HTTP/2 was not tested because this machine's curl build has no --http2 option.

Which faymas site is the fastest?

faymas.in, whose home page returned time-to-first-byte of 0.064 to 0.077 seconds across five consecutive requests, all served from Cloudflare cache; faymas.com.in was slowest at 1.263 to 1.705 seconds.

Do the faymas sites set cookies?

No — none of the 106 responses carried a Set-Cookie header, so none of the four sets a login, preference or consent cookie server-side.

Why does faymas.net return 200 for a page that does not exist?

It serves a 99,782-byte HTML page with a 200 status instead of a 404, which is a soft 404; faymas-in.com does the same thing by redirecting to its homepage and returning 200.

Does any faymas site let a CDN cache its HTML?

Only faymas.in — 35 of its 61 responses came back as HIT, EXPIRED or MISS with two carrying an age of about 18 minutes, while faymas.net sent no cf-cache-status at all and both WordPress domains returned DYNAMIC.

How big is a faymas page?

The median uncompressed HTML page was 549,991 bytes on faymas.in, 216,817 on faymas.net, 197,264 on faymas.com.in and 94,822 on faymas-in.com, with Brotli shrinking the largest pages to about 60 per cent of their size.