2011-08-14 11 views
8

Czy idąc odCzy to jest optymalizacja?

<script type="text/javascript" src="jquery.js"></script> 

do

<script type="text/javascript"> 
    <?php echo file_get_contents('jquery.js'); ?> 
</script> 

naprawdę przyspieszyć?

Myślę, że tak, ponieważ php może pobierać i osadzać zawartość pliku szybciej niż przeglądarka klienta może złożyć pełne żądanie pliku, ponieważ php nie przechodzi przez sieć.

Czy główna różnica polega na tym, że tradycyjna metoda może być buforowana?

+2

To powoduje jednak buforowanie. – GWW

+2

@ GWW zamień "może" na "wolę". :) – nickf

+1

@nickf: Naprawiono;) – GWW

Odpowiedz

11

To może być szybciej na stronie obciążenia pierwszy, ale na każdym kolejnym obciążeniem będzie znacznie wolniej. W pierwszym przykładzie przeglądarka klienta buforowałaby wynik. W drugim nie może.

2

Musisz przenieść bajty do przeglądarki w obu przypadkach. Jedyna różnica polega na tym, że w drugim przypadku zapisujesz żądanie HTTP. Upewnij się również, aby uciec javascript za pomocą CDATA lub używając htmlspecialchars.

Jeśli umieścisz swoją bibliotekę JS na stronie HTML, nie będzie ona buforowana przez przeglądarkę. Dobrym pomysłem jest utrzymywanie JS oddzielnie od normalnego kodu HTML, ponieważ przeglądarka może go buforować i nie musi pobierać go w kolejnych żądaniach.

Tak więc, aby było krótko, jest to optymalizacja, która działa tylko wtedy, gdy strona jest wywoływana raz przez użytkownika, a jquery nie jest używana na innych stronach.


Alternatywnie, można użyć jQuery z google apis - co powoduje, że są one często w pamięci podręcznej przeglądarki tak, więc nie ma potrzeby, aby przenieść lib w ogóle.

+1

W HTML 4.01 typ elementu 'SCRIPT' zadeklarował już zawartość CDATA. –

+1

... i 'htmlspecialchars' bardzo źle zepsują, powiedzmy, porównania takie jak' if (a

+0

Spodziewałem się, że strona będzie XHTML, a przy XHTML musisz uciec. – cweiske

0

To zależy od tego, ile plików używa tego samego pliku. Jednak w większości sytuacji będzie to wolniejsze niż twój pierwszy fragment kodu, głównie dlatego, że można buforować pamięć jquery.js.

4

Jeśli w życiu klienta służysz tylko jednej witrynie, to tak, ponieważ masz tylko jedno żądanie HTTP zamiast dwóch.

Jeśli zamierzasz serwować wiele witryn, z których wszystkie są połączone z tym samym plikiem źródłowym javascript, duplikujesz wszystkie te nadmiarowe dane i nie dajesz klientowi możliwości buforowania tego pliku.

0

Tak, początkowo byłaby to optymalizacja wydajności pod względem liczby żądań HTTP używanych do obsługi strony - Twoja strona będzie jednak nieco większa na stronę pageload, ponieważ jquery.js będzie buforowana w przeglądarce po pierwszym pobraniu .

0

Ma to miejsce, jeśli strona jest statyczna.
Ale jeśli nie jest statyczna, przeglądarka pobierze stronę w czasie, gdy jquery się nie zmieni, ale nadal będzie dołączony. jeśli użyjesz src="jquery.js", a strona ulegnie zmianie, przeglądarka załaduje jquery z pamięci podręcznej i nie pobierze go ponownie, więc używanie src="jquery.js" jest rzeczywiście szybsze.

2

Robi to dla tej JEDNEJ STRONY.

Wszystkie kolejne strony korzystające z tej samej biblioteki (jquery.js pobrane z tego samego adresu URL) SUFFER, ponieważ jeśli podasz odniesienie do zewnętrznego pliku tak, to musi zostać pobrane w dodatkowym połączeniu (które jest stosunkowo tanie z HTTP \ 1.1 i pipelining), BUT - pod warunkiem, że twój serwer obsługuje go z przydatnymi nagłówkami (wygasa: -header daleko w przyszłości), przeglądarka buforuje to pobieranie, podczas gdy z "optymalizacją" musi ją pobrać z każdą zawartością- strona.

zobaczyć również stron takich jak ta: http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/

(słowo kluczowe tutaj jest „revving” w związku z tymi daleko przyszłych dat ważności)

2

Pierwszym z nich jest lepszy, ponieważ przeglądarka może buforować scenariusz. W drugiej wersji będzie musiał ponownie pobrać skrypt za każdym razem, gdy ładuje stronę, nawet jeśli skrypt się nie zmienił.

Jedyny przypadek, gdy druga wersja ulepsza skrypty, których nie może buforować przeglądarka.