Comment est ce site si vite?

Question

comment le site Web http://dftba.com/ est-il si rapide?

quand je clique sur un lien, il charge tout de suite? qu'est-ce qui fait que ça marche comme ça? Comment puis-je le faire fonctionner comme ça sur mon site?

certains objets du site sont hébergés par un site Web appelé ecogeek-cdn.net? qui est cette société et pourquoi hébergent-ils les images de ce site?

je cherche dans ce site depuis quelque temps parce que je veux que ce site soit comme le mien

ils utilisent le site Apache
Ils utilisent le site Python (lorsque le développeur me l'a demandé)
ils utilisent le site jquery et jqueryui
leur site est construit sur mesure, sans wordpress
leur site est ~~possédé~~hébergé par liquidweb
leur site reçoit un million d'utilisateurs par mois
leur site a été lancé en janvier
leur site utilise cpanel
~~leur site n'a pas SSH ou FTP (j'ai essayé de me connecter mais il m'a refusé tout)~~ ils ont SSH et FTP mais seulement autorisés par leurs adresses

S'il vous plaît;
mon anglais n'est pas aussi bon que le vôtre

Smudge · Accepted Answer

#BestQuestionEver =)

Je suis le développeur du site et je devrais pouvoir répondre à la plupart de ces questions.

Vous avez soulevé des points intéressants.

En termes de backend (le backend est rarement la source de goulots d'étranglement lors du chargement de page, il est généralement chargé mais le jeu n'en vaut pas la peine), le site fonctionne sur 2 serveurs dédiés de LiquidWeb 128 Go de RAM) en utilisant Python et PHP (PHP pour les commandes cart/Paypal, Python pour l'interface principale). Nous utilisons également MongoDB, Redis et Memcached pour accélérer encore plus le traitement.

Le frontend est là où ça devient intéressant. Comme John le dit, nous minifions tous nos CSS et Javascript. De plus, toutes les ressources externes sont desservies par le site 'ecogeek-cdn'. Ecogeek est la société propriétaire des serveurs sur lesquels le site est exploité. Ecogeek-cdn.net pointe notre réseau de distribution de contenu auto-hébergé qui, selon votre pays, sera servi directement par nos serveurs ou par EdgeCast (nous utilisons des Des trucs de DNS que je ne comprends pas tout à fait pour trouver la meilleure option/la plus rapide). La raison pour laquelle nous utilisons le domaine ecogeek-cdn.net au lieu de cdn.dftba.com ou quelque chose de similaire est résumée assez bien par le site sstatic (Le CDN utilisé par StackExchange - I.E. de ce site)

Lorsque le navigateur demande une image statique et envoie des cookies avec la demande, le serveur n'a aucune utilisation de ces cookies. Ils créent donc uniquement du trafic réseau sans raison valable. Vous devez vous assurer que les composants statiques sont demandés avec des demandes sans cookie. Créez un sous-domaine et hébergez-y tous vos composants statiques.

Si votre domaine est www.example.org, vous pouvez héberger vos composants statiques sur static.example.org. Toutefois, si vous avez déjà défini des cookies sur le domaine de premier niveau example.org, par opposition à www.example.org, toutes les demandes adressées à static.example.org incluront ces cookies. Dans ce cas, vous pouvez acheter un tout nouveau domaine, héberger vos composants statiques et garder ce domaine sans cookies. Yahoo! utilise yimg.com, YouTube utilise ytimg.com, Amazon utilise images-Amazon.com et ainsi de suite.

Un autre avantage de l'hébergement de composants statiques sur un domaine sans cookies est que certains mandataires peuvent refuser de mettre en cache les composants qui sont demandés avec des cookies. Sur une note connexe, si vous vous demandez si vous devriez utiliser example.org ou www.example.org pour votre page d'accueil, prenez en compte l'impact des cookies. Omettre www ne vous laisse pas d'autre choix que d'écrire des cookies sur * .example.org. Pour des raisons de performances, il est donc préférable d'utiliser le sous-domaine www et d'écrire les cookies dans ce sous-domaine.

Tout le contenu statique est diffusé via NGINX avec des durées d'expiration persistante et très élevée. Il est donc mis en cache par le navigateur de l'utilisateur le plus longtemps possible. Cela accélère le chargement de la page, car aucune charge n'est nécessaire. Nous avons également commencé à jouer avec des éléments tels que le préchargement d’images et de pages afin d’accélérer les choses.

Mais je pense que la principale chose qui contribue à nos chargements de page rapides utilise AJAX, cela signifie que chaque fois que votre navigateur demande une page, il ne charge que les ressources requises pour cette page, tout le reste reste à sa place. Nous pouvons également utiliser des animations, par exemple, pour rendre la page plus rapide, même si ce n’est pas le cas (c’est un problème psychologique; si le chargement d’une image prend 1 seconde, mais que les dernières 0,25 secondes sont atténuées, les utilisateurs sentir comme si il a chargé en 0,75 secondes parce que les choses se passent).

Il existe de nombreuses astuces pour obtenir un site Web rapide (astuce: le temps passé à essayer d'accélérer votre backend est probablement une perte de temps. L'utilisation de CDN, la réduction de fichiers, l'utilisation de sprites CSS, etc. permettent de gagner une demi-seconde du temps de chargement d'une page, pour obtenir ce genre d’amélioration), consultez les suggestions sur Google PageSpeed et Yahoo YSlow, puis sur Google pour trouver le meilleur moyen de le mettre en œuvre pour votre site.

John Conde · Answer

Choses que j'ai remarquées:

Leur contenu statique est fourni par des sites tiers, ce qui permet de télécharger plus de fichiers en parallèle.
Il semble qu'ils utilisent un réseau de distribution de contenu (Content Delivery Networks) qui permet de télécharger des fichiers à partir d'un serveur proche de l'utilisateur final.
La plupart des CSS sont minifiés, ce qui réduit la taille des fichiers
La plupart de leur JavaScript est situé au bas de la page, ce qui permet au navigateur de charger la page en premier, puis de traiter le JavaScript qui sera transparent pour l'utilisateur.
Ils mettent en cache les fichiers statiques dont la date d'expiration est très éloignée

Fait assez intéressant, ils obtiennent un faible score de Google Page Speed (73 sur 100). J'ai remarqué qu'ils ne compressaient pas leurs fichiers texte avec gzip. Ils seraient encore plus rapides s'ils le faisaient.