Landing page redirects

Silktide checks whether reaching your page involves redirects - addresses that answer "go here instead" rather than serving the page. Each redirect is an extra round trip to a server before the real page can even begin to load.

A chain like this makes the browser cross the network three times before receiving any content:

http:\/\/example.com\/           -> redirect
https:\/\/example.com\/          -> redirect
https:\/\/www.example.com\/      -> redirect
https:\/\/www.example.com\/home  -> the actual page

Why this matters

Redirects delay the page before a single byte of content arrives, and on mobile connections each hop can cost hundreds of milliseconds. The pattern is worst exactly where speed matters most: landing pages reached from ads, search results, and shared links, where a slow start means visitors give up before seeing anything.

Chains build up by accident - an upgrade here, a "www" normalisation there, a page move last year - and nobody sees the combined cost because internal navigation skips it. New visitors arriving from outside pay for every hop.

How to fix it

Update links, ads, and campaign URLs to point directly at the final address, skipping every intermediate hop.
Collapse chains on your server: each old address should redirect straight to the final destination in one step, not through the chain one hop at a time.
Use on one URL rather than redirecting phones to a separate mobile site such as m.example.com - separate mobile URLs cost a redirect on every entry, and hurt search rankings too.
Avoid redirects that exist only to set cookies or tracking parameters; set them on the destination page instead.

How Silktide tests this

Load the page in a real browser, using the device type, connection speed, and test location configured for your speed tests.
Follow the chain of redirects the browser passes through to reach the final page, and measure the time each one adds.
Report each address in the chain with its time cost, and grade the page by the total: any measurable redirect delay lowers the grade, and around one second of accumulated delay is graded as poor.

Troubleshooting

The HTTP-to-HTTPS redirect is required

Yes - keep it, since visitors who type the bare address must be upgraded to HTTPS. The goal is one hop at most: that redirect should land directly on the final URL, and everything you control (links, ads, sitemaps) should point at the final HTTPS address so most visitors never redirect at all.

The redirect comes from a marketing or shortener URL

Tracking URLs and link shorteners add hops by design. That can be a fair trade, but it is still real delay for every visitor - keep such chains as short as possible and point them at the final page directly.