Is this image inlining thing something new? Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
For that image I would prefer to use inline SVG...
31–40 of 292 posts
Is this image inlining thing something new? Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
For that image I would prefer to use inline SVG...
Is this image inlining thing something new? Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
Is this image inlining thing something new? Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
No, it's been around since forever. Just not used terribly often.
> Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
It depends. Making a new request to fetch the image always has overhead. Whether that overhead is bigger or smaller than the overhead of base64-encoding the image depends on:
• file size (naturally)
• file compressibility: The difference isn't as pronounced after gzipping everything, especially if the source data is somewhat compressible
• protocol: http2 allows a correctly configured server to push attached data with the original request, so no second request is needed. Even without server push, http2's multiplexing will reduce the overhead drastically compared to plain HTTP1.1 or the worst case, HTTPS1.1 to a different domain. The latter requires a full TLS handshake, and that's what, >30kb data exchanged if you have more than one CA certificate in the chain? That's a lot of image data.
Is this image inlining thing something new? Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
However, if the image is very large, it will make the initial request large as well. I would only use this for images that are small and above the fold.
The fastest and most reliable hosting is, by far, based on my own experience is amazon's e2 cloud and S3 bucket services.
Took me almost 30 seconds to load, maybe because the server is being hammered by HN traffic right now? Also like others here were saying, using a CDN would definitely help with the initial latency.
Is this image inlining thing something new? Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
Just to point out, there's no particular reason to host a page like this on a VPS at all. You could just throw it on S3. Even better, you could put it behind a CDN like Cloudfront and the total cost would be a dollar or two a month, not $25+ and it would be significantly faster.
Yeah I notice that was weird too. The creator speaks a lot about about html optimizations but one of the most widely-used methods of page speed increases are global CDN distribution. The SSD is really meaningless in this context. The website is so small that it will be loaded almost 100% from the filesystem cache. As long as it has more than 512 MB of ram... If I wanted my website to load incredibly fast, I would abs…
- Brotli instead of Gzip. Likely saves around 10% size.
- Minify everything, including HTML. Could save around 3% size on that page.
Just to point out, there's no particular reason to host a page like this on a VPS at all. You could just throw it on S3. Even better, you could put it behind a CDN like Cloudfront and the total cost would be a dollar or two a month, not $25+ and it would be significantly faster.
> You could just throw it on S3. Even better, you could put it behind a CDN like Cloudfront and the total cost would be a dollar or two a month, not $25+ and it would be significantly faster. I apologize for quibbling (really, I do! but I'm an infrastructure guy! This is my bag!). Yes, host it on S3, but ALWAYS put a CDN in front of S3 with long cache times (even just Cloudfront works). S3 can sporadically take hundr…
I personally went the other way. I still use CloudFront as a CDN but made it cache items for short periods of time. Invalidation was too much of a hassle, and it took too long. Admittedly, I should use hashes or something of the sort to keep my items versioned, but laziness always gets in the way.