Extreme webperf
Is it possible to load an image concurrently with HTML on connections where this won't slow the HTML loading? Or include the images at the end of the HTML stream?
75 Replies
You can add a pre-load link in the headers to ask the browser to start downloading the image file sooner
This is almost negligible though in my case
I want to start downloading the image at the same time as the HTML, or slightly after
reducing a round trip to the server
with http2, you could do this with server push
but browsers dropped support for that
I don't think you can have a resource be loaded at the same time as the initial html payload, but you could hint to the browser that a resource is important and should be loaded as soon as possible with a link header that has a rel=preload, I can't find anything about if that secondary request can start before the html initial load one though. And considering you only have 2 (and half with the data url thumbnail) resources I don't know if you can speed up anything here
Reducing the load time of the html might help, but it's kinda hard if you have only 1.9KB of it, there's not much you can remove from it I suppose
you can't anymore: it's a huge waste of bandwidth
but sending resource hints should help a lot
It's very silly that the browser cannot simply send the screen dimensions to the server with the initial request payload. As this would allow a CDN to send the relevant images/assets concurrently with the initial HTML response
Some people are on Satellite connections that can take a few seconds for each round trip
well, no. because layout is a thing.
you would need to pre-render the page on the server with the same viewport to get accurate prediction of what is visible or not
A CDN, especially for SSG content, can easily compute the relevant images based on the CSS of the page
yes
you wouldn't have to render
only compute the layout
do you have any idea of how much compute that would be ?
yes
like sure it would speed up the very slow connection by a bit, but it would slow down all the other ones by a lot
unless you're connected to the CDN directly via fibre, with sub 5 millisecond latency, I don't see the compute being slower
Maybe you are correct, but it doesn't make sense to me
rendering for the web is not that fast
CDN servers basically never have GPUs so they would need to do rendering without hardware acceleration. so if there's something complex to render like... an image, it would take at least a few tens of millisecond
we don't need to render images to do layout calculations
even without that, the layout step of the rendering pipeline takes longer than most round-trips
See this is where I think it could be faster
and there the memory and compute cost to think about too
Maybe we need to strip an optimised image calculation version of layout/reflow
you can't do that a few thousand times a seconds
and cdn servers can send millions of files a second
I mean rather than running a whole web layout engine inside an edge server, one could run an optimised image calculation engine
for SSG sites or cached SSR you could even have a precompiled list of screen dimension ranges and associated assets to download
using static hints (like link header with
rel=preload) is supposed to enable the same thing without the cost on the server sidethis requires you to first receive the HTML though right
no, it's an http header
oh?
you can use a link tag too, but I'm talking about the header version
ah but that is in the first server response
tho TBF, puting it in the header section doesn't move it that much higher in the request in most cases
I wonder how much faster it is in headers vs HTML tag vs just let the browser see the image
yea
because browsers would quickly figure out which image is above the fold and important to load
they're smart af on their own
you need to load the blocking stylesheets before you do that tho
(blocking stylesheet = stylesheet loaded from within the
<head>)yea
any inline <style> element too IIRC, tho don't quote me on that
Astro output has critical styles inlined in the HTML response
both style= and <style>
I wonder if I would shave off that much time with preload header
that's nice for first load... but kinda worse for any subsequent load because of caching
preload header would be extra bytes down the line, so it would have to pay for itself
from the waterfall you shower, I would say that you can't improve much, because to my knowledge you can't start any request before the first one finishes
yea, I'm only concerned about first load.
Any subsequent load I'm aiming to have handled by a service worker and prerendering
less than a hundred bytes if you keep the image URL short
I think you're right when it comes to old HTTP protocols. But with newer ones you can start multiple connections while streaming the HTML
the difficulty here is I know that having many size variants of the dynamic image will be much better for loading time than loading it a few ms early with headers
you need a protocol switch message to do that tho... that's one more round trip
wdym, it's same protocol no?
default is HTTP 1.1
almost all modern browsers use QUIC I think
so you would need to upgrade the connection to HTTP 2 or HTTP 3 (pretty sure that's not the name of the protocol for 3 but can't rememebt the actual one)
support, but the initial request is always HTTP 1.1 cause the browser has no clue about what the server supports
support =/= use by default
are you suggesting that the server has to respond with the same protocol the client initiates with?
that sucks
I wonder if it can reply with QUIC to a HTTP 1.1 request
that would be weird if you sent an HTTP1.1 request and recieved a QUIC response XD
if in your request you say that you understand QUIC it would be a lovely surprise 😆
http1.1 to 2 might work cause the protocols are kinda similar, but QUICK doesn't even use TCP
I wonder if the HSTS preload list includes info on
always-accepts: QUIC or something lol
oh right TCP vs UDP
fucking hell I just want a faster internet lol
I guess the main issue is unoptimised sites and not squeezing the most out of this tech on sites like mine
2 round trips is the tightest you can gethttps://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Upgrade
wasn't sure but yeah http1.1 to http2 is at least 1 round trip more than staying on the same proto
it's an infrastructure issue too
but images are new requests right with a new protocol?
there's a reason Big Cloud tris to put datacenters everywhere
yea
POPs
yeah, but a protocol applies to all request using the same connection
so you would need to either open a new connection or send the upgrade message
Internet inequality 😆
that contrast is attrocious XD
hahaha
only on the map, not the dots
it's same without dark reader on
yeah but I could not see there was a map under the dots at first XD
actually light is slightly better
amazed that western Aus and south island NZ have no Cloudflare presence
Nor does greenland (but almost no population)
Svalbard, Antarctica & more island nation POPs would be 🔥
at least you're not a Papua New Guinea... there are in the middle of a "no data center zone" xD
oh yea true
yea that stands out too
northern canada
stop listing places with less than one human per 100km^2 and you might find that coverage is actually not that bad XD
I wonder about the economics of micro CDN POPs on islands and in remote areas that only store critical stuff and act to establish the connection with fewer round trips while retrieving the data from a bigger POP
CDN POP are just as expensive to setup as shields
like a CDN could speed up a site loads without even storing cached assets, by establishing the connection with the user before fetching the assets to get there from the origin server
shields?
no idea what the actual term is, that's the Fastly naming for the ground truth for a resource
server -> CDN Shield -> CDN POP -> client
I guess the arrows should go the other way arround... w/e
oh right
a POP is just having your edge there but a shield stores data
POP can store data too, but cache only
ah
So unlikely for a non-shield to store KV data/do worker compute etc.
that sucks
at least for Fastly, never dabbled into how cloudflare works, but I would assume they work kinda the same
that I can't tell you, I have no idea
but from what I understand of how Fastly works a server can be both a POP and a Shield at the same time, just not for the same resources
yea
so... maybe you could have edge stuff all over if you manage your data correctly? dunno, not really my field of expertise XD
I like to pretend servers are not a thing
it cant yet
it is as optimized as it gets: on http 1.1 with
keep-alive, http 2 and http 3; you can re-use the same connection for multiple resources
the way this works is very different for each version, but just saving a 2nd https handshake and negotiation is a huge speed improvement
http 3 can multiplex the same connection to receive multiple resources at the same time
in the end, it may will be 1 connection with multiple requests