» »

[JS] Event, ko se stran naloži po "back" gumbu?

[JS] Event, ko se stran naloži po "back" gumbu?

HotBurek ::

Pozdravljeni.

Opazil sem, da če grem nazaj na prejšno stran z gumbom "back", mi naloži zgolj HTML, CSS in JS pa ne. Potem naredim refresh, in zlouda tudi CSS in JS.

Gre se za iPhone OS 7_1_2 ter Safari 9537.53.

Headerje imam takole:

HTTP/2.0 200 OK
server: nginx
date: Mon, 21 Oct 2019 18:54:42 GMT
content-type: text/css; charset=utf-8;
vary: Accept-Encoding
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
access-control-allow-origin: *
expect-ct: max-age=0
cache-control: : no-cache, no-store, must-revalidate
pragma: : no-cache
content-encoding: gzip
X-Firefox-Spdy: h2



Zanima me, če se da v JS priklopit na kakšen event in ob siteLoad preverit, ali je uporabnik uporabil gumb "back" (ter naredi site reload)?

Oz. če je kakšna druga rešitev?
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

HotBurek ::

Zadevo sem rešil na neoptimalen način.

Prvo sem iz header-jev odstranil "cache-control" in "pragma" (ta je tako oldis goldis), in je sprva izgledalo, da dela. Ampak sem potem še testiral in odstranitev header-jev ni pomagalo.

Sedaj sem rešil tako, da za vsak request index.hml fajla spremenim CSS path; dodam random cifro: href="/index.css?r=1837833264"

Je mal problem, ker za vse strani uporabljam isti paht (/index.css), vsebina response-a se pa spremnija, odvisno od referer-ja.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

MrStein ::

Zakaj pa bi rad CSS na novo naložil? A se tako pogosto spreminja?

Oziroma najprej to: kaj misliš z "ne naloži CSS" ?
A uporabi staro verzijo iz cache? Ali pa sploh ne naloži CSS in je stran "nikakva" ?
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Spura ::

Mislim da ni nobenemu jasno kaj je mislil. Da mu ne nalozi JS in CSS lahko pomeni vec razlicnih stvari.

HotBurek ::

Iz log fajlov se vidi, da (ko greš back) naredi samo GET request za HTML, notri v HTML-ju sta dva linka (CSS in JS), katerih pa ne naloži in je stran "nikakgva".

Iz cache-a na ni naložil, ker (mislim) sem to disejblal.

Tole še moram naštudirat. Sem videl tudi Etag. Mislim, da se ta spremeni, če se spremeni vsebina in potem klient ve, kdaj naložit novo (spremenjeno) vsebino.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

kuall ::

https://stackoverflow.com/questions/263...

če daš js/css fajlom končnico npr ?version=date pol se bo naložila nova verzihja fajla klientom, ko date spremeniš.

tvoj scenarij je možen, če js in css nalagaš dinamično.

Zgodovina sprememb…

  • spremenilo: kuall ()

HotBurek ::

Sej tako sem sedaj rešil. Generiram random število in ob HTML response-u pofixam /index.css link v index.css?r+123456...random, pa dela.

Fix je slab, moram popravit tako, da bodo različni URL-ji za CSS-je in ne samo /index.css po vseh straneh, a zaenkrat dela in lahko grem naprej.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

Spura ::

HotBurek je izjavil:

Iz log fajlov se vidi, da (ko greš back) naredi samo GET request za HTML, notri v HTML-ju sta dva linka (CSS in JS), katerih pa ne naloži in je stran "nikakgva".

Iz cache-a na ni naložil, ker (mislim) sem to disejblal.

Tole še moram naštudirat. Sem videl tudi Etag. Mislim, da se ta spremeni, če se spremeni vsebina in potem klient ve, kdaj naložit novo (spremenjeno) vsebino.

Ja browser ima caching in ti je JS file in CSS file iz cachea vzel. Ce dodajas random stvari na koncu linka je isto kot bi cache izklopu, torej se pojavi vprasanje zakaj ga ne.
Dodatek &version=date je pac hack od JS programerjev, ker kot vedno pojma nimajo o lastnem okolju v katerem delajo.

MrStein ::

> Iz log fajlov se vidi, da (ko greš back) naredi samo GET request za HTML, notri v HTML-ju sta dva linka (CSS in JS), katerih pa ne naloži in je stran "nikakgva".

Da ne naloži iz serverja ampak vzame iz cache je normalno.

Da pa je stran "nikakgva" pa ni normlano. A sploh CSS ne upošteva?

Ali gre za nek blazen JS/CSS hackery na strani, ali pa... no počakamo na več informacij.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

HotBurek ::

Evo, recimo kot primer. Sta dve HTML strani:
/modra.html
/zelena.html

Obe imata v HEAD-u:
link type="text/css" rel="stylesheet" href="/index.css"

Strežnik, glede na referer vrača različno vsebino:
GET /index.css (referer=/modra.html) vrne:
.element1 { background-color: blue; }

GET /index.css (referer=/zelena.html) vrne:
.element2 { background-color: green; }


In potem, obiščeš modro stran, in je element1 modre barve. Klikneš na link href="/zelena.html", in element2 je zelen. Sedaj pa v brskalniku (kot rečeno, iPhone 4 + Safari) klikneš "back" (gumb od samega brovserja), in brskalnik (predvidevam) iz cache-a potegne "index.css" za zeleno stran in element2, kljub temu, da si na modri strani in potrebuješ CSS za element1.


p.s.: Včasih študiram, da bi bilo bolje, lažje in hitreje naredit nek 1-2-3 minutni video s predstavitvoji problema. One day, but not today. :O
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

Zgodovina sprememb…

  • spremenilo: HotBurek ()

Spura ::

Ja valda da dela k drek, ker ti browserju za dobesedno isti file vracas razlicne vrednosti. File /index.css je pac ena entiteta za browser, ki jo ti vracas kot razlicno glede na potek uporabnikove navigacije, od kje ti ideja da je to kakorkoli sprejemljivo.

Zakaj pa ne mores imeti /index-modra.css includean na modra.html in pa /index-zelena.css na zeleni strani?

MrStein ::

HotBurek je izjavil:


Strežnik, glede na referer vrača različno vsebino:

There's your problem right there.

(kot je že spura rekel)

HotBurek je izjavil:


p.s.: Včasih študiram, da bi bilo bolje, lažje in hitreje naredit nek 1-2-3 minutni video s predstavitvoji problema. One day, but not today. :O

Ni treba, zgoraj citiran stavek vse pove.

Razumem pa da si naklonjen nepotrebnemu kompliciranju. ;)

MrStein je izjavil:


Ali gre za nek blazen JS/CSS hackery

Jep, kot se mi je zdelo. ;)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

MrStein ::

HotBurek je izjavil:


Strežnik, glede na referer vrača različno vsebino:

Sem sicer pred tedni imel en tak problem, ko je en sistem različno deloval glede na refer. Ko se je drugi sistem, od koder je request prihajal spremenil, se je celotna zadeva seveda sesula.

Hvalabogu se referer zadnje čase ukinja, in bo takih ... kixov ... vedno manj.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

HotBurek ::

Do tega pojava je prišlo, ker imam sledeč sistem. Za vsak request HTML dokumenta prvo preberem "fame", v katerem je vključen HEAD z vsemi elementi (in ponavljajočim /index.css linkom), potem pa glede na request ("/", "/stuff.html", "info.html") znotraj BODY-ja dodam "content".

Zadeva dela super, tudi v FF na desktopu. Na ne najbolj pravilno delovanje sem naletel šele z iPhone 4 + Safari in navigiranja z "back" gumbom v browserju.

In ja, rešil bom tako, da bom v HTML HEAD-erju vračal različne linke ("/index.css", "/stuff.css", "/info.css"). Je na to-do listi.

Sicer pa referer uporabljam zato, ker imam več CSS fajlov in potem dinamično, glede na referer, skupaj zložim (in v enem samem request-u vrnem) samo tiste CSS-je, katere stran potrebuje. Tako se vrne minimalno CSS-ja.

Se pravi, stran "/abc.html" potrebuje 3 CSS fajle. Stran (oz. brskalnik) naredi request "/abc.css" z referer-jem "/abc.html", program (na strežniku) to vidi, prebere tri CSS fajle ("troll.css", "master.css", "king.css") in jih vrne v enem "fajlu" /abc.css.
Tako brskalnik naredi samo en request za CSS (in samo enega za JS) in je res lepo za pogledat. :D
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

Zgodovina sprememb…

  • spremenilo: HotBurek ()

MrStein ::

Potem raje "zakodiraj" kaj je potrebno, v ime css linka in lahko imaš celo vse statično na serverju (manj CPU).

Torej abc.css za abc.html, abc_stuff.css za frame stuff.html in podobno.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

HotBurek ::

Mislim, da nea to gre tako.

Recimo na strežniku so CSS fajli:
fajl1.css
fajl2.css
fajl3.css

Za "/" potrebujem fajl1.css in fajl2.css. Za "/test.html" potrebujem fajl2.css in fajl3.css. Za "/this.html" potrebuje fajl1.css in fajl3.css.

Ker koda glede na referer sestavi CSS en sam "master" CSS, mi to omogoča, da dejanske CSS fajle spreminjam samo enkrat, vključenega imam pa na več straneh.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

misek ::

Zakaj pa ne vključiš CSS kar direktno v html datoteki? Saj že veš kaj moraš servirati. Potem sploh ne bo več dodatne zahteve za CSS datoteko :)

MrStein ::

HotBurek je izjavil:

Mislim, da nea to gre tako.

Recimo na strežniku so CSS fajli:
fajl1.css
fajl2.css
fajl3.css

Za "/" potrebujem fajl1.css in fajl2.css. Za "/test.html" potrebujem fajl2.css in fajl3.css. Za "/this.html" potrebuje fajl1.css in fajl3.css.

Ja, saj to sem mislil.
V "/" inkludaš "fajl1+2.css"
V "/test.html" inkludaš "fajl2+3.css"
V "/this.html" inkludaš "fajl1+3.css"

Na serverju pa:
GET "fajl1+2.css" --> vrneš vsebino fajl1.css ter fajl2.css
GET "fajl2+3.css" --> vrneš vsebino fajl2.css ter fajl3.css
GET "fajl1+3.css" --> vrneš vsebino fajl1.css ter fajl3.css

(to pa lahko narediš dinamično ali statično, po želji, kar ti bolj ustreza)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

HotBurek ::

Tako ja! 8-) To tudi pride na vrsto. Vsebina CSS-ja se bo vpisala med STYLE in /STYLE tag v HEAD-u, tako da requesta za CSS sploh ne bo.

Isto imam plan za JS, s tem, da ga bom zapisal na koncu, na koncu tik pred /BODY.

Tako bo samo en HTTP GET request za HTML fajl, ki bo vrnil (seveda narejeno dinamično na serverju) že zapečeno CSS in JS vsebino. In celoten site (kar je od HTML+CSS+JS) se bo naložil v kakšnih ~400ms (sedaj je 2x dlje).
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

MrStein ::

HotBurek je izjavil:


Isto imam plan za JS, s tem, da ga bom zapisal na koncu, na koncu tik pred /BODY.

To sicer z varnostnega vidika ni ravno najboljše.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

HotBurek ::

Kakšni pa so varnostni problemi, če je JS, ki je sicer serviran preko fajla, zapisan direktno v HTML med SCRIPT in /SCRIPT tag-i?
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

MrStein ::

To lahko kar novo temo odpreš o tem.

Kot prvo možnost XSS.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Spura ::

Zakaj je pa tok pomembno, da se vse naredi z enim requestom? Sicer je ze uredu da na mobitelih ne delas po 100 requestov, samo ce bos imel pac nekaj vec CSS fajlov te tut ne bo konec.

HotBurek ::

MrStein, sem naredil no thread: Inline JS v HTML; varnost, XSS, ...

Spura, rad bi naredil najboljši setup, kar se da. Se pravi, če se da dobit vse (HTML+CSS+JS) v enem requesti, ter da se izkaže, da je to super najhitrejše, potem bom imel tak config. Sicer pa nazaj, kjer je po 1xHTML, 1xCSS, 1xJS requestov, kar imam že sedaj.

Slabost trenutnega configa je, da po prejemu HTML-ja pač čaka na CSS in JS (sicer naredi vzporedno in ni moteče) in zadeva skupno traja ~800ms. Requesti trajajo nekje 200~250ms, s tem da sta CSS+JS vzporedna, se pravi 500ms skupaj za vse. Pol je pa še nek premor med HTML in CSS+JS.
Vsekakor bom potestiral, kako je če je vse v enem in pol bom videl, kater opcijo izbrat.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

Utisevalec ::

Linkanje na zunanje fileje za CSS in JS pomeni da čaka/nalaga browser vsebino samo prvič, potem uporabi cache. Skratka nalaganje na tak način ni nič počasnejše, še hitrejše je kot če bi imel en dinamičen klic. Četudi imaš 10 fajlov ki so različni po straneh se recimo naložijo slejkoprej v cache (lahko jih tudi forsiraš in naložiš v prvem "init nalaganju") in potem se ne nalagajo več. Pohitritev je tako na strani uporabnika (browser) kot tudi na strani serverja, ker se ne trudi z nepotrebnimi requesti. Enako velja za vso linkano vsebino, torej recimo tudi slike (te so lahko večje in se pozna cache tudi pri nalaganju na hirejših linijah).

Koncept gradnje spletnih strani je danes itak tak da se čimveč vsebine shrani lokalno in se potem uporablja lokalno. Včasih so to bili CSSji, JS in slike, danes imaš local storage tudi za ostale stvari, recimo podatke iz baze za obdelavo ipd.

Zgodovina sprememb…

MrStein ::

Delno off topic, ampak uporaba cache je še vedno pogosto zelo slaba. Primer:

( - sem na strani A)
( - kliknem link na stran B)
- stisnem gumb BACK

Zakaj se prejšnja stran (A) ne pojavi v trenutku? Saj je v cache. Pa še renderirana je bila in vse kaj gre zraven.

Kot workaround odpiram vse kar se da v novem tabu in potem ta novi tab zaprem. Prejšnja stran je v starem tabu in je na voljo takoj.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Utisevalec ::

To ni problem protokola ampak slabe uporabe caching opcij v samih webstraneh (in/ali) v browserjih. Recimo webserver ima nastavljeno da striktno pri dinamičnih spletnih straneh vrača v headerju "no-cache, no-store, must-revalidate", syadmin tega ne popravlja ker tako deluje za vse 100% (čeprav ali res?!). Razvijalci itak nimajo pojma kaj je cache, njim na optiki vedno vse dela hitro. Potem pridemo do tega da se cache ne uporablja tam kjer bi se lahko in se uporablja tam kjer se nebi smel!:)

HotBurek ::

Evo, sem naredil tako, da sem CSS in JS zapekel v HTML, in potem vse to skupaj vrnem.

Response je nekje v 300ms, potem še nekaj malega, da browser vse skupaj izriše. Stran se naloži v trenutku (ni tistih "resize" event-ov, ko je HTML že naložen, potem se pa CSS louda in stran "popravlja" na končni izgled).

Caching za HTML nimam vklopljen, je pa omogočen GZIP. Kolikor vidim, je razmerje nekje 1:4~5 med Transferred in Size.

Stestiral na desktop, iphone, ipad, in je uporaba res super. Tako hitro, kot klikaš, dobiš response nazaj. Stran se v trenutku prikaže..

(Na vrhu sta sliki keširani, spodaj je pa brez cache-a)
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window

Matek ::

MrStein je izjavil:

Delno off topic, ampak uporaba cache je še vedno pogosto zelo slaba. Primer:

( - sem na strani A)
( - kliknem link na stran B)
- stisnem gumb BACK

Zakaj se prejšnja stran (A) ne pojavi v trenutku? Saj je v cache. Pa še renderirana je bila in vse kaj gre zraven.

Kot workaround odpiram vse kar se da v novem tabu in potem ta novi tab zaprem. Prejšnja stran je v starem tabu in je na voljo takoj.
To, ali gre stran v cache ali ne, je odvisno od headerjev, ki jih pri prvem nalaganju posreduje server. Stran, ki jo gledaš, je dinamična, zato server browserju namenoma sporoči, naj je ne kešira - v nasprotnem primeru bi ti prebral novico na rtvslo.si, pritisnil back in dobil (sicer instantno naložen) front page s starimi novicami.
Bolje ispasti glup nego iz aviona.

Zgodovina sprememb…

  • spremenil: Matek ()

Spura ::

HotBurek je izjavil:

MrStein, sem naredil no thread: Inline JS v HTML; varnost, XSS, ...

Spura, rad bi naredil najboljši setup, kar se da. Se pravi, če se da dobit vse (HTML+CSS+JS) v enem requesti, ter da se izkaže, da je to super najhitrejše, potem bom imel tak config. Sicer pa nazaj, kjer je po 1xHTML, 1xCSS, 1xJS requestov, kar imam že sedaj.

Slabost trenutnega configa je, da po prejemu HTML-ja pač čaka na CSS in JS (sicer naredi vzporedno in ni moteče) in zadeva skupno traja ~800ms. Requesti trajajo nekje 200~250ms, s tem da sta CSS+JS vzporedna, se pravi 500ms skupaj za vse. Pol je pa še nek premor med HTML in CSS+JS.
Vsekakor bom potestiral, kako je če je vse v enem in pol bom videl, kater opcijo izbrat.

Ti namesto da bi normalne mehanizme v browserju uporabu, raje neki optimiziras stevilo requestov, namest da bi raje razmislu zakaj ti rabi 250ms za vsak request ki ima po 10kb unzipped. Zrihti raje server.


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
!

Vse, kar ste si želeli vprašati o CSS, pa si niste upali. (strani: 1 2 3 423 24 25 26 )

Oddelek: Izdelava spletišč
1297330905 (55054) htmltroubles
»

Kdo izdeluje klasične HTML/CSS/JS spletne strani?

Oddelek: Izdelava spletišč
222474 (1590) Phantomeye
»

Inline JS v HTML; varnost, XSS, ...

Oddelek: Programiranje
211531 (1139) MrStein
»

Nekaj vprašanj glede izdelave spletne strani.

Oddelek: Izdelava spletišč
384300 (3151) scipascapa
»

Pohitritev spletne strani

Oddelek: Izdelava spletišč
292083 (1026) vezalke

Več podobnih tem