Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customizer page takes ages to load in China #16886

Closed
ghost opened this issue Jul 25, 2015 · 10 comments
Closed

Customizer page takes ages to load in China #16886

ghost opened this issue Jul 25, 2015 · 10 comments
Assignees
Milestone

Comments

@ghost
Copy link

ghost commented Jul 25, 2015

External jquery lib at ajax.googleapis.com doesn't loads -_-
Customizer doesn't works.

@kkirsche
Copy link
Contributor

@mevsme Not as easy, but you could download the LESS source and just modify variables.less then build it yourself. Could also probably download the repo, replace ajax.googleapis.com with a local instance of jQuery, build the docs, and run the customizer from there (haven't tried that myself though to know if it would work)

@cvrebert
Copy link
Collaborator

Try using the unofficial Chinese translation of the docs: http://v3.bootcss.com/customize/
It uses its own CDN for jQuery.

@cvrebert cvrebert changed the title Boostrap customize page takes ages to load in China Customizer page takes ages to load in China Jul 25, 2015
@cvrebert
Copy link
Collaborator

@twbs/team Given that the customizer is going bye-bye in v4 anyway, and the availability of the bootcss.com version, how would folks feel about closing this as WontFix?

@XhmikosR
Copy link
Member

Actually, this is something I've been meaning to take a look at. Well, not the China issue per se, but adding a local jQuery fallback.

XhmikosR added a commit that referenced this issue Jul 25, 2015
Shouldn't really happen, but China for example has blocked Google so this should help.

Fixes #16886.
@XhmikosR XhmikosR added this to the v3.3.6 milestone Jul 26, 2015
@coliff
Copy link
Contributor

coliff commented Jan 13, 2016

HTML5Boilerplate recently switched from Google's CDN to jquery.com's CDN (Ref: h5bp/html5-boilerplate#1737 (comment)) so that users in China don't have any problems. Could we consider changing the CDN to jQuery?

@XhmikosR
Copy link
Member

To be honest, why would we care for censorship? I see the point of this, but we already have a fallback anyway.

@coliff
Copy link
Contributor

coliff commented Jan 14, 2016

As explained at H5BP (https://github.com/h5bp/html5-boilerplate/blob/master/dist/doc/html.md)

"The jQuery CDN version of the jQuery JavaScript library is referenced towards the bottom of the page. A local fallback of jQuery is included for rare instances when the CDN version might not be available, and to facilitate offline development.

The jQuery CDN version was chosen over other potential candidates (like Google's Hosted Libraries) because it's fast (comparable or faster than Google by some measures) and, (unlike Google's CDN) is available to China's hundreds of millions of internet users.

For many years we chose the Google Hosted version over the jQuery CDN because it was available over HTTPS (the jQuery CDN was not,) and it offered a better chance of hitting the cache lottery owing to the popularity of the Google CDN. The first issue is no longer valid and the second is far outweighed by being able to serve jQuery to Chinese users."

@XhmikosR
Copy link
Member

Still, that doesn't answer why we should circumvent censorship of any way.

I don't want to get political, I simply don't believe we should do do anything about it because it's just compromising.

@coliff
Copy link
Contributor

coliff commented Jan 14, 2016

It's not compromising though - the jQuery CDN is comparable or faster than Google's by some measures. Choosing a different CDN doesn't 'circumvent censorship' at all. - its really got nothing to do with politics.

There are about 500 million Internet users in China. Surely its better to use a CDN with 100% global coverage rather than one with less?

@XhmikosR
Copy link
Member

I personally don't agree with this. Because, to me, changing the CDN isn't worth it in this case.

Either way, feel free to open a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants