Optimizarea vitezei / htaccess

Salutare Bogdan! Ma bucur sa vad tineri ambitiosi ca tine si care nu se dau guru in acest domeniu. De invatat avem toti, chiar si cei care sunt experti sau se considera experti. Daca nu este cu suparare, am sa iti dau cateva sfaturi pentru ca am putin timp liber si mai citesc cate ceva pe ici pe colo. Comunitatea asta are baieti capabili in domeniul SEO si ar trebui sa mai ceri ajutor din cand in cand. Stii, majoritatea uita cum a fost la inceputul carierei si este pacat sa nu ai respect fata de persoanele care sunt la inceput de drum, indiferent de domeniul in care activezi. Uite ce cred ca ar trebui sa faci la site-ul tau:

1. La instalarea unei teme WordPress, primul lucru care trebuie facut este sa redenumesti folderul temei in ceva care are legatura cu domeniul de activitate al site-ului. In cazul tau, nu ar trebui sa fie "zerif-lite", ci "web-design", sau "seo", etc. Daca vrei sa faci acum acest lucru, descarca tema in calculatorul tau, o redenumesti, urmezi pasii de la punctul 3, o incarci si o activezi.
2. Orice tema WordPress, are un fisier CSS, care se numeste style.css. Deschizi fisierul respectiv cu un editor de text si modifici datele de acolo. Nu este OK, sa apara "Theme Name: Zerif Lite"
3. Este foarte bine sa schimbi URL-ul catre folderul "wp-content", adica sa nu mai fie /wp-content/themes/, sa fie ceva de genul /fisiere-seo/themes/. Cum faci asta:

In structura WordPress (totul se face dupa instalarea WordPress si a temei), editezi fisierul wp-config.php si jos de tot adaugi asta:

/** Setează variabilele WordPress și fișierele incluse. */
define ('WP_CONTENT_FOLDERNAME', 'fisiere-seo');
define ('WP_CONTENT_DIR', ABSPATH . WP_CONTENT_FOLDERNAME) ;
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/');
define('WP_CONTENT_URL', WP_SITEURL . WP_CONTENT_FOLDERNAME);

require_once(ABSPATH . 'wp-settings.php');
header("Last-Modified: " . the_modified_date());


Dupa adaugarea codului respectiv, redenumesti fisierul wp-content in fisiere-seo, sau ce vrei tu dar sa fie acelasi nume ca in prima linie de cod, unde scrie fisiere-seo

4. Cresterea vitezei de incarcare in browser - poti testa site-ul inainte de adaugarea codului in .htaccess, cu PageSpeed Insights, de la Google. Editezi fisierul .htaccess si adaugi in partea de sus urmatorul cod de optimizare:

#Start Optimizare SEO on-page
<IfModule mod_expires.c>
FileETag none
ExpiresActive on
# Perhaps better to whitelist expires rules? Perhaps.
ExpiresDefault "access plus 1 month"
# cache.appcache needs re-requests
# in FF 3.6 (thx Remy ~Introducing HTML5)
ExpiresByType text/cache-manifest "access plus 0 seconds"
# Your document html
ExpiresByType text/html "access plus 0 seconds"
# Data
ExpiresByType text/xml "access plus 0 seconds"
ExpiresByType application/xml "access plus 0 seconds"
ExpiresByType application/json "access plus 0 seconds"
# RSS feed
ExpiresByType application/rss+xml "access plus 1 hour"
# Favicon (cannot be renamed)
ExpiresByType image/x-icon "access plus 1 week"
# Media: images, video, audio
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType video/ogg "access plus 1 month"
ExpiresByType audio/ogg "access plus 1 month"
ExpiresByType video/mp4 "access plus 1 month"
ExpiresByType video/webm "access plus 1 month"
# HTC files (css3pie)
ExpiresByType text/x-component "access plus 1 month"
# Webfonts
ExpiresByType font/truetype "access plus 1 month"
ExpiresByType font/opentype "access plus 1 month"
ExpiresByType application/x-font-woff "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 month"
ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
# CSS and JavaScript
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType text/javascript "access plus 1 year"
<IfModule mod_headers.c>
Header append Cache-Control "public"
</IfModule>
<IfModule mod_deflate.c>
# force deflate for mangled headers
# developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping/
<IfModule mod_setenvif.c>
<IfModule mod_headers.c>
SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
</IfModule>
</IfModule>
</IfModule>
# HTML, TXT, CSS, JavaScript, JSON, XML, HTC:
<IfModule !mod_filter.c>
# Legacy versions of Apache
AddOutputFilterByType DEFLATE text/html text/plain text/css application/json
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE text/xml application/xml text/x-component
AddOutputFilterByType DEFLATE application/xhtml+xml application/rss+xml application/atom+xml
AddOutputFilterByType DEFLATE image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype
</IfModule>
#Expire Header
<FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css|swf)$">
ExpiresDefault "access plus 2 hours"
</FilesMatch>
# compress text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddType x-font/otf .otf
AddType x-font/ttf .ttf
AddType x-font/eot .eot
AddType x-font/woff .woff
AddType image/x-icon .ico
AddType image/png .png
<IfModule deflate_module>
<IfModule filter_module>
AddOutputFilterByType DEFLATE text/plain text/html
AddOutputFilterByType DEFLATE text/xml application/xml application/xhtml+xml application/xml-dtd
AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml image/svg+xml
AddOutputFilterByType DEFLATE text/css text/javascript application/javascript application/x-javascript
AddOutputFilterByType DEFLATE font/otf font/opentype application/font-otf application/x-font-otf
AddOutputFilterByType DEFLATE font/ttf font/truetype application/font-ttf application/x-font-ttf
</IfModule>
</IfModule>
# Final Optimizare on-page

Ai aici cateva optiuni de optimizare standard, dar sunt mult mai multe. Daca ai nevoie de ajutor, poti cere aici fara jena. Cu siguranta se va gasi cineva sa te ajute. Trebuie sa fii constient ca website-ul tau de prezentare conteaza pentru client. daca tu oferi astfel de servicii si site-ul tau nu este OK, nu vei avea clienti.

Toata stima!

Multumesc mult pentru sfaturi !
Nu am lucrat prea mult la site-ul meu . am cumparat domeniul pentru alta afacere , dar am vandut-o :))
Si o sa vreau sa-l folosesc pentru altceva , dar nu acum . asa ca m'am gandit ca momentan sa pun doar un wordpress cat de cat, de prezentare pe el.
Poti sa'mi lasi un id de skype, sau email , sau orice?
Multumesc mult!

@vertedi: la ce ajuta punctele 1, 2 si 3?

Citat:

---

Postat în original de casperel

@vertedi: la ce ajuta punctele 1, 2 si 3?

---

Ajuta la seo.
Url-ul fisierelor css,js,etc.. au un cuvant seo in loc de wp-contect.

Citat:

---

Postat în original de Kidde

Ajuta la seo.
Url-ul fisierelor css,js,etc.. au un cuvant seo in loc de wp-contect.

---

Poti argumenta?
Eventual un test facut de cineva, undeva?

Da, uite la ce ajuta punctele 1,2 si 3, cu toate ca si voi stiti aceste lucruri dar na, tre sa argumentam. Referitor la platforma WordPress, sunt foarte multe persoane pricepute care prezinta tot felul de servicii si aici ma refer la cei care activeaza in SEO si Web Design, dar ignora cateva aspecte minore la instalarea unei platforme WP.

1. De ce trebuie schimbat numele folderului temei - pai frumos este sa apara pe site-ul tau in limba romana /wp-content/themes/enfold/, de exemplu? Nu este mai OK, sa apara /wp-content/themes/tractoare/ (pentru un site de tractoare)?
2. De ce sa modifici datele din style.css - pai daca tu creezi un website pentru nu's ce companie si in style.css, raman alte date, este OK? De ce sa stie toata lumea ca tu folosesti o tema cu nu's ce nume si poate care are si probleme de securitate!
3. Redenumirea folderului /wp-content/ tine in primul rand de securitate la nivel de atacuri automate si apoi de design-ul codului sursa. Una este sa ai /wp-content/themes/enfold si altfel arata /fisiere-seo/themes/tractoare de ex.


La partea de securitate in WordPress, trebuiesc indeplinite cel putin 10 conditii vitale, printre care se afla si redenumirea fisierului wp-content sau schimbarea URL-ului la toate fisierele WordPress.

Citat:

---

Postat în original de vertedi

Da, uite la ce ajuta punctele 1,2 si 3,

---

Kidde a spus ca ajuta la SEO si eram curios cum anume.
In rest, ca e "frumos" sa fie folderul nustiucum... e complet irelevant pentru mine. Cat despre securitate, poti fi sigur ca daca aia era problema, era un nume random la fiecare instalare (cum e adminul de la presta).
Cand cumperi o tema, depinde de licenta ei. Daca n-o faci tu, "frumos" e sa nu scrii numele tau pe ea.

Dar astea sunt subiecte de dezbatut care n-au neaparat legatura cu SEO. Ma interesa in ce fel are legatura specific, numele folderelor in instalarea ta, atata timp cat nu sunt vizibile in niciun url. Daca folosesc debian in loc de centos imi da vreun premiu?

Este OK cum spui tu @Dan. Folderele sunt vizibile in URL-urile imaginilor, CSS, JS, etc, daca la asta te refereai cu "atata timp cat nu sunt vizibile in niciun url". Din punctul meu de vedere, un cod sursa fara /wp-content/, arata mai bine si ma pazeste cat de cat. Acum, ce sa spun, fiecare cu parerea lui si eu respect parerea oricui.

@vertedi
Nu am personalizat niciodata wp-content pentru ca am descoperit tarziu chestia asta si, in conditiile in care am sute de articole, imagini, etc, si folosesc unele module mai complexe, m-am gandit sa nu zapacesc site-ul. Daca se face modificarea asta din mers, nu trebuiesc modifecate si url-urile atasamentelor deja existente in baza de date?
Multumesc!

Legat de contradictiile de aici, din punct de vedere SEO ar fi doar includerea unui kw in url-ul tuturor atasamentelor. Personal nu vad cu ochi buni chestia asta, prefer sa gestionez kw-urile atasamentelot din numele fisierului si alt. Daca as ranka si pe articole la fel ca pe imagini, as fi rege :D. Am site-uri care au picat de mult, nu mi-am mai dat interesul de luni de zile pentru ca am abandonat nisele, dar inca primesc vizite din cautarile dupa imagini.

Citat:

---

Postat în original de Mishu

Legat de contradictiile de aici, din punct de vedere SEO ar fi doar includerea unui kw in url-ul tuturor atasamentelor. Personal nu vad cu ochi buni chestia asta.

---

Mi se pare aberant sa faca google chestia asta. Sa dea valoare pe baza unui folder intern, neafisat in site nicaieri. Majoritatea site-urilor mari folosesc un CDN, iar WP chiar ofera varianta asta gratuit, caz in care url-ul imaginilor n-are nicio legatura cu nimic. Dar daca cineva are argumente cu privire la asta, eventual bazate pe un test, pe o logica oarecare, le ascult.

Legat de securitate si de chestiunea din htaccess prezentata de vertedi, am iarasi rezerve. Eu vad altfel securitatea (adica ai un plugin vulnerabil, preferi sa il ascunzi sau sa il corectezi?). Iar despre htaccess, eu as zice ca regulile alea nu sunt bune pentru toti. In primul rand ca multi folosesc nginx, nu apache, apoi fiecare regula expusa acolo ar trebui sa fie inteleasa, abia apoi implementata.

Gandeste-te ca un cetatean incepator de pe forum pune cum scrie acolo, cache la css un an. In timp ce dezvolta site-ul, ca testeaza si el daca merge bine inainte sa fie gata. Cat dureaza sa se prinda unde e problema si de ce nu vede modificarile? Sau altfel - ala chiar face cache la css versionat? De aia am zis, sunt subiecte de dezbatut, nu trebuie luate de bune din prima. Aviz amatorilor.

@Mishu - nu se zapaceste nimic din WordPress, daca se schimba URL-ul, folderului wp-content. Informatia se va lua automat din noul folder. Problema este doar daca ai adaugat manual in ceva articole sau pagini, imagini care se servesc din /wp-content.

@Dan - Scriam pe undeva ca parerile sunt impartite si in general pe forum se discuta din experienta. Fiecare persoana care activeaza in acest domeniu, are modul sau de lucru si daca impartaseste ceva aici, eu de exemplu testez, dupa care comentez sau vin cu argumente pro sau contra. Referitor la CDN si variantele gratuite, sunt apa de ploaie! Daca folosesti un CDN, pentru incarcarea imaginilor de acolo sau a fisierelor CSS, JS, vei constata ca procentul de optimizare scade foarte tare. Daca eu activez in domeniul SEO si prezint servicii de optimizare SEO on-page si off-page, website-ul meu trebuie sa fie bine optimizat altfel, ramane loc de iterpretare.

Eu tin foarte mult la partea tehnica a unui website si mai ales la website-urile mele care au un procent bun de optimizare si asta se datoreaza si codurilor adaugate in .htaccess. Daca cineva adauga acele coduri in .htaccess, nu au cum sa faca rau si se pot sterge in cateva secunde. NGINX-ul, ignora .htaccess-sul, deci codurile respective nu au valoare dupa cate stiu eu.

Eu am mai avut discutii legate de PageSpeed, pe acest forum si nu sunt multi care stiu intr-adevar sa optimizeze un site, cu toate ca prezinta servicii de optimizare, dar pareri au si majoritatea contra. Ce am scris despre optimizarea platformei WordPress, am scris din experienta si daca la mine functioneaza la zeci de site-uri, de ce nu ar functiona si la altii? A testat cineva codurile din .htaccess si a fost problema? Instaleaza WordPress, undeva, fa un test cu PageSpeed, apoi adauga codurile respective in .htaccess si vezi diferenta. Fa orice modificare in orice fisier CSS si vei vedea ca modificarea se vede instant - codurile din .htaccess, nu creaza fisiere .html, care sa fie servite in browser.

Este bine cum spui tu "De aia am zis, sunt subiecte de dezbatut, nu trebuie luate de bune din prima. Aviz amatorilor.". La modul general, daca la o discutie pe forum sau oriunde in alta parte, cand vii cu argumente contra, ar trebui sa testezi intai varianta pusa in discutie si apoi sa argumentezi, altfel, discutam in contradictoriu doua saptamani si fara valoare.

Citat:

---

Postat în original de vertedi

Este bine cum spui tu "De aia am zis, sunt subiecte de dezbatut, nu trebuie luate de bune din prima. Aviz amatorilor.". La modul general, daca la o discutie pe forum sau oriunde in alta parte, cand vii cu argumente contra, ar trebui sa testezi intai varianta pusa in discutie si apoi sa argumentezi, altfel, discutam in contradictoriu doua saptamani si fara valoare.

---

Or fi subiecte de dezbatut, ai sau nu dreptate, am o intrebare mai buna.

Din tot forumul, cum decis ca cel mai bine ar fi sa le dezbati in topicul de servicii al unui coleg?

Citat:

---

Postat în original de vertedi

Instaleaza WordPress, undeva, fa un test cu PageSpeed...

---

Eu nu contest ca pagespeed iti da niste informatii bunicele, dar in incercarea de a obtine un scor mare te pierzi in detalii si uneori pierzi esentialul.
Folosesc asta: https://www.webpagetest.org/ care mi se pare mult mai relevant. Si inca o data: militez pentru ca fiecare sa inteleaga ce face, nu sa ia un cod si sa-l puna pe site si aia e.

Foarte corect ce spui @Dan. Toata stima!

Pentru cei care s-ai gandit sa foloseasca indicatiile de mai sus:

Citat:

---

.htaccess files are evaluated on EVERY server request. Even for static images, CSS and JS files.

Also, parent directory's .htaccess file is processed for files residing in subdirectory too. So, if your .htaccess is in root directory of website, then it will be processed for all requests made for files in the subdirectories too (along with the .htaccess file in subdirectory).

That is a lot of processing. If you have a page with 10 images (for example) it gets processes 11 times. And the more processing in the file, then the more cycles it takes. So yes, anything in a htaccess file has an impact.

---

Pentru ca e bine sa cunoasca lumea cat de indicata poate fi folosirea unui "carnat" in fisierul .htaccess, mai ales daca ai un cont de gazduire shared, cu resurse CPU limitate.

@Ovidescu, nu am inteles chestia cu "folosirea unui "carnat""! Sa inteleg ca nu este bine sa adaugi coduri de optimizare, sau ce? Am sa iti dau cateva detalii despre fisierul .htaccess, sa ne intelegem mai bine:

Ce este un fișier .htaccess

.htaccess este un fișier de configurare care se utilizeaza pe servere web Apache si se afla in directorul radacina sau se mai poate gasi in diverse subdirectoare unde sunt necesare comenzi custom. Fisierul .htaccess, ofera posibilitatea de a controla un anumit director sau o parte a serverului (pentru ca te refereai la shared). Prin utilizarea fișierului .htaccess putem modifica configurarile software de tip server, pentru a opri sau satarta rularea unor functionalitati de server si caracteristici. Pentru ca subiectul respectiv se refera la optimizarea unei platforme WordPress, iata ce poate face:

- optimizarea site-ului
- imbunatatirea vitezei de incarcare in browser
- protejarea prin parola a diverselor directoare, etc.
- blocari de IP si multe alte servicii

In cazul nostru, scopul principal este adaugarea acestor coduri in .htaccess, pentru ca nu avem acces la nivel de server in fisierele Apache. Codurile adaugate in .htaccess, nu afecteaza serverul pentru ca daca nu stiai, companiile de hosting nu mai au servere Intel Pentium 3, au ceva mai performante. Eu sunt sigur ca si la tine in .htaccess, exista coduri de optimizare, numai ca asa place unora, sa fie altfel si sa arunce subiectul discutiei in alta parte.

Daca nu esti lamurit cu .htaccess-ul, am sa dezvolt mai mult subiectul. Multumesc pentru parerea ta! Asta inseamna Forum - discutii, opinii, etc. Orice este bine venit, SEOPEDIA, este o comunitate mare si se poate discuta orice si oricum, adica nu chiar oricum!

Citat:

---

Postat în original de vertedi

@Ovidescu, nu am inteles chestia cu "folosirea unui "carnat""! Sa inteleg ca nu este bine sa adaugi coduri de optimizare, sau ce?

---

Are dreptate Ovidescu.
Apache evalueza htaccess la incarcarea fiecarui fisier (imagine, css html etc). Cu cat este mai stufos htaccess, cu atat timpul de incarcare creste. E drept, timpii sunt mici, dar se aduna si incarcarea serverului creste. In functie de server si de bucatica pe care o primesti tu din server, unele directive puse de tine acolo pot chiar ingreuna un site, pot creste timpul de incarcare al site-ului. Cum ar fi compresia. Daca esti la limita cu resursele si site-ul este unul foarte dinamic, este posibil ca atunci cand activezi compresia sa ai nevoie de alt server.

Chioar astept discutia despre htaccess :)

Bun, daca vreti sa va convingeti, iata cateva website-uri care contin codurile respective si pe care va rog sa le testati asa cum stiti voi:

Pentru teste folositi ce vreti voi si va sugerez:

- Which loads faster? - comparati cu alte site-uri concurente viteza de incarcare
- Google: https://developers.google.com/speed/...nsights/?hl=ro
- Google: https://testmysite.thinkwithgoogle.com/
- https://seositecheckup.com/
- https://gtmetrix.com/

...sau ce mai stiti voi.

1. computerscom.ro - shared hosting de la TLH.
2. romania-seo.ro - un VPS, slab de la Globehosting
3. cursuri-seo.com - shared de la Globehosting
4. kseo.ro - shared slab de la Romarg
5. infoseo.ro - shared de la TLH
6. opti-seo.ro - shared de la xtremehosting
7. firma-seo.ro - shared de la TLH

Am enumerat 7 site-uri pe care le puteti compara cu ce vreti voi la partea de optimizare. Nu sunt cele mai bune site-uri din Internet, dar sunt ale mele si au codurile respective adaugate in .htaccess. Acum daca tot participati la discutie si veniti cu "nu este bine, nu este corect, nu este adevarat", haideti sa vedem cu ce optimizari veniti voi pentru ca majoritatea celor care aduc argumente contra se ocupa de SEO. Eu am dat 7 exemple, sa vad ce dati voi fara adaugari de coduri in .htaccess. Sper ca nu spuneti "NU POT DA SITE-UL MEU", pentru ca asta ar da nota de slabiciune.

Eu am raspuns la cererea lui @bogdanpodina si am venit cu ceva idei, atat cat stiu am incercat sa ajut cu placere. Daca voi sunteti experti in domeniu si veniti cu asemenea argumente, ar fi OK, sa dati ceva exemple. Daca nu veniti cu exemple, inseamna ca stiti sa scrieti bine pe forum. Eu sunt mai batran si acumulez mai greu chestiile astea cu SEO si respect tinerii care au succes in asa ceva dar, nu este suficient sa comentezi, trebuie sa si arati ceva, asa ar fi OK.

Mai scriu inca o data ca SEOPEDIA, este un forum unde se discuta despre SEO si ca pe orice forum, vedim cu idei, argumente pro sau contra, etc. Eu iau de bun ce spuneti voi dar pana la proba contrarie, ca orice om normal, vreau sa vad.

Citat:

---

Postat în original de vertedi

Am enumerat 7 site-uri pe care le puteti compara cu ce vreti voi la partea de optimizare. Nu sunt cele mai bune site-uri din Internet, dar sunt ale mele si au codurile respective adaugate in .htaccess.

---

Exact ce spuneam.
Am luat la intamplare unul si uite, singurul factor care conteaza la SEO are nota mica:

http://i.imgur.com/LjrGOiA.png

Multumesc @Dan! Ma bucur ca ai nimerit unul din 7, cu ceva probleme dar se poate sa mai fie si problema de la server, este hosting shared, ce pretentii sa ai! La mine vad ca arata altfel, am sa mai incerc si mai tarziu. Oricum, este jenant pentru mine sa vand servicii SEO si sa am un site cu probleme de genul acesta. Dupa cum spuneam, eu nu ma consider specialist, sunt de nivel mediu si fac atat cat ma duce capul. Asteptam ceva exemple de la voi, sa am si eu ce testa, asa mai invat cate ceva.

Ataşament 4330

Citat:

---

Postat în original de vertedi

sunt de nivel mediu.

---

Nicio problema. Eu ti-am raspuns la ce ai sustinut tu, ca acele directive din htaccess sunt bune. Eu doar zic ca nu sunt mereu bune, atata tot.

"Batrane" vertedi, eu nu vreau sa te conving pe tine de ceva anume, am scris doar ca trebuie sa fie atenti (cei pe care i-ai convins ca trebuie sa foloseasca orbeste directivele respective) la folosirea .htaccess, fiindca serverul s-ar putea sa tina sau nu. Degeaba optimizezi in asa fel incat paginile ar trebui sa se incarce minunat de rapid, daca ingenunchiezi serverul.
Da, eu am avut probleme, in trecut, cu un .htaccess marisor pe un server dedicat (un dual xenon). Daca ai un cont shared cu atat mai mult e bine sa fii atent la cat de repede poti atinge limita maxima de procesare, fiindca te trezesti cu contul suspendat si plangi pe forum ca ai "doar" un wordpress cu 200 de vizitatori / zi. Daca esti chiar maniac cu optimizarile, renunta la apache, apartine secolului trecut.

Partea cu

Citat:

---

Eu sunt sigur ca si la tine in .htaccess, exista coduri de optimizare, numai ca asa place unora, sa fie altfel si sa arunce subiectul discutiei in alta parte.

---

e de prost gust, n-are sens sa-ti raspund la asa ceva.

Repet, am scris pentru cei care ti-ar putea lua frazele bombastice drept litera de lege, in conditiile in care chiar nu e cazul. Parerea mea e ca ar trebui sa fim mai responsabili cand dam sfaturi.
Sa ai spor in toate!

Buna discutia.

Exemplu recent:

- 5 site-uri fara trafic prea mare gazduite pe un cont shared ok.

Cazul 1: fara modul de cache + alte nu stiu ce coduri de htaccess care sa optimizeze tampeniile enumerate de gtmetrix - incarcare decenta, in 2-3 secunde.-

Cazul 2: cu toate recomandarile gtmetrix, site-uri duse toate la 95%(verdele ala misto), module si toate cele, site-ul se incarca in....15 secunde(nu mereu, ce-i drept, dar poti sa stii cand intra vizitatorul ala care-ti aduce si bani?!). De ce? Pai imi mananca toate resursele daca le deschid pe toate concomitent!

Atentie mare la neatentie. Ne uitam la niste cifre si uitam esentialul :)

@Ovidescu, este drept ce spui si sincer, nu vreau sa te supar sau sa demonstrez nu's ce balarii. Pe mine ma deranjeaza ca nu vad la nimeni sa fi probat codurile respective si sa spuna ca serverul este pus in cap, pentru ca nu are cum. fata de :

Citat:

---

Daca esti chiar maniac cu optimizarile, renunta la apache, apartine secolului trecut.

---

...nu, nu sunt maniac! Incerc sa fac o optimizare buna si atat. Nu crezi ca ar fi jenant sa spun "vand servicii de optimizare SEO", sau "sunt expert", asa cum vezi pe multe site-uri si daca cineva testeaza site-urile mele sa gaseasca tampenii? Optimizarea unui server cu Apache, eu o fac manual si nu am avut inca probleme. Am website-uri optimizate foarte bine si sunt pe Apache, nu vad inca o problema cu Apache-ul.

Multumesc tuturor pentru raspunsuri, sunt bine de luat in calcul si din discutiile noastre pot si altii invata. Chiar am creat un articol pe unul din site-urile mele cu mai multe detalii despre .htaccess si codurile respective si pot spune ca sunt din experienta, testate si mega testate - la mine merg si au mers pe orice server, mai putin NGINX, acolo este alceva.

Merci pentru urare @Ovidescu, sa ai si tu spor in ce iti doresti. Toata stima!

Hai sa iese si ceva util din discutiile astea, ca ele sunt foarte bune dar parca nu aici. Poluam oferta omului si cred ca singura greseala pe care a facut-o vertedi este ca a postat aici. In rest, ca are sau nu dreptate se poae discuta dar important este ca din discutii sa se poata extrage informatie utila.

@Dan: First Byte Time nu este o problema care tine de server? Pe shared, dupa ceva modificari facute de firma la care am gazduirea (trecerea la LiteSpeed) am un FBT intre 450 ms si (tineti-va) peste 12.000 ms ajungand uneori si la 30K ms. Uzual pe la 3,5 sec. Nu are rost sa mai spun ca uneori vizitatorul prefera sa inchida pagina inainte de a se incarca si in ce mod mi-a afectat asta traficul. (Ca tot m-am plans in alt topic, se pare ca asta e cauza!)
Are rost sa discut cu ei despre treaba asta sau pierd timpul si e mai bine sa sar repede la alta gazduire? Pana acum mi-a mers f. bine cu ei, e vorba de spatiul.ro. Apropo, care mai aveti gazduire la ei, ma puteti ajuta si numai spunandu-mi daca va confruntati cu aceeasi problema.

@vertedi: E foarte usor sa dai a exemplu un site mic, simplu, fara functionalitati care sa maninca resurse, cu o pagina care se incarca din cateva requesturi. Din cauza asta pot sa spun ca exemplele tale nu confirma ceea ce ai spus daca nu vii cu un exemplu de "site greu" optimizat ca la carte. Nu spun ca nu ai dreptate, spun doar ca exemplele nu sunt concludente, nu pot fi reprezentative.

@toti ceilalti: Folositi module de cache? Ati vazut cam ce baga alea prin htaccess? Atunci cum se face ca pe alea le recomandati iar un cod optimizat (nu neaparat al lui vertedi) il respingeti?

Stima tuturor si astept sfaturi pertinente pentru problema mea, nu ma prea pricep la chestiile de server.

@Mishu - First time byte tine de mai multi factori, printre care server, cache, php, retea etc.
La conturile shared, unele hosturi fac o chestie pe care n-o inteleg pe deplin, dar am mai mentionat-o. Cand site-ul nu are vizite, se sterge din cache (al lor). Cand e accesat prima oara dupa o zi (sa zicem), dureaza extrem de mult pana se incarca, pentru ca cel mai probabil intai se populeaza cache, apoi este servit catre utilizator. Nu cred ca e ceva ce poti face in sensul asta in afara de un script automat care sa viziteze site-ul ocazional.

Altfel da, de principiu un server local (acelasi oras cu cel care face testul) cu ceva cache, nginx, php7, memcache/redis si suficient de "liber" va incepe sa serveasca pagina mult mai repede decat serverele shared. Conturile shared nu folosesc ultimele tehniologii din simplul motiv ca exista scripturi ale utilizatorilor care nu merg pe nginx sau/si nu sunt compatibile cu php7, iar compania de hosting nu o sa stea la fiecare sa il intrebe "dar tu ce folosesti, ia sa vedem, merge?".

Compresia "on the fly" de care spunea vertedi in instructiunile lui de htaccess este buna in cele mai multe cazuri, cu mentiunea ca intarzie putin raspunsul serverului (trebuie sa comprime contentul) si trebuie sa stii ce faci. Adica nu are sens sa comprimi si imaginile, care sunt deja comprimate. Instructiunile lui par ok dealtfel in sensul asta.

Wordpress are cateva pluginuri de cache foarte bune (eu folosesc w3total cache) care pe langa instrucitunile in htaccess (pe care eu nu le folosesc, ca am nginx) face cache la pagini, la bucati de php, la obiecte din db. Astfel, nu este nevoie ca serverul sa proceseze nimic in 99% din cazuri, doar serveste content static.

Nu ma pricep sa spun ce mai este intre site-ul tau si marele internet atunci cand esti pe un server shared cu litespeed, deci nu pot sa iti dau un sfat in sensul asta. Compania de hosting iti raspunde cel mai bine la intrebare. Cert e ca atunci cand serverul lor e aglomerat, ai de suferit. Si aglomeratia nu tine de ei, ci de "vecinii" tai de pe server.

Ce am spus eu si repet - nu luati de bun orice scrie pe internet. Faceti backup, testati diverse, folositi https://www.webpagetest.org/ care are mai multe locatii si browsere si va da informatii despre raspunsurile serverului la fiecare element de pe pagina. Exista cazuri in care codul lui vertedi, in lumea reala, poate sa faca un site sa se miste greu. De aia ar trebui, dupa parerea mea, inteleasa fiecare instructiune si vazut daca se aplica.

Nu este vorba de site-uri fara vizite. Am deschis un ticket sa aud si parerea celor de la gazduire.
Cica ar fi de la limtari...
La resource usage imi arata ca am limitari pe I/O usage resources pentru ca am depasit database i/o usage, unde vad si o dinamica foarte mare, intre 0 B/s pana la 2,9 MB/s.
Ideea e ca timpii de incarcare sunt intre 3 s si peste 30 s, iar First Byte Time foarte rar e sub 500 ms, ajungand pana la peste 15 s. Sunt fluctuatii foarte mari si cred ca asta doar cu serverul poate avea legatura.
Site-urile erau destul de incarcate, fiecare cu peste 120 requesturi, multe imagini, scripturi custom, etc. Am redus pe cat am putut fara sa afectez functionalitatea si au ajuns la 50-80 requesturi dar fara a se imbunatati ceva.
Mi se pare cam ciudat ca acea limitare pe i/o usage (la 2 MB/s pe care nici nu i-am mai atins de atunci) sa fie de vina, plus ca situatia asta e de ceva timp iar limitarea e de ieri.

Multumesc!

Ce parere aveti de https://www.namecheap.com/support/kn...dpress-website ?

Hop și eu, să mă bag în seamă

Fișierul .htaccess* este parcurs la fiecare request (imagine, css, js, ce vreți voi).
La un site stufos și suficient de accesat, consumul de resurse pentru parcurgerea .htaccess o sa înceapă să se simtă.

Soluțiile sunt simple
- fie mutati toate directivele .htaccess în definiția serverului virtual
- fie rulati nginx (în care până la urmă faceți exact aceeași treabă)

Să fiți sănătoși!

Citat:

---

@vertedi: E foarte usor sa dai a exemplu un site mic, simplu, fara functionalitati care sa maninca resurse, cu o pagina care se incarca din cateva requesturi. Din cauza asta pot sa spun ca exemplele tale nu confirma ceea ce ai spus daca nu vii cu un exemplu de "site greu" optimizat ca la carte. Nu spun ca nu ai dreptate, spun doar ca exemplele nu sunt concludente, nu pot fi reprezentative.

---

@Mishu, eu am venit cu ceva exemple pentru ca asa a generat discutia legata de codurile .htaccess. Daca exemplele mele nu sunt concludente, vino tu cu ceva concludent daca tot despre asta vorbim. OK, nu veni cu un site mare, vino cu unul mic, foarte mic, abia instalat, sa aiba imagini, continut, CSS, JS.

Citat:

---

E foarte usor sa dai a exemplu un site mic, simplu, fara functionalitati care sa maninca resurse, cu o pagina care se incarca din cateva requesturi.

---

La exemplele date de mine sunt cateva request-uri, pentru ca website-urile respective sunt optimizate. Din 7-8 fisiere CSS, am creat doar unul si acela compresat. Din 10-12 fisiere JavaScript, am creat 1-2 si acelea compresate. De ce crezi ca un website mare cum spui tu are multe requesturi? Pai pentru asta, incarca zeci de fisiere CSS, care fac diverse servicii, zeci de JS-uri, imagini pentru tema care nu sunt adaugate intr-un sprite, imagini de produse care nu sunt optimizate, fisiere externe pentru fonturi sau diverse alte servicii.

Asta este motivul pentru care ai timp mare de raspuns la server. Incearca sa optimizezi site-ul si nu vei mai avea. Combina si comprima fisierele CSS si JS, optimizeaza serverul cat se poate, optimizeaza imaginile si vei vedea ca totul va fi bine. Adauga aici un exemplu de website care iti apartine si are prea multe requesturi si cu siguranta se va gasi cineva sa te indrume.

Citat:

---

Postat în original de gupi

La un site stufos și suficient de accesat, consumul de resurse pentru parcurgerea .htaccess o sa înceapă să se simtă.

---

Vb. din experienta? Nu am testat dar sunt in stare sa pun pariu ca nu poti sesiza diferenta.

Din experienta:

Se dau: 1 poza (jpeg, comprimat), 1 css (pana in 1000 de linii), 1 js (pana in 1000 de linii).
Diferenta de viteza, cache vs no cache (orice fel de cache implementat decent; nu bine, decent) se vede. Fara sa masori nimic, iti dai seama ca e mai rapid :)

Pentru cei se se plang ca "incarca" .htaccess-ul:
cache - este o colecție de date ce sunt o "copie la indigo" a valorilor originale stocate altundeva sau calculate mai devreme, unde operația de aducere din memorie a datelor originale este costisitoare (datorită timpilor mari de acces la memorie) sau costul recalculării acestora este mare, în comparație cu costul citirii acestora din cache. ( wikipedia :) )

Sa tragem niste concluzii.
- Orice mecanism ce face cache ocupa anumite resurse. Nu exista sistem de cache care sa nu "ingreuneze".
- Cu cache, la prima accesare (cand nu ai cache) totul merge mai greu. :)
- Cu cache, de multe ori, resursele mici ce nu necesita multa procesare se aduc mai greu.

Cu cache, unele lucruri merg mai greu, altele mai usor. Daca nu poti gasi acel punct in care maximizezi chestiile care merg repede si le minimizezi pe cele ce merg gereu, poti spune ca ai un cache prost!

Cei ce dau copy-paste (in .htaccess sau in general) o pot nimeri bine sau nu. Daca nu stii ce faci, poti folosi un plugin sau poti ruga pe cineva sa te ajute. E mai simplu.

Eu am 3 chestii in .htaccess si prefer sa ramana asa

1. 301 seo redirect pentru https (asta e adaugat de curand),2 randuri sau 3.
2. chestile default de la wordpress, fara alea nu se poate, ce pune el prima oara nu ce ar mai putea adauga alte 100 de pluginuri in plus pe acolo (4 randuri parca)
3. xml-rpc protection (nu ca mi-ar sparge cineva siteul dar cand vin 1000 de roboti sa se joace cu fisierul ala merge foarte greu siteul)

Am mai vazut la uni clienti un Deny pe ip-uri. unul din ei avea deja peste 200 de ip-uri in lista. Am avut si eu o vreme cand tot adaugam robotii si veneau altii... mai bine pui sucuri sau alte metode de protectie care blocheaza singure ip-uri decat sa stai sa faci o lista care din punctul meu de vedere nu se termina nicodata.

Referitor la viteza de incarcare a siteului. Recent am facut un test cu gmetrix la unul din siteurile mele si mi-a dat rezultatul din imaginea atasata - https://s2.postimg.org/vlhrn9jjt/Untitled-1.jpg. Stiti cumva cum as putea sa rezolv, cum pot sa scad acel numar de requesturi, la ce se refera mai exact?

Citat:

---

Postat în original de haotik

3. xml-rpc protection (nu ca mi-ar sparge cineva siteul dar cand vin 1000 de roboti sa se joace cu fisierul ala merge foarte greu siteul)

---

Exista varianta doar pentru .htaccess sau trebuie modificat si pe serverul Apache?

Ai putea configura Apache să folosească HTTP/2 -> este semnificativ mai rapid decât HTTP și oferă o serie de avantaje.
Dacă dai o căutare pe Google găsești articole cu instrucțiuni despre cum se face.