Új hozzászólás Aktív témák
-
-
-
-
martonx
veterán
"Ezt kezelni is sok, és valószínűleg a Google sem szeretné." - ezt azért így túlzás kijelenteni
Légyszi guglizz utána, hogy a Google-nek mi az elvárása a sitemap.xml-nek. Nekem 10mbyte-os méret rémlik maximumnak amit kezel, és X tízezer link. De lusta vagyok rákeresni és felfrissíteni az emlékeim.
Á látom közben rákerestél, helyes. Ez esetben a véleményem, hogy azt csináld, amit SEO-ilag el szeretnél érni
-
-
-
martonx
veterán
Igaziból semmi nem kell hozzá hiszen az origin headerben látszik, hogy melyik domainről indult az http request.
Ettől függetlenül a legtutibb megoldás, az általad írt példa, amikor querystringben hozzácsapod a domainedet. Ők meg ezt fogadják, és maguknál logolják. Más kérdés, hogy ez az elmélet a gyakorlatban le fognak szarni. -
disy68
aktív tag
Attól függően érdemes beállítani, hogy mennyi idő legyen a lejárat, amennyi idő a várható változása az adott resource-nak. Ha csak static content-et szeretnél cache-elni, ami várhatóan nem fog változni, akkor adj meg hosszú lejárati időt.
Statikusnak számítanak ilyen szempontból a verziózott fájlok is.
A cache az url alapján megy, szóval a https://domain.com/something.js?v=1.0 cache-elésre kerül a böngésző által és ha azt változtatod és cseréled https://domain.com/something.js?v=1.1-re, akkor az egy teljesen új resource lesz a böngésző szempontjából, amit letölt és cache-el magának. A korábbi verzió pedig addig marad a böngésző cache-ben, amíg le nem jár vagy ki nem lesz törölve (manuálisan vagy a böngésző által). -
Taci
addikt
Az én hibám, bocsánat a "pánikkeltésért"...
Valahogyan benne maradt egyHeader Set Cache-Control "max-age=0, no-store"
így minden fájlnak a headerjében ez volt benne, így találtam meg.
Most már rendben működik.Már csak az ajánlott cache-elési időtartammal kapcsolatban kérnék iránymutatást.
Köszönöm, és bocsánat a sok egymás utáni posztért.
-
Taci
addikt
Így állítottam be:
<IfModule mod_expires.c>ExpiresActive On# ImagesExpiresByType image/gif "access plus 1 month"ExpiresByType image/jpg "access plus 1 month"ExpiresByType image/jpeg "access plus 1 month"ExpiresByType image/png "access plus 1 month"ExpiresByType image/svg+xml "access plus 1 month"ExpiresByType image/webp "access plus 1 month"# Webfonts# TrueType (TTF)ExpiresByType application/x-font-ttf "access plus 1 month"# OpenTypeExpiresByType font/opentype "access plus 1 month"# Web Open Font Format (WOFF) 1.0 (WOFF)ExpiresByType application/font-woff "access plus 1 month"ExpiresByType application/x-font-woff "access plus 1 month"ExpiresByType font/woff "access plus 1 month"# Web Open Font Format (WOFF) 2.0 (WOFF2)ExpiresByType application/x-font-woff2 "access plus 1 month"# Embedded OpenType (EOT)ExpiresByType application/vnd.ms-fontobject "access plus 1 month"ExpiresByType font/eot "access plus 1 month"# otf ttfExpiresByType application/font-sfnt "access plus 1 month"# CSS and JavaScriptExpiresByType text/css "access plus 1 week"ExpiresByType text/javascript "access plus 1 week"ExpiresByType application/javascript "access plus 1 week"</IfModule>De F12 --> Network alatt a fájljaimnál nem látom se a
Disk cache, se aMemory cachefeliratokat, csak a fájlméretet, így gondolom, nem működik a cache-elés.Van ötletetek, miért nem? Mit kell még beállítanom?
Tapasztaltam, hogy a .htaccess-ben történt változásokhoz jobb törölni az oldalhoz tartozó böngészési adatokat (vagy eleve privát böngészésben nézni), így most úgy próbálom, de sajnos így sem működik úgy, ahogy szeretném. -
Taci
addikt
Beállítottam, nem volt egy bonyolult művelet. Utána is olvastam, mit csinál, szóval ez megoldva.
Viszont ha már írok, beírom egy másik kérdésemet is, szintén a Lighthouse-hoz/PageSpeed-hez kapcsolódva.
Reszponzív az oldalam, ugyanaz a kód viszi minden felbontáson az oldalt, pontosan ugyanazokkal a fájlokkal.
Mégis nagyon eltérő mérési eredményeket adnak az eszközök:Desktop:
Mobile:
Ég és föld a különbség, és nem értem, miért.
Részletesen a riport itt érhető el: [link]
"Távolítsa el a megjelenítést gátló erőforrásokat"
Ennél a résznél desktopon az egyik saját fájlt 80ms megtakarítási potenciálra írja, míg mobilon ugyanezt a fájlt már 300ms-re.
A cookiebot js fájlját asztalon 270ms-re, mobilon 1080ms-re...Miért mér más eredményeket ugyanarra a kódra asztalon és mobilon? 76 pont asztalon, 42 mobilon az össz-eredmény. Hatalmas különbség, és nem igazán tudok vele mit kezdeni.
Tudtok tanácsot adni?
Van értelme nézni ezt a riportot egyáltalán? Merthogy amúgy nagyon nem ilyen sebességekkel tölt be mobilon sem, szóval nem értem, mit és hogyan mér, de nem valós.Köszi.
-
martonx
veterán
"A külön tesztkörnyezet megvan (abban fejlesztettem), de Safarihoz nincs hozzáférésem rajta."
Szerintem két különböző dolgot értünk tesztkörnyezet alatt. Tesztkörnyezet az, amikor csinálsz egy másik ugyanolyan környezetet mint az éles.
Pl. az éles környezeted hostolod XY cégnél és akármi.hu a címe.
A teszt környezeted pedig ugyanúgy XY cégnél kell hostolnod, és mondjuk teszt.akármi.hu lesz a címe. Így aztán a teszt környezetbe azt raksz ki, amit akarsz, azt ugyanúgy fogod tudni tesztelni, bárhonnan, bármivel, mint az éles site-ot.
Én erről beszélek, ez a hivatalos, normális megoldás. Nyilván lehet, hogy plusz pénzbe kerül egy teszt környezet fenntartása, de akkor is ez a jó megoldás, a többi csak kókányolás. -
Golyobis
tag
Esetleg ez, hogy a hivatkozó oldalakhoz nem ír semmit, pedig az egész weboldal tele van hivatkozásokkal.
Bár nem vagyok biztos benne, hogy ez nem-e természetes, gyakran kicsit furák, vagy akár bugosak a google programok.
Nemrégiben volt egy hasonló anomáliám a google business-sel, ahol végül a google valamelyik alkalmazottja válaszolt, hogy egy általuk is ismert bugról van szó. (Halkan megjegyzem, hogy az a bug akkor már hónapok óta fennállt, mégsem javították.)
Egy másik árulkodó dolog, hogy a feltérképezés vagy crawling résznél akad el, mindig azt írja hogy "felfedezve jelenleg nincs indexelve".
(felfedezés>fetérképezés>indexelés a sorrend, erre már rájöttem)A felfedezés rész is rendszerint a webhelytérképen keresztül történik, ha még túl friss egy bejegyzés, és még nincs benne a webhelytérképben, akkor hivatkozás, és webhelytérkép hiányában valami olyasmit ír ugyanott, hogy "nem ismert oldal".
Ezenkívül persze lehet még valami érdekes a search console-ban, amiből egy gyakorlott ember megmondaná, hogy mi a hiba, de én semmi kirívót nem látok, nincsenek hibaüzenetek, vagy piros betűvel írt figyelmeztetések.
Arra sem látok infót, hogy az egyik aloldal miért lett most váratlanul de-indexelve.
Ha megtaláltad a hozzáértőt, akkor nekem is küldd el majd az elérhetőségeit.
-
Taci
addikt
Ahhoz, hogy elérjem mobilról a lenti módszerrel a weblapot, a gép IP címét kell használnom. (https://tesztszerver.hu/index.html helyett a 192.168.1.11/index.html éri csak el). Így viszont a certificate erre nem érvényes (a szerver tanúsítványa nem egyezek az URL-lel), ezért szinte semmit nem tölt be a weblapból. (És ha gépen nézem az IP címes elérést, ott is ugyanúgy nem tölt be szinte semmit, hiszen a certificate-ben a tesztszerver.hu szerepel, és nem az IP cím.)
Tudtok erre valamilyen megoldás? -
martonx
veterán
"Van esetleg valamilyen mód rá, hogy "valós mobilváltozatban" használhassam a Chrome-ot?"
Természetesen van. USB-vel összedugod a telefonod a gépeddel (egy esetben szopás csak, ha Android telefonod van és közben Mac-el szopatod magad). Ekkor a telefonodon ugyanúgy tudod a Chrome-ot F12-vel használni a PC-s Chrome-on keresztül.
Ha nem akarsz USB-zni, akkor nem ennyire jó, de elég jó megoldás az ngrok használata, hogy telefonon meg tudd nyitni a localhoston futó oldalt.
Illetve ami még szintén jó megoldás, az a BrowserStack előfizetés, ennek van Chrome pluginje is.
-
nevemfel
senior tag
[link] - ez alapján a Chrome a 90-es verziótól kezdve alapból https-et használ, ha az url-ben nincs benne a http:// protokoll előtag. Az oldal alján még ezt írja:
[2] IP addresses, single label domains, and reserved hostnames such as test/ or localhost/ will continue defaulting to HTTP.
-
Taci
addikt
Kicsit egyszerűsítve a kérdést:
var/www/html
Az úgy jó, ha ide teszem a gyökérbe az index.html-t és a .haccess fájlt, minden mást pedig ezen belül egy almappába? Pl. var/www/html/biztonsagos-almappaVagy van jobb/másabb ajánlás?
Pl. a var/www/html/public mappa használata, bár ez nagyon nem egyértelmű számomra. Mert pl. ilyet is találtam:
The purpose to set the webroot to var/www/html/public is to hide the sensitive files like .htaccess.
De akkor az index.html-nek is mellett kell lenni, szóval akkor a DocumentRoot-ot is meg kell változtatnom.
Vagy erre az is elég, hogy<Files .htaccess>Order allow,denyDeny from all</Files>
, és simán használjam a var/www/html mappát az index.html-nek és a .htaccess-nek, minden más meg menjen a var/www/html/biztonsagos-almappa mappába? -
Taci
addikt
Sajnos túlléptem a szerkesztési időt:
Ja igen, és az amúgy a baj az átirányítással, hogy ilyenkor a maintenance.html az aktív, és mondjuk ott van előtted, látod, hogy karbantartás van, visszanézel 10 perc múlva, és ráfrissítesz az oldalra, hogy hátha működik már azóta, de mivel a maintenance.html az aktív, mindig azt töltöd újra és újra.
Vagy ilyenkor ha már nincs átirányítás, működik az oldal, akkor meg ezt a maintenance-t kell a főoldalra visszairányítani? -
nevemfel
senior tag
Én ezt a snippetet használom htaccess maintenance-hez:
<IfModule mod_rewrite.c>RewriteEngine OnRewriteCond %{DOCUMENT_ROOT}/maintenance.php -fRewriteCond %{SCRIPT_FILENAME} !maintenance.phpRewriteRule ^.*$ /maintenance.php [R=503,L]ErrorDocument 503 /maintenance.phpHeader Set Cache-Control "max-age=0, no-store"</IfModule> -
Memora
senior tag
Köszi, átnézek akkor oda!
Annyit még meg tudnátok mondani, hogy ha csak simán új template-et választok a Softaculous App-ban, majd ugyanúgy feltöltöm, mint az elsőt (WordPress install-t választva?), akkor úgy az fog megjelenni, vagy a régi marad, vagy nem fog működni, vagy a manage theme sets-nél beállíthatom, melyiket akarom látni? -
Coyot
őstag
Nem bonyolult amugy, csak elsőre nem éppen logikus mikor ficsőröket adok hozzá. Bár az Azure SQL db hozzáadásából nem derül ki a price calculator-ban, hogy az mégis milyen db engine-eket támogat.
De így 32giga tárhellyel a basic havi 20eur. Az olyan so-so, production módban pedig 70 - az szerintem nem rossz.
-
martonx
veterán
Csakis felhő: Azure, Aws, Google Cloud.
Fentiek közül egész konkrétan Azure App Service-t javaslom. Van MySql Azure-ban is, viszont az emlékeim szerint elég drága. Átpattintod a db-det MSSql-re, és fillérekből lesz Db-d is, ami a felhő szolgáltatók között egyedüliként monitorozza magát, és optimalizálja magát (bizony, csinál indexeket, statisztikákat a querykhez igazodva, ).
Linux-os app service havi 10 EUR körül rémlik, SQL 4 EUR. Azaz havi nettó 15 EUR körül ki tud jönni az alap hosting.
És ha már felhőben vagy, korlátlanul tudod skálázni magad (csak bírja a pénztárcád). -
-
disy68
aktív tag
Nem probléma, ha valamelyik kép egy nagyobb képernyőn már scroll nélkül is látható és lazy-ként van kezelve, arra is fog jelezni az IntersectionObserver ugyanúgy. Hasraütésre (meg persze az oldal tartalmától függően) pár ms késleltetés lehet, mintha eager-ként lenne kezelve.
-
martonx
veterán
Ezek szerint nem egy saját WP plugint csináltál, ahogy kellett volna, hanem a WP-hez hozzátákoltál valamit saját izét? És akkor mit használsz a WP-ből?
Mert az általad felsorolt WP előnyök, akkor jönnek jól, ha tisztán WP-zel, saját pluginnel. És akkor fogod tudni a user kezelését, blogokat, kommentelhetőséget is használni.Szerintem. Bár a PHP és a WP elég távol áll tőlem.
-
martonx
veterán
A WP-nek van saját user kezelése. Erre vonatkozott az értetlenségem. Ha van sajátja, akkor minek kezdenél el pluszban Firebase-el bohóckodni.
A saját tartamadhoz is minek kellett saját tábla? Ha meg már minden saját, akkor minek WP???
Valamit elképesztően rosszul csinálsz, de lelked rajta, valamin úgyis meg kell tanulni webfejleszteni -
martonx
veterán
Ebben az esetben eleve valmilyen CMS-el kellett volna nekifutnod. És akkor a SEO se lenne kérdés
De még mindig nem késő CMS-re váltanod.Másik alternatíva, hogy mindent így hagysz, és bekötöd magad mellé a Google Firebase-t (ha már ehhez van kompetenciád, egyébként van csomó más hasonló szolgáltatás).
Illetve emellé lekódolod magadnak az összes többi funkcionalitást 1-2 év alatt. -
inf3rno
nagyúr
Igen úgy tűnt, hogy néha frissül úgy is, ha be van zárva. Viszont ez lehet, hogy chrome feature, hogy néha frissíti a bookmarkokat. Az is lehet, hogy ami kikerül a kezdőlapra amikor új tabot nyitok csak annál frissül. Tényleg nem tudom. Még lehetőség, hogy push notification-el frissíti, de nem rémlik, hogy rányomtam volna bármikor is. Megfigyelem egy kicsit jobban, hátha csak benéztem. Mindenesetre tök jó lenne, ha meg lehetne így csinálni.
-
-
martonx
veterán
Azt tudnod kell, hogy ilyenkor a Google a saját crawler botját (vagy ahhoz nagyon hasonlót) futtat meg az oldaladon, 3G szintű net sebességgel, azaz nem az számít, hogy te 1GBps-es Digi neten milyen gyorsnak látod az oldalad betöltését, hanem az számít, hogy mondjuk USA-ból nézve egy 3G-s mobilnet sebességnek megfelelő nettel a Google bot szerint milyen gyors.
És ezek szerint az oldalad fájdalmasan lassú, sok js, css, kép, tudomisén mi blokkolja. Ezekről szerencsére egész pontos áttekintést ad a Lighthouse, hogy mi blokkolja, és mit tehetsz ez ellen. Mi nem fogjuk tudni helyetted megmondani, mert te látod a részletes riportot.
-
Taci
addikt
Még egy "fontos" infó, nem tudom, köze lehet-e hozzá, de ServerPress / DesktopServer alatt fut egyelőre az oldal, mert lokálban fejlesztem.
Ez eszembe juthatott volna hamarabb is, hogy fontos infó lehet. Na utána is olvasok, köze lehet-e a rossz eredményhez. (Remélem, igen, mert amúgy továbbra is tanácstalan vagyok.) -
Taci
addikt
Baj, ha így hagyom? Mármint hogy a Chrome azt mondja rá, hogy csiga lassú, de nyilván nem az, mert úgy nem adnám ki semmiképp.
Ezt még annyival egészíteném ki, hogy nem szeretném így hagyni. Nyilván okkal ad ilyen értékeket, szóval ezt a (fals) okot szeretném megtalálni és megszüntetni. Milyen lehetőségek vannak erre, amik rá is mutatnak, hogy mi-hol vérzik el? -
disy68
aktív tag
"A Place ID fix, univerzális, pl. ha Google-ben rákerestek Budapestére, 5 oldalnyi találatot hoz."
Ez így nem igaz. Ez a place id jelölhet mindenféle helyet (város, üzlet, földrajzi egység), amit a google számon tart és változhat idővel. Lásd Place IDs.
Szóval ahogy ezt kezelni lehetne, ha ennyire testreszabott időjárás widget-et szeretnél:
- lekéred a user location-jét (vagy/és backend-en próbálod meghatározni előre)
- a google reverse geocoding api-jával lekéred a koordináta szerinti helyadatokat (vagy ha a backend mond valami közelítő helyadatot, akkor a places api-val rákeresel)
- lekéred a forecast7 url-t a korábban megkapott place_id-val
- legyártod a megfelelő widget url-t/widget-etA google által megszerzett place_id-t illetve a forecast7 által adott url-t is persze elmentheted a koordinátához/városnévhez a folyamat során db-be, cache-be, hogy ne kelljen mindig a google api-hoz újabb requesteket ellőni és csak akkor kéred le ezeket újra, ha a widget url nem működne, ehhez persze ezt se ártana ellenőrizni.
-
cattus
addikt
Az ikonos problémánál az a legjobb, ha mindig csak vagy az egyik vagy a másik class van rajta az elemeden, különben az általad leírt anomáliák léphetnek fel. A toggle meg ugye csak a paraméterben megadott class-t fogja állítani, a többit nem. Ilyenkor vagy mindkettő class-szal hívsz egy toggle-t vagy add / remove-ot.
-
cattus
addikt
Milyen rendszerbe szeretnéd integrálni? A logika ugye itt az, hogy a HTML-be a placeholdert teszed be alapállapotban, majd ha betöltött a kép (erről ugye valahogy értesülnöd kell runtime) akkor kicseréled. Ha nem tudod előre a végleges kép dimenzióit, akkor kb. esélytelen valamekkora layout shift nélkül ezt kivitelezni.
...addig nézelődők a neten még...
Új hozzászólás Aktív témák
Hirdetés
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest