Skip to content

Commit 68a53c0

Browse files
authored
Merge pull request #38 from Quafadas/lolgab-patch-1
Fix typos in blog post
2 parents a7b9d59 + 5950386 commit 68a53c0

File tree

1 file changed

+10
-10
lines changed

1 file changed

+10
-10
lines changed

site/docs/_blog/_posts/2024-07-17-On Cdns.md

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -4,26 +4,26 @@ title: On CDNs
44

55
One of the objects which seems to crop up rather often when discussing this idea, is that
66

7-
> My users are now dependant on a CDN!
7+
> My users are now dependent on a CDN!
88
9-
This is true, although my invesigtaion makes this appear way less scary then it first looks. In fact on balance I've developed a strong preference for them...
9+
This is true, although my investigation makes this appear way less scary then it first looks. In fact on balance I've developed a strong preference for them...
1010

11-
The reliability concern is dealt with in two ways. Firstly according to jsdelivr [status](https://status.jsdelivr.com), it's uptime was 100% in 2023. So, that's not too bad.
11+
The reliability concern is dealt with in two ways. Firstly according to jsdelivr [status](https://status.jsdelivr.com), its uptime was 100% in 2023. So, that's not too bad.
1212

13-
And if you specifiy the explicit dependance of the module you are using... actually, it gets waaaay better ... because when the CDN responds to an explicitly versioned request, it includes a bunch of headers which say "This artifact is immutable. Don't bother me about this again. Ever".
13+
And if you specify the explicit dependence of the module you are using... actually, it gets waaaay better ... because when the CDN responds to an explicitly versioned request, it includes a bunch of headers which say "This artifact is immutable. Don't bother me about this again. Ever".
1414

15-
And the browser wqill respect that - next time you go ask for your dependancy, it simply loads it out of it's cache. There _is no network request_. Dependancy load time : 0ms, according to the browser network tools.
15+
And the browser will respect that - next time you go ask for your dependency, it simply loads it out of its cache. There _is no network request_. Dependency load time: 0ms, according to the browser network tools.
1616

17-
It's tought to get faster than 0. Also, no request means no netork risk.
17+
It's tought to get faster than 0. Also, no request means no network risk.
1818

1919
So, under "ideal" conditions:
2020

2121
- You are using a modern browser
2222
- You are making the request for a second+ time
23-
- You have explicitly specified the version of the dependancies you're using
23+
- You have explicitly specified the version of the dependencies you're using
2424

25-
Dependancy resolution is both very reliable and very fast. What's cool - that cache survives redeployment. So your app is slow for the user the first time... but the cache survives a redeployment. It's fast afterwards. We can reword the statment as follows;
25+
Dependency resolution is both very reliable and very fast. What's cool - that cache survives redeployment. So your app is slow for the user the first time... but the cache survives a redeployment. It's fast afterwards. We can reword the statement as follows;
2626

27-
> My users are now dependant on a CDN being available the first time they visit my site.
27+
> My users are now dependent on a CDN being available the first time they visit my site.
2828
29-
Which is less scary given the historical uptime!
29+
Which is less scary given the historical uptime!

0 commit comments

Comments
 (0)