2017-11-02 7 views
1

See: https://developers.google.com/maps/documentation/javascript/tutorialVerwendet Google den falschen Weg?

Google nutzt hier:

<script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap" async defer></script> 
</body> 
</html> 

Meine Frage ist, warum Google „verschieben“ verwendet, denn meiner Meinung nach ist es nicht im Skript von ihnen über alles tun?

wir diesen (1) Vergleichen:

<script src="script.js" defer></script> 
</body> 
</html> 

Mit diesem (2):

<script src="script.js"></script> 
</body> 
</html> 

Der einzige Unterschied ist, dass, wenn "script.js" im Falle der Ausführung: (1), Sie werden sicher sein, dass das "Ende des Body-Tags" und "Ende des HTML-Tags" noch nicht im DOM enthalten sind. Im Fall (1) sind diese Tags bereits im DOM, wenn "script.js" ausgeführt wird. Aber das Ende des body/html Tags ändert nichts auf Ihrem Bildschirm (Rendering), so dass diese Tags tatsächlich keinen Einfluss auf das "Rendering" haben. Theoretisch gibt es einen kleinen Unterschied zwischen diesen beiden Beispielen, aber in der Praxis gibt es überhaupt keinen Unterschied.

Also was könnte der Grund sein, Defer zu verwenden? Lass uns zurück in die Geschichte gehen. Wenn Sie in alten Browsern verwenden würden:

<script src="script.js"></script> 
</body> 
</html> 

Die Probleme waren, dass Sie nicht "Preload-Scanner" hatten. Sie können das Dokument (parallel) scannen und nach Downloads suchen, die bereits gestartet werden sollen. Ein alter Browser würde "script.js" zum ersten Mal sehen, wenn der "HTML-Parser" diesen Teil des Dokuments erreichen würde. Das ist ziemlich spät, um den Download zu beginnen und Zeitverschwendung. Aus diesem Grund haben sie "defer" entwickelt, so dass Sie das Skript-Tag am Anfang des Dokuments platzieren können, aber die Ausführung würde stattfinden, wenn der HTML-Parser mit dem gesamten Dokument ausgeführt wird (damit der HTML-Parser nicht blockiert wird)).

Für neuere Browser würde "defer" sowieso keinen Sinn ergeben, weil Sie einfach ein "sync script tag" verwenden könnten, kurz vor dem Ende der Seite. Der "Preload Scanner" startet den Download fast sofort. Und weil Sie es am Ende des Dokuments platzieren, wird die Ausführung des Skripts den HTML-Parser nicht blockieren (execept end body/html, aber diese Tags haben keinen Einfluss auf das Rendering).

Also "Defer" fügt nur älteren Browsern etwas Funktionalität hinzu, da Sie in neueren Browsern einfach das "sync script tag" am Ende des Dokuments verwenden können.

Aber Verschiebung in älteren Browsern wäre nur sinnvoll, wenn Sie das Skript-Tag am Anfang des Dokuments und nicht am Ende des Dokuments platzieren. Wenn Sie "Defer" am Ende des Dokuments platzieren, muss der Browser trotzdem lange warten, bevor er mit dem Download beginnen kann.

Also was ich sage ist: "Defer" macht keinen Unterschied in der Praxis, wenn Sie es auf ein Skript-Tag kurz vor dem Ende des Dokuments setzen. Es würde nur Sinn machen, wenn Sie es am Anfang des Dokuments auf ein Skript-Tag setzen würden.

So sieht es für mich aus, dass Google die Bedeutung von "Defer" nicht wirklich versteht, denn warum würden sie es hinzufügen? Es macht nichts. Oder denkt das falsch an mich?

Dies sind einige weitere Fragen/Beiträge von mir, wo ich meine Zweifel sowieso über das, was Google sagt über Rendering und mit aufschieben/Asynchron-et cetera:

Google is wrong about defer?

Why a browser is not always finishing rendering of the preceding HTML, before executing javascript?

External blocking scripts force the browser to wait, before the page can be rendered?

Consequences javascript can have document.write in the code?

Scripts that are dynamically created don't block rendering?

Loading external javascript via async script tag at the end of a webpage

Deshalb habe ich überprüfen wollte, wie Google ihre eigenen Skripts macht und nach einer Google-Suche fand ich schon dieses Beispiel, mit mir seltsam aussehenden Verwendung von „verschieben“.

Jedenfalls könnte es einen Grund geben, es zu benutzen, aber Google ist nicht klar mit dem richtigen Grund. In der Dokumentation erzählt Google die Geschichte, die ich dir in diesem Post/Frage erzählt habe. Aber das ist kein Grund, "Defer" so zu benutzen.

Ich weiß, dass verschiedene Browser "verschiebt" anders, also vielleicht ist das der Grund, warum Google es verwendet. Aber dann gibt ihre Dokumentation nicht die richtigen Gründe. Und dann ist meine Frage, was genau dieser Grund ist?

Wer weiß mehr darüber? Oder "Defer" ist wirklich umsonst im Skript von Google?

Antwort

0

Ich habe darüber nachgedacht und ich werde es versuchen, meine eigene Frage zu beantworten;). Wahrscheinlich denkt Google, dass Leute diesen Code kopieren/einfügen werden:

... und fügen Sie es einfach irgendwo auf der Seite hinzu. In einem solchen Fall würde "Defer" Sinn machen.

Eigentlich, wenn Sie 1 Skript-Tag am Ende des Dokuments haben, und Sie verwenden "async" darauf, es macht auch keinen Sinn. Aber es ist sinnvoll, wenn sich das Script-Tag nicht am Ende des Dokuments befindet.

Aber wenn ich Google wäre, würde ich trotzdem einige Notiz darüber hinzufügen, denn wenn Sie eine große Firma sind, Leute überprüfen Beispiele und schätzen es. Ich kenne selbst Webmaster, die nur am Ende des Dokuments async/defer zu einem Script-Tag hinzufügen, obwohl es das einzige ist. Du könntest denken: Aber es tut nichts, also was ist das Problem daran? Zum Beispiel kann async einfach etwas mehr Verzögerung hinzufügen, bevor JavaScipt ausgeführt wird (verglichen mit der Synchronisation). In einem solchen Fall kann es besser sein, die Synchronisierung in Bezug auf die Seitengeschwindigkeit anstelle von asynchron auf Ihrem Skript-Tag zu verwenden.

Verwandte Themen