[HN Gopher] Self-host your static assets (2019)
___________________________________________________________________
Self-host your static assets (2019)
Author : kosasbest
Score : 70 points
Date : 2022-03-05 17:22 UTC (5 hours ago)
(HTM) web link (csswizardry.com)
(TXT) w3m dump (csswizardry.com)
| juanse wrote:
| One fear that I have with this modern way in which we use so many
| references in different sources is that any minor fail, can mean
| a real pain.
| markdog12 wrote:
| Imagine if every web page loaded this fast?
| axelthegerman wrote:
| I'm surprised noone is mentioning that a CDN totally does help to
| serve your assets across different geographies.
|
| Even if HTTP/2 is faster to load multiple assets over the same
| connection, I found it still better for users on other continents
| to serve my web app over the main domain from my server in US-
| East or Central and have a global CDN catching ALL my assets (not
| 5 CDNs for 5 different JS frameworks)
| z3c0 wrote:
| I've been a web developer for just over a decade now. Lately,
| I've been rather amused at how much more elementary my websites
| are today compared to, say, 5 years ago. I went through all the
| MVW frameworks, the gulp builds, the MEAN stack, 100% JavaScript
| SPAs, Typescript, etc, until eventually finding myself back where
| I started: static HTML page, a lite CSS framework, and almost no
| JavaScript.
|
| My development is faster than ever, my web pages are faster than
| ever, and I can spend more time making sure the website delivers
| information effectively than worrying about gluing a million
| disparate frameworks together.
| vmception wrote:
| Same, its almost a wholesale rejection and works just fine for
| either getting the point across or driving millions in revenue
|
| In the web3 space, all the "call to actions" are direct
| payments, so the funnel is reduced to a single step - optimized
| by orders of magnitude over the long winded funnels of web 2.0
| services for even higher margins and even faster sales cycles
|
| most of the learnings from all these other frameworks was to
| optimize for the most user experiences to keep them engaged for
| a convoluted product where the user session needs to be
| transferred between views and made longer and longer
|
| In a world where most sites and services never needed to do
| that, and the current web3 ones that monetize well definitely
| don't need to, none of this complicated frontend (or associated
| backend) matters any more
|
| The only remaining relevant learnings from the past 10 years
| are responsive design for different screen sizes, CDNs for even
| more caching, and better auto deployments from version control
| updates
| [deleted]
| eternityforest wrote:
| Modern JS can easily use MB of JS libs. Sometimes it would be
| rather hard to do without them. We also have stuff like icofont.
|
| If I have 100kb of content that needs 500kb of JS... I lose a lot
| of bandwidth if I were to self host.
| lelandfe wrote:
| > if lots and lots of sites link to the same CDN-hosted version
| of, say, jQuery, then surely users are likely to already have
| that exact file on their machine already
|
| > [However] Safari has completely disabled this feature for fear
| of abuse where privacy is concerned
|
| All major browsers have now disabled shared caches[0][1]. Using a
| CDN for resources is strictly worse, now, performance-wise.
|
| [0] https://developers.google.com/web/updates/2020/10/http-
| cache...
|
| [1] https://arstechnica.com/gadgets/2020/12/firefox-v85-will-
| imp...
| eternityforest wrote:
| I really hate that you can't disable the cache partition. Every
| megabyte counts in a mobile first world.
| mro_name wrote:
| so why not cut it from image cruft, videos or bloated code
| and frameworks?
|
| What kind of pages are we talking? Print-ready image
| archives?
| lelandfe wrote:
| It's for the best. Cache partitioning solves a browser
| history leak described in _Timing Attacks on Web Privacy_ [0]
|
| The permutations of different CDNs and asset versions meant
| the cache hit rate was low anyway.[1][2]
|
| [0] https://www.cs.umd.edu/~jkatz/TEACHING/comp_sec_F04/downl
| oad... (PDF)
|
| [1] https://zoompf.com/blog/2010/01/should-you-use-
| javascript-li...
|
| [2] https://web.archive.org/web/20111123170325/http://statich
| tml...
| tick_tock_tick wrote:
| > Using a CDN for resources is strictly worse, now,
| performance-wise.
|
| It's still normally significantly better if only for the fact
| the CDN's servers are physically closer to the client.
| [deleted]
| lelandfe wrote:
| "Normally," i.e. when the origin itself is not behind a CDN,
| right?
| samwillis wrote:
| Not only hosting static assets yourself, it's best to have them
| on your main (sub)domain. It saves a dns round trip when visiting
| site for the first time. It also has the advantage with HTTP/2
| being able to use that same initial connection for all assets on
| the page.
|
| The old way of having your server rendered pages on your main
| domain and static assets on static.domain.com really should end.
| Less of an issue if your doing jamstack with no server side
| rendering or using something like Vercel.
|
| This is also one of the advantages of using a combined waf/cdn
| such as CloudFlare. It allows you to have everything on the same
| domain while also having the use of waf and cdn capabilities.
| There is no need to have a subdomain to hold your static assets
| if you want to place it behind a cdn service. The only
| potentially problem is if your main hosting provider or tech
| stack makes having everything on one domain difficult.
|
| I mostly work with Python on the sever and have found
| "whitenoise" a great way to achieve this.
|
| Obviously it's still easer to host any "dynamic" assets or user
| submitted assets on a subdomain. (There are good arguments that
| user submitted assets should be on another domain completely for
| belts and braces security)
| zelon88 wrote:
| I will never src a script to a third party server. Same with
| fonts.
|
| I think it's ironic that we thrash chipmakers for side channel
| attacks that realistically couldn't ever be exploited but the
| same people turn around and call 14 different scripts from 14
| different domains to display a 900kb web page.
|
| Who really knows who has access to or is tracking access to that
| code? And what happens when one of them goes down?
|
| "The CDN is WAY more reliable than my server."
|
| But your server is the least common denominator. Who cares if
| your scripts load if your server doesn't? For low volume, unless
| you have redundancy at every level of the stack; you can't get
| more reliable than one box.
| IgorPartola wrote:
| How do you handle things like taking payments?
| Nextgrid wrote:
| You can make an exception for payments (where you rely on the
| payment processor anyway, so the reliability argument goes
| away - if the processor is down, the payment will fail even
| if you self-host the payment script). Of course, embed the
| payment script only on the actual payment page, even if your
| processor tells you otherwise and quotes some fraud-related
| bullshit.
| samwillis wrote:
| > even if your processor tells you otherwise and quotes
| some fraud-related bullshit.
|
| You may be right 99.9% of the time. But if your site starts
| being used by someone automatically testing stolen credit
| card to see if they work you will be thankful for the
| automated script detection this gives. Every chargeback
| cost the vendor $20, now imagine 1k of those in a sort
| period of time, not pretty.
|
| So far I have fortunately not been a victim of this but
| have read about people who have and it gives me enough fear
| to stick that script on all pages.
| Nextgrid wrote:
| Can't you just enforce 3D-Secure and be done with it?
| samwillis wrote:
| I may well be out of date (last looked at it about 18
| months ago) but I don't think all card issuers have
| implemented 3D secure yet. Although I think there may
| have been a deadline for them to.
|
| Also friction in the checkout process is bad and can
| contribute to dropouts. You can decide to always enforce
| 3d secure or to have it only run when banks
| require/suggest it. Personally I set a cart total
| threshold above which it's required and set it only to be
| applied when banks require it for lower value orders.
| samwillis wrote:
| Slight aside, most payment services with a Stipe like js self
| hosted checkout now suggest you include their JavaScript on
| all pages off your site, not just the checkout. This is so
| that they can begin to build a profile of how the
| user/browser moves around the site in order to use ML to
| prevent fraud. They also require that you _dont_ self host
| the js.
|
| The main use of this is to detect automated scripts running
| cards on your site to test if they work.
|
| Obviously it's an endless battle as the fraudsters move to
| using tools such as puppeteer/playwright to simulate a human
| using a browser.
| zelon88 wrote:
| I haven't had to do that in a while but in the past I would
| just create external links to the payment processor who then
| links back when the payment is approved/declined.
|
| Obviously you can't reasonably "roll your own" payment
| provider, but that doesn't mean I need to run their code with
| my name at the top of the page.
| toast0 wrote:
| It used to be pretty common to self-host a checkout page,
| and the server contacts the payment processor. That comes
| with a security checklist compliance burden these days
| though. Probably better to send the browser to the
| processor and wait for them to come back, as you said.
| the_arun wrote:
| Article does a great job of describing self-host. But they don't
| provide tips on how to self host in an easy way.
|
| 1. Is it hosting on our own CDN endpoints. How easy to set this
| up? Is there a 0 cost way of doing it for our experiments?
|
| 2. Alternatively hosting them on our own github pages or repos? -
| here we still depend on GitHub CDN.
| ipaddr wrote:
| Self host would not be putting them on github pages unless you
| own github.
| travisjungroth wrote:
| He's not talking about self host as in CDN vs self host. It's
| about not linking to third party assets. You link to
| yoursite.com/static/bootstrap.js, not
| someoneelse.com/shared/bootstrap.js.
|
| You can (should, as he says at the end) have this be through a
| CDN. Just use the same CDN you use for other stuff.
| immibis wrote:
| The article is not really talking about "self host" but rather
| "host in the same place as the rest of your website"
| [deleted]
| Swizec wrote:
| > Users may have the file pre-cached
|
| This is no longer true. Due to security concerns browsers no
| longer re-use the cache between websites.
|
| That said, hosting assets yourself is fantastic _if you use a
| CDN_. Accessing American websites without CDN from Europe can be
| quite rough. I remember one of my first remote freelancing gigs
| where it took about 5s to load the company's website hosted on
| Heroku. Just because of availability zones.
|
| At my current gig, we self-host our assets and it's fine because
| we're US-centric. We host in us-west-2 and I live in SF and
| everything loads super fast. But you can really tell the dev site
| loads slower when working from the east coast.
|
| Network latency is no joke.
| Lascaille wrote:
| angrais wrote:
| Self hosting means downloading the source of a script (e.g.,
| jQuery), and hosting on the servers your site/app serve from.
| So I assume that GPs site is hosted on AWS and this may make
| more sense?
|
| Else yes, a bit confusing.
| Swizec wrote:
| What? The whole infra runs on us-west-2 and there are no 3rd
| party resources loaded from elsewhere.
|
| You expect us to run servers in our bedrooms to count as self
| hosting?
| Lascaille wrote:
| eyelidlessness wrote:
| The article and the comment are talking about hosting the
| site and its resources in the same place/on the same
| domain, not about the kind of hosting used. This advice
| still holds even if your entire site is behind a CDN.
| dpweb wrote:
| Caching. That you control in code - not controlled by server
| headers which never worked reliably back to the earliest days.
| Already addressed in browsers in window.caches, serviceworker.
|
| It's not so much you need JQuery version x cached from another
| origin, but once its loaded from your site, it never needs to be
| sent again. Heck you cache everything, or everything except
| index.html if you want to.
| paxys wrote:
| Unfortunately there's a significant cost to actually implementing
| and maintaining this. For a non-mission critical/hobbyist site,
| putting a couple links to bootstrap, jquery, d3, vue, google
| fonts etc. in your header is a lot easier (and cheaper) than
| setting up your own bundler, build process and CDN. I don't
| particularly care if my pages take an extra few milliseconds to
| load.
| antihero wrote:
| I wouldn't exactly say using a bundler is a significant cost,
| nor that serving a few hundred kB is that much cheaper than
| relying on a shared CDN. If anything that's just more lazy than
| anything else. Modern bundlers like vite aren't exactly
| difficult to set up.
| minus7 wrote:
| Literally no significant extra effort to download the files and
| put them with your website. If you fetch them from a CDN with a
| fixed version you're not getting updates anyway.
| paxys wrote:
| Putting them on your website means they are being served from
| your web server every time, which has a much worse
| performance penalty (and bandwidth cost) than everything the
| article mentions. The alternative is pushing it to your own
| CDN, which is the complexity I was referring to.
| immibis wrote:
| What is the cost to putting your frameworks on your site?
___________________________________________________________________
(page generated 2022-03-05 23:00 UTC)