홈페이지 로딩 시간이 너무 길어요 도와주세요. 정보
홈페이지 로딩 시간이 너무 길어요 도와주세요.본문
저번에 질문에 답변해 주셔서 감사합니다. 그런데 저의 짧은 지식 때문에 아직도 해결 하지 못했네요
현재 제가 만들고 있는 홈피는 http://125.250.82.189 인데요. 이상하게 접속을 하면 상태 표시줄에 완료가 한번 된 후, 로딩이 됩니다. 익스 상태 표시줄에 보면 로딩 되고 있는 것들이 보이잖아요.
그래서 그런지 접속이 바로 되지 않고 1-2초 정도 멈추는 현상이 있습니다.
너무 많은 최신글을 올려서 그런지 아니면 제가 iframe 를 3개 쓰는데 그것때문인지. 시그너스님이 접속자 스킨에 있는 sql을 너무 많이 쓴다고 해서 제거 해 보고 했는데도 여전히 중간에 멈추는 현상이 있습니다.
제가 너무 막연한 질문을 했는지 모르겠군요. 그럼 꼭 고수님들의 좋은 조언 부탁합니다.
댓글 전체
웹브라우저 최하단의 상태표시줄에 출력되는 상태 정보는,
하나. 네트워크 부하 또는 속도지연에 따른 비교적 원활하지 못한 네트워크 상황에서 비롯될 수 있으며,
둘. 과도한 자바스크립트의 사용으로 각각의 자바스크립트가 충돌되어 발생될 수 있고,
셋. 비교적 상태가 양호한 자신의 계정(계정 경로의)의 내용을 iframe으로 사용하지 않고,
외부의 내용(뉴스티커 등)을 끌어쓰는 경우에 빈번하게 발생될 수 있으며,
넷. 자신의 계정이라 할지라도 그누보드가 설치된 경로 또는 설치된 경로의 하단이 아닌,
그누보드가 설치된 경로와 평행한 구조이거나 그 이외의 외부 경로에서
특정한 내용을 iframe으로 끌어오는 경우 발생될 수 있고,
다섯. '시그너스'님께서 기존에 답변을 주셨듯이, 초기화면에서 sql 쿼리문의 과도한 사용에서 비롯될 가능성도 크며,
여섯. 자바스크립트와 연동되는 각종 메뉴나 이미지(자잘한 각종 아이콘 포함)에서 비롯될 수도 있습니다.
일곱. 또한 특정한 PC에서만 로딩에 문제가 있는 경우라면
쿠키를 비롯한 인터넷 임시파일을 모두 삭제함과 동시에 PC에 과부하가 걸릴 수 있는
각종 프로그램등을 'PC최적화' 기능을 수행할 수 있는 프로그램으로 정리해 볼 필요도 있습니다.
하나. 네트워크 부하 또는 속도지연에 따른 비교적 원활하지 못한 네트워크 상황에서 비롯될 수 있으며,
둘. 과도한 자바스크립트의 사용으로 각각의 자바스크립트가 충돌되어 발생될 수 있고,
셋. 비교적 상태가 양호한 자신의 계정(계정 경로의)의 내용을 iframe으로 사용하지 않고,
외부의 내용(뉴스티커 등)을 끌어쓰는 경우에 빈번하게 발생될 수 있으며,
넷. 자신의 계정이라 할지라도 그누보드가 설치된 경로 또는 설치된 경로의 하단이 아닌,
그누보드가 설치된 경로와 평행한 구조이거나 그 이외의 외부 경로에서
특정한 내용을 iframe으로 끌어오는 경우 발생될 수 있고,
다섯. '시그너스'님께서 기존에 답변을 주셨듯이, 초기화면에서 sql 쿼리문의 과도한 사용에서 비롯될 가능성도 크며,
여섯. 자바스크립트와 연동되는 각종 메뉴나 이미지(자잘한 각종 아이콘 포함)에서 비롯될 수도 있습니다.
일곱. 또한 특정한 PC에서만 로딩에 문제가 있는 경우라면
쿠키를 비롯한 인터넷 임시파일을 모두 삭제함과 동시에 PC에 과부하가 걸릴 수 있는
각종 프로그램등을 'PC최적화' 기능을 수행할 수 있는 프로그램으로 정리해 볼 필요도 있습니다.
자신이 자리부터 그 서버에 도달하는 루트입니다.
명령어 창에서
C:\tracert 125.250.82.189 -j >a.dat 엔터
한참 기다리시면
C:\에 a.dat 가 생성되면서
열어보면 아래와 같은 통과되는 일단의 라우터주소가 보일겁니다.
어느 부분에서 병목이 생기는지는 정확하진 않습니다.
같은 대역의 203 IP가 3개 인걸보니 그중하나는
라우터나,공유기나,허브가 물린 컴같네요.
이렇게 연결된 장비의 하나하나를 체크하기란
회선제공하는 업체의 도움없이는 불가하죠.
Tracing route to 125.250.82.189 over a maximum of 30 hops
1 6 ms 6 ms 6 ms 10.174.64.1
2 7 ms 6 ms 15 ms 222.235.203.1
3 7 ms 8 ms 6 ms 58.229.48.53
4 15 ms 11 ms 12 ms 211.117.1.125
5 12 ms 15 ms 11 ms 211.117.39.134
6 17 ms 19 ms 18 ms 61.43.0.229
7 19 ms 15 ms 14 ms 210.92.194.113
8 15 ms 20 ms 14 ms 210.120.61.205
9 18 ms 19 ms 18 ms 210.120.103.90
10 20 ms 18 ms 24 ms 203.233.49.2
11 17 ms 19 ms 16 ms 203.233.49.42
12 19 ms 17 ms 17 ms 203.248.226.106
13 19 ms 17 ms 18 ms 125.250.82.189
Trace complete.
회선이 좋다는 가정하에서
1,욕심을 버리세요.
아무리 서버가 좋아도 포털을 흉내내지는 마십시요.
많은 수의 형식에 맞는 서버가 통신컨트롤러를 통해서 호스트와
물려있는 형태를... 하나의 페이지 에서 보여주는 건 무리입니다.
업스크롤이 1개만 되어도 CPU의 점유율은 높아 집니다.
그런 스타일이 한페이지에 5를 쓰시는군요.
페이지를 쪼개시고 1개만 쓰세요.
이미지도 줄이시고. 포샵에서 저장도 save for web 으로 하시고.
명령어 창에서
C:\tracert 125.250.82.189 -j >a.dat 엔터
한참 기다리시면
C:\에 a.dat 가 생성되면서
열어보면 아래와 같은 통과되는 일단의 라우터주소가 보일겁니다.
어느 부분에서 병목이 생기는지는 정확하진 않습니다.
같은 대역의 203 IP가 3개 인걸보니 그중하나는
라우터나,공유기나,허브가 물린 컴같네요.
이렇게 연결된 장비의 하나하나를 체크하기란
회선제공하는 업체의 도움없이는 불가하죠.
Tracing route to 125.250.82.189 over a maximum of 30 hops
1 6 ms 6 ms 6 ms 10.174.64.1
2 7 ms 6 ms 15 ms 222.235.203.1
3 7 ms 8 ms 6 ms 58.229.48.53
4 15 ms 11 ms 12 ms 211.117.1.125
5 12 ms 15 ms 11 ms 211.117.39.134
6 17 ms 19 ms 18 ms 61.43.0.229
7 19 ms 15 ms 14 ms 210.92.194.113
8 15 ms 20 ms 14 ms 210.120.61.205
9 18 ms 19 ms 18 ms 210.120.103.90
10 20 ms 18 ms 24 ms 203.233.49.2
11 17 ms 19 ms 16 ms 203.233.49.42
12 19 ms 17 ms 17 ms 203.248.226.106
13 19 ms 17 ms 18 ms 125.250.82.189
Trace complete.
회선이 좋다는 가정하에서
1,욕심을 버리세요.
아무리 서버가 좋아도 포털을 흉내내지는 마십시요.
많은 수의 형식에 맞는 서버가 통신컨트롤러를 통해서 호스트와
물려있는 형태를... 하나의 페이지 에서 보여주는 건 무리입니다.
업스크롤이 1개만 되어도 CPU의 점유율은 높아 집니다.
그런 스타일이 한페이지에 5를 쓰시는군요.
페이지를 쪼개시고 1개만 쓰세요.
이미지도 줄이시고. 포샵에서 저장도 save for web 으로 하시고.
현재 적용된 초기화면의 내용에서 스크롤되는 최근게시물을 빼버린후 화면을 한번 로딩해보시기 바랍니다.
정확하지는 않습니다만 위의 스킨이 속도를 많이 잡아먹는 현상을 봤던 기억이 있군요 ^^
그리고 나스카님께서 체크리스트를 주셨는데...
그중에서 두번째의 사항을 체크하시어 현재의 초기화면에서 꼭필요하지 않은 자바스크립터는 제거를 해주시는것이 좋을것 같습니다.
정확하지는 않습니다만 위의 스킨이 속도를 많이 잡아먹는 현상을 봤던 기억이 있군요 ^^
그리고 나스카님께서 체크리스트를 주셨는데...
그중에서 두번째의 사항을 체크하시어 현재의 초기화면에서 꼭필요하지 않은 자바스크립터는 제거를 해주시는것이 좋을것 같습니다.
나스카님의 조언과 답변 감사합니다. 그런데 이거 너무 막막하네요. 과감하게 iframe을 버려야 할지...역시 초보라 힘들군요.
혼자 학교 홈페이지 만들라고 벌써 2달이 지나갔는데, 아이들에게 2학기때 새롭게 오픈한다고 약속했는데 아직도 약속을 못지켰네요, 새로이 오픈을 하기 직전인데 여전히 문제가 발생해서 급한 마음에...,
답답하네요. 끝에 와서 문제가 생기다니. 저희 서버 라인이 512k밖에 안되서 가능하면 무겁지 않게 만들려고 했는데. 역시나 만들다 보면 욕심이 자꾸 생겨서..ㅋㅋㅋ
혼자 학교 홈페이지 만들라고 벌써 2달이 지나갔는데, 아이들에게 2학기때 새롭게 오픈한다고 약속했는데 아직도 약속을 못지켰네요, 새로이 오픈을 하기 직전인데 여전히 문제가 발생해서 급한 마음에...,
답답하네요. 끝에 와서 문제가 생기다니. 저희 서버 라인이 512k밖에 안되서 가능하면 무겁지 않게 만들려고 했는데. 역시나 만들다 보면 욕심이 자꾸 생겨서..ㅋㅋㅋ
음, 제가 보기에는 팝업때문에 그런것 같군요
먼저 팝업띄우는것을 제거한후
열어보시면
속도가 빨라졋다고 느껴지시면
팝업 띄우는 스크립트를
<body 태그안에 onload 이벤트시 작동하도록 넣어주시거나
공통하단 젤 마지막에 넣어주시기 바랍니다.
먼저 팝업띄우는것을 제거한후
열어보시면
속도가 빨라졋다고 느껴지시면
팝업 띄우는 스크립트를
<body 태그안에 onload 이벤트시 작동하도록 넣어주시거나
공통하단 젤 마지막에 넣어주시기 바랍니다.
음 그리고 tail.sub.php 은 젤 마지막에 나와야 하는데
html 하단 중간에 끼어있네요.
그리고
</body>
</html>
이것도 다섯번 나오네요.
<body~~ 이것은 두번......
일단 현재 메인페이지에서 소스보기해서
어느 부분이 잘 못됏는지 확인하고
인클루드가 잘 되었는지
태그가 제대로 자기 위치에 가서 붙엇는지
여러가지 점검해보시는게 좋겟네요.
html 하단 중간에 끼어있네요.
그리고
</body>
</html>
이것도 다섯번 나오네요.
<body~~ 이것은 두번......
일단 현재 메인페이지에서 소스보기해서
어느 부분이 잘 못됏는지 확인하고
인클루드가 잘 되었는지
태그가 제대로 자기 위치에 가서 붙엇는지
여러가지 점검해보시는게 좋겟네요.
언제 이렇게 많은 답변이 들어 왔지 하여간 너무들 감사합니다.
When swallowing small doses of code, JavaScript interpreters tend to process data speedily.
But if you throw a ton of complex and deeply nested code at a browser,
you may notice some latency, even if all the data is downloaded in the browser.
Here are a handful of useful tips to help you unclog potential processing bottlenecks in your code:
* Avoid using the eval( ) function
* Avoid the with construction
* Minimize repetitive expression evaluation
* Use simulated hash tables for lookups in large arrays of objects
* Avoid multiple document.write( ) method calls
Look for these culprits especially inside loops, where delays become magnified.
The final tip addresses use of the document.write( ) method to generate content while the page loads.
Treat this method as if it were an inherently slow input/output type of operation. Invoke the method
as infrequently as possible. If you are writing a lot of content to the page, accumulate the HTML
into a string variable, and blast it to the page with one call to document.write( ).
JavaScript & DHTML Cookbook
By Danny Goodman
But if you throw a ton of complex and deeply nested code at a browser,
you may notice some latency, even if all the data is downloaded in the browser.
Here are a handful of useful tips to help you unclog potential processing bottlenecks in your code:
* Avoid using the eval( ) function
* Avoid the with construction
* Minimize repetitive expression evaluation
* Use simulated hash tables for lookups in large arrays of objects
* Avoid multiple document.write( ) method calls
Look for these culprits especially inside loops, where delays become magnified.
The final tip addresses use of the document.write( ) method to generate content while the page loads.
Treat this method as if it were an inherently slow input/output type of operation. Invoke the method
as infrequently as possible. If you are writing a lot of content to the page, accumulate the HTML
into a string variable, and blast it to the page with one call to document.write( ).
JavaScript & DHTML Cookbook
By Danny Goodman